1、背景在生产环境有可能有删除某个不重要大表的需求,因为大表占用的大量磁盘空间,如果我们直接drop掉此表,通常需要20秒以上的时间,总会觉得会卡主Mysql,现在给大家一个正确的删除姿势。2、首先我们查看
1、背景
在生产环境有可能有删除某个不重要大表的需求,因为大表占用的大量磁盘空间,如果我们直接drop掉此表,通常需要20秒以上的时间,总会觉得会卡主Mysql,现在给大家一个正确的删除姿势。
2、首先我们查看此大表
shell>ls log_api_call_01_01* -l
-rw-r----- 1 mysql mysql 9362 Jun 22 15:35 log_api_call_01_01.frm
-rw-r----- 1 mysql mysql 293334036112 Jun 22 15:38 log_api_call_01_01.ibd
shell>ln log_api_call_01_01.ibd log_api_call_01_01ibd.bak
shell>ls log_api_call_01_01* -l
-rw-rw—- 1 MySQL mysql 9362 Apr 14 23:03 log_api_call_01_01.frm
-rw-r----- 1 mysql mysql 293334036112 Jun 22 15:38 log_api_call_01_01.ibd
-rw-r----- 1 mysql mysql 293334036112 Jun 22 15:38 log_api_call_01_01.ibd.bak
mysql>drop table log_api_call_01_01;
Query Ok, 0 rows affacted(0.92 sec)
通过这样的操作,可以减少mysql drop大表hang住的时间,然后在业务低峰期再去删除真实的那个*.b文*.bak件。
至于原理:
就是利用OS HARD LINK的原理,
当多个文件名同时指向同一个Inode时,这个INODE的引用数N>1, 删除其中任何一个文件名都会很快.
因为其直接的物理文件块没有被删除.只是删除了一个指针而已;
当INODE的引用数N=1时, 删除文件需要去把这个文件相关的所有数据块清除,所以会比较耗时;
对于大表操作操作的其实几个Tips:
可以先用rename table替代drop table
mysql> rename table log_api_call_01_01 to log_api_call_01_01_bak;
删除物理文件
for i in `seq 100 -1 1 ` ;do sleep 2;sudo truncate -s ${i}G /data/mysql/manager/log_api_call_01_01.ibd.bak;done sudo rm -rf /data/mysql/manager/log_api_call_01_01.ibd.bak;
这个动作也很快只是相当于改一个文件名。
另外也可以考虑使用XFS文件系统,对于Drop表动作也比较快。
--结束END--
本文标题: MySQL大表删除正确的姿势
本文链接: https://lsjlt.com/news/45686.html(转载时请注明来源链接)
有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
2024-10-23
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
2024-10-22
回答
回答
回答
回答
回答
回答
回答
回答
回答
回答
0