TRUNCATE [TABLE] tbl_name
TRUNCATE TABLE完全清空一张桌子。它需要DROP
特权。
从逻辑上讲，TRUNCATE TABLE类似于DELETE删除所有行的语句，或一系列DROP
TABLEandCREATE TABLE
语句。为了实现高性能，它绕过了删除数据的DML方法。因此，它不能回滚，它不会导致ON DELETE触发器触发，也不能对InnoDB具有父子外键关系的表执行。
虽然TRUNCATE TABLE类似于DELETE，但它被归类为 DDL 语句而不是 DML 语句。它
DELETE在以下方面有所不同：
截断操作删除并重新创建表，这比一行一行地删除行要快得多，特别是对于大表。
截断操作会导致隐式提交，因此无法回滚。请参阅第 13.3.3 节，“导致隐式提交的语句”。
如果会话持有活动表锁，则无法执行截断操作。
TRUNCATE TABLE如果存在 来自引用该表的其他表的任何约束，则该InnoDB表或 表将失败 。允许同一个表的列之间的外键约束。NDBFOREIGN KEY截断操作不会为已删除的行数返回有意义的值。通常的结果是“ 0 行受影响”，这应该被解释为“没有信息。”
只要表格式文件
tbl_name.frmTRUNCATE TABLE，即使数据或索引文件已损坏。任何
AUTO_INCREMENT值都将重置为其起始值。即使对于通常不重用序列值 的MyISAM和也是如此。InnoDB与分区表一起使用时，
TRUNCATE TABLE保留分区；也就是说，数据和索引文件被删除并重新创建，而分区定义 (.par) 文件不受影响。该
TRUNCATE TABLE语句不调用ON DELETE触发器。
TRUNCATE TABLEfor a table 关闭用打开的表的所有处理程序
HANDLER OPEN。
TRUNCATE TABLE出于二进制日志记录和复制的目的而被处理为
- 即，作为DROP TABLEDDL
CREATE TABLE而不是 DML。这是因为，当使用
InnoDB事务隔离级别不允许基于语句的日志记录（READ
COMMITTED或）的其他事务存储引擎时，在使用或
日志记录模式READ
UNCOMMITTED时不会记录和复制语句。（错误号 36763）但是，它仍然
以前面描述的方式应用于副本。
STATEMENTMIXEDInnoDB
在具有大型InnoDB缓冲池并
已innodb_adaptive_hash_index
启用的系统上，由于在删除表的自适应哈希索引条目TRUNCATE TABLE时发生的 LRU 扫描，操作可能会导致系统性能暂时下降。InnoDB该问题已
DROP TABLE在 MySQL 5.5.23（错误#13704145、错误#64284）中得到解决，但仍然是
TRUNCATE TABLE（错误#68184）的已知问题。
TRUNCATE TABLE可以与 Performance Schema 汇总表一起使用，但效果是将汇总列重置为 0 或NULL，而不是删除行。请参阅第 22.12.9 节，“性能模式摘要表”。