MySQL大表删除正确的姿式

一、背景

在生产环境有可能有删除某个不重要大表的需求，由于大表占用的大量磁盘空间，若是咱们直接drop掉此表，一般须要20秒以上的时间，总会以为会卡主MySQL，如今给你们一个正确的删除姿式。

二、首先咱们查看此大表

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表动做也比较快。