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;
這個動作也很快只是相當於改一個文件名。
另外也可以考慮使用XFS文件系統，對於Drop表動作也比較快。