13.1.34 TRUNCATE TABLE 语句

TRUNCATE [TABLE] tbl_name

TRUNCATE TABLE完全清空一张桌子。它需要DROP特权。

从逻辑上讲，TRUNCATE TABLE类似于删除所有行或DROP TABLE和CREATE TABLE语句序列的DELETE语句。为了获得高性能，它绕过了删除数据的 DML 方法。因此，它无法回滚，也不会引发ON DELETE触发器，并且无法对具有父子外键关系的InnoDBtable 执行该操作。

尽管TRUNCATE TABLE与DELETE类似，但它被分类为 DDL 语句而不是 DML 语句。它与DELETE在以下方面不同：

• 截断操作可删除并重新创建 table，这比逐行删除行要快得多，尤其是对于大型 table。

• 截断操作会导致隐式提交，因此无法回滚。参见第 13.3.3 节“导致隐式提交的声明”。

• 如果会话持有活动 table 锁，则无法执行截断操作。

• 如果InnoDBtable 或NDBtable 的其他 table 引用了FOREIGN KEY约束，则TRUNCATE TABLE失败。允许在同一 table 的列之间使用外键约束。

• 截断操作不会为删除的行数返回有意义的值。通常的结果是“受影响的 0 行”，应解释为“无信息”。

• 只要 table 格式文件tbl_name.frm有效，就可以使用TRUNCATE TABLE将 table 重新创建为空 table，即使数据或索引文件已损坏。

• 任何AUTO_INCREMENT值都将重置为其初始值。即使是MyISAM和InnoDB，也是如此，它们通常不重用序列值。

• 与分区 table 一起使用时，TRUNCATE TABLE保留分区；也就是说，数据和索引文件被删除并重新创建，而分区定义(.par)文件不受影响。

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

table 格的TRUNCATE TABLE关闭使用HANDLER OPEN打开的 table 格的所有处理程序。

出于二进制日志记录和复制的目的，TRUNCATE TABLE被视为DROP TABLE，然后是CREATE TABLE，即 DDL 而不是 DML。这是由于以下事实：在使用InnoDB和其他事务隔离级别不允许基于语句的日志记录(READ COMMITTED或READ UNCOMMITTED)的事务存储引擎时，在使用STATEMENT或MIXED日志记录模式时未记录并复制该语句。 (缺陷号 36763)但是，它仍以前述方式使用InnoDB应用于复制从属。

在具有大型InnoDB缓冲池并启用innodb_adaptive_hash_index的系统上，由于在删除InnoDBtable 的自适应哈希索引条目时发生 LRU 扫描，因此TRUNCATE TABLE操作可能会导致系统性能暂时下降。在 MySQL 5.5.23 中解决了DROP TABLE的问题(错误#13704145，错误#64284)，但对于TRUNCATE TABLE仍然是已知问题(错误#68184)。

TRUNCATE TABLE可以与 Performance Schema 摘要 table 一起使用，但是效果是将摘要列重置为 0 或NULL，而不是删除行。参见第 25.12.15 节，“性能架构摘要 table”。