背景

最近在排查问题的时候遇到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