作者簡介

肖鵬

微博研發中心資料庫技術負責人，主要負責微博資料庫（MySQL/Reids/HBase/Memcached）相關的業務保障，效能優化，架構設計以及周邊的自動化系統建設。10年網際網路資料庫架構和管理經驗，專注於資料庫的高效能和高可用技術保障方向。

眾所周知drop table會嚴重的消耗伺服器IO效能，如果被drop的table容量較大，甚至會影響到線上的正常。

首先，我們看一下為什麼drop容量大的table會影響線上服務

---

直接執行drop table，mysql會將表定義和表資料全都刪除，包括磁碟上的物理檔案，也包括buffer pool中的記憶體資料。

這就分兩步，第一步從buffer pool中刪除

，這會涉及到table_cache的lock，如果持有table_cache的lock，這將導致其他查詢都無法執行。這種情況在沒有innodb_per_table之前尤為嚴重。另外，mysql 5.5.23之後新增lazy drop table功能，這個功能用來解決mutex on the LRU list。其中心思想就是加鎖，找到需要被刪除的page，刪除1024個page之後釋放鎖讓其他thread工作，之後loop。

而percona的lazy drop處理起來更優雅一些，其會先加鎖，然後找到需要被刪除的page，標記，釋放鎖，後臺慢慢刪除。

之後就是第二步，這步在大容量表的時候更為消耗時間，那就是在os上刪除物理檔案

。大家都知道在ext3上rm一個200G的檔案會非常耗時，這是由於ext3儲存資料的結構導致，如果一個很大的檔案，ext3的i_block無法直接存放，需要多層巢狀才能完全儲存下，在這種情況下由於對映的層次多，並且由於多層對映也不會是順序儲存的，就導致了很大的隨機IO，這就導致了刪除物理檔案非常慢的現象。在這種情況下，建議升級到ext4，這是由於ext4比ext3使用extent分配儲存空間，其最大的優勢就是順序儲存。

ext3：

ext4：

知道了原因，我們來說說如何解決。具體步驟如下：

---

1、建立硬連結。

ln table.ibd table.idb.hdlk

2、mysql執行drop table操作。

drop table if exists tablename；

3、使用truncate刪除物理檔案。

truncate -s 1024*1024*4 filename

其實硬連結和drop table就不用多說了，在建立硬連結之後，mysql會認為rm了硬連結檔案之後就算操作完畢，不會真正去刪除物理檔案從而提高了速度。但是對於伺服器來說，實際的物理檔案還在，如果手動rm，還是會產生很多的io影響，這時候就用到了truncate這個工具。這個工具會根據指定的size大小進行逐步刪除，會將對IO造成的影響降到最低。