在drop table
时,innodb
引擎会清理该表在每个buffer pool
实例中中对应的数据块页面,为了避免对系统的影响,这里的清除操作并不是真正的flush
,而是将涉及到的页面从flush
队列中摘除。但在摘除过程中,删除进程会持有每个buffer pool
的全局锁,然后搜索这个buffer pool
里对应的页面以便从flush list
中删除。如果在buffer pool
中需要被搜索并删除的页面过多,那么遍历时间就会增大,这就导致了其他事务操作被阻塞,严重时可导致数据库锁住。
(推荐课程:MySQL教程)
在这里还需要注意一件事情,如果数据库的buffer pool
设置的很大,就会导致遍历时间变长
清理buffer pool
时,还包含清理AHI
包含此表的数据,AHI
的功能在这里就不多说了,主要是当b+tree
的层级变高时,为避免b+tree
逐层搜索,AHI
能根据某个检索条件,直接查询到对应的数据页,跳过逐层定位的步骤。其次AHI会占用 1/16 的buffer pool
的大小,如果线上表数据不是特别大,不是超高并发,不建议将开启AHI,可以考虑关闭AHI
功能
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
在删除数据文件时,如果数据文件过大,删除过程会产生大量的IO
并耗费更多的时间,造成磁盘IO
开销飙升,CPU
负载过高,影响其他程序运行。我的一个好伙伴,就曾在线上库删除了一张 1TB 大小的表,结果20分钟,数据库无响应,最后库崩溃,重启了。
既然知道drop table
做了2件事情,那就针对以上 2 个事情进行优化
在清除Buffer Pool
缓冲上,为减少当个buffer pool
的大小,可以合理设置innodb_buffer_pool_instances
参数,减少buffer pool
数据块列表扫描时间,同时关闭AHI
功能
在步骤2上,可以巧妙的利用linux
的硬连接特性,延迟删除真正的物理文件。
当多个文件名同时指向同一个INODE
时,这个INODE
的引用数 N>1, 删除其中任何一个文件名都会很快.因为其直接的物理文件块没有被删除.只是删除了一个指针而已;当INODE
的引用数 N=1 时, 删除文件需要去把这个文件相关的所有数据块清除,所以会比较耗时;
如果给数据库表的.ibd
文件创建一个硬链接,当删除表时,删除物理文件时,其实删除的就是物理文件的一个指针,所以删除操作响应速度会非常快,大约不到1秒左右
下面就来演示一下具体的操作
1 2 3 4 |
|
最后就是要真正删除掉物理文件,释放文件所占用的磁盘空间,那么问题来了,如果优雅的删除物理文件呢,在这里推荐大家coreutils
工具集中的truncate
命令
当然需要你先安装相关的软件包
1 2 3 4 5 6 7 8 9 |
|
安装好之后,就可以写一个脚本,非常优雅的分布删除大文件,${i}G
表示,每次删除 10G
1 2 3 4 5 6 7 8 9 10 |
|
以上就是怎么drop掉mysql库中的1TB表单的详细内容,更多请关注php中文网其它相关文章!
联系客服