作者簡介
肖鵬
微網誌研發中心資料庫技術負責人，主要負責微網誌資料庫（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、建立硬連結。
2、mysql執行drop table操作。
3、使用truncate删除實體檔案。
其實硬連結和drop table就不用多說了，在建立硬連結之後，mysql會認為rm了硬連結檔案之後就算操作完畢，不會真正去删除實體檔案進而提高了速度。但是對于伺服器來說，實際的實體檔案還在，如果手動rm，還是會産生很多的io影響，這時候就用到了truncate這個工具。這個工具會根據指定的size大小進行逐漸删除，會将對io造成的影響降到最低。