背景
最近在排查问题的时候遇到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触发器
- table 会关闭所有已经打开的该表的文件句柄。
binlog日志
在binlog日志里面，对于InnoDB表或其他支持事务的引擎来说是先drop再create记录的，而对于基于STATEMENT或者MIXED复制模式不会被记录。
注意事项
如果一个系统的innodb buffer pool比较大并且开启了innodb_adaptive_hash_index ，truncate table 可能会引起暂时的性能下降，因为当删除InnoDB表的自适应hash簇时需要遍历LRU链表。
