truncate table須知

背景

最近在排查問題的時候遇到truncate table阻塞了業務語句擷取MDL鎖，為此記錄下truncate table的東東以備後用

執行權限

drop table

SQL類型

DDL而不是DML，為什麼會這樣歸類呢？

• 先drop再create

  這樣清理表會快些，特别是對大表來說

• 會帶來隐式送出，且不能復原

  會帶來隐式的還有

  https://dev.mysql.com/doc/refman/5.6/en/implicit-commit.html
• 遇到其他session持有活動的表鎖該操作不會被執行
• 對于跟其他表有關聯外鍵的InnoDB和NDB表，truncate table會失敗
• truncate table 不像delete一樣可以傳回實際修改了多少行
• 對于自增值AUTO_INCREMENT會被歸0
• 隻要表名合法，即使資料或索引檔案被破壞的情況下，這個表可以被重新建立成一張空表。
• 對于分區表，truncate table之後還是保留分區結構，這是因為雖然資料檔案和索引檔案被drop然後重新建立，但是分區表定義檔案(.par)不受影響
• truncate table不會喚醒DELETE觸發器

1. table 會關閉所有已經打開的該表的檔案句柄。

binlog日志

在binlog日志裡面，對于InnoDB表或其他支援事務的引擎來說是先drop再create記錄的，而對于基于STATEMENT或者MIXED複制模式不會被記錄。

注意事項

如果一個系統的innodb buffer pool比較大并且開啟了

innodb_adaptive_hash_index

，truncate table 可能會引起暫時的性能下降，因為當删除InnoDB表的自适應hash簇時需要周遊LRU連結清單。

參考

https://dev.mysql.com/doc/refman/5.6/en/truncate-table.html