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造成一次隐式提交, 所以它不会被回滚。
- Truncate遇到会话持有表锁时不能被执行。
针对InnoDB or NDB表与其它表有外键约束关系,TRUNCATE TABLE
将会执行失败。同一张表的列之间有外键约束是允许的。
Truncate操作不会返回一个有意义删除的行数的值。通常的结果是“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可与Performance模式中的summary表一起使用,但结果是将summary列重置为0或NULL,而不是删除行。 请参见第23.9.15节“Performance Schema Summary Tables”。