13.1.34 TRUNCATE TABLE 语句
TRUNCATE [TABLE] tbl_name
TRUNCATE TABLE完全清空一张桌子。它需要DROP特权。
从逻辑上讲,TRUNCATE TABLE类似于删除所有行或DROP TABLE和CREATE TABLE语句序列的DELETE语句。为了获得高性能,它绕过了删除数据的 DML 方法。因此,它无法回滚,也不会引发ON DELETE
触发器,并且无法对具有父子外键关系的InnoDB
table 执行该操作。
尽管TRUNCATE TABLE与DELETE类似,但它被分类为 DDL 语句而不是 DML 语句。它与DELETE在以下方面不同:
-
截断操作可删除并重新创建 table,这比逐行删除行要快得多,尤其是对于大型 table。
-
截断操作会导致隐式提交,因此无法回滚。参见第 13.3.3 节“导致隐式提交的声明”。
-
如果会话持有活动 table 锁,则无法执行截断操作。
-
如果
InnoDB
table 或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的系统上,由于在删除InnoDB
table 的自适应哈希索引条目时发生 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”。