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表動做也比較快。