MySQL关键字之TRUNCATE

TRUNCATE TABLE 可以彻底清空一张表。但这个关键字需要DROP权限。

逻辑上, TRUNCATE TABLE 与 DELETE 语句非常相似，都可以删除所有的行数据, 或者可以理解为顺序执行DROP TABLE然后CREATE TABLE语句。为了获取高性能, 它绕过了DML方式去删除数据。除此之外, 它不能被回滚。它不会造成ON DELETE触发器触发，它不能被执行于InnoDB引擎里带有外键关系的父子表。

尽管 TRUNCATE TABLE 与 DELETE 比较相似, 它被归为DDL语句，而不是DML语句。在MySQL 5.7中与DELETE有以下不同的地方:

Truncate操作是删除并且重建这张表，比一行一行的删除数据要快很多，特别是数据量非常大的表。

Truncate操作造成一次隐式提交, 所以它不会被回滚。

Truncation操作遇到会话持有表锁时不能被执行。

针对InnoDB or NDB表与其它表有外键约束关系，TRUNCATE TABLE 将会执行失败。同一张表的列之间有外键约束是允许的。

Truncation操作不会返回一个有意义删除的行数的值。通常的结果是“0 rows affected,” 被解释成“no information.”

只要表结构文件tbl_name.frm有效，TRUNCATE TABLE之后这个表作为一个空表可以被重建, 尽管数据文件和索引文件已经损坏。

任何 AUTO_INCREMENT 列的值都被重置为初始值。MyISAM 和 InnoDB引擎下这个条件依然成立，一般不会复用序列值。

当使用分区表, TRUNCATE TABLE 保存分区信息; 那就是数据文件和索引文件先被删除然后重建, 然而分区定义文件(.par)file不受影响。

注意：
MySQL 5.7.6版本, 不再创建分区(.par) 文件。 相反, 分区定义存储在内部数据字典里。

TRUNCATE TABLE 语句 调用 ON DELETE 触发器。

TRUNCATE TABLE 为一张表关闭被HANDLER OPEN打开的所有的处理程序。

TRUNCATE TABLE 被用于二进制日志和复制目的是DROP TABLE 然后CREATE TABLE—即, DDL语句 而不是 DML语句。 这是出于这样的因素, 当使用InnoDB 和其它事务性存储引擎，事务隔离级别不允许基于语句的日志模式(READ COMMITTED or READ UNCOMMITTED), 当使用STATEMENT 或者 MIXED日志模式时，语句不被写入日志和复制(Bug #36763) 然而, 像之前描述的，它仍然应用于从库使用InnoDB复制的方式。

系统上有一个很大的InnoDB缓冲池和启用innodb_adaptive_hash_index, TRUNCATE TABLE 操作可能会导致一个临时系统性能下降，由于LRU扫描时删除InnoDB表的自适应哈希索引条目导致。删除表的问题是解决MySQL 5.5.23(错误# 64284,错误# 64284),但TRUNCATE TABLE 仍然是一个已知问题(错误# 68184)。

TRUNCATE TABLE can be used with Performance Schema summary tables, but the effect is to reset the summary columns to 0 or NULL, not to remove rows. See Section 23.9.15, “Performance Schema Summary Tables”.

---