TRUNCATE是删表重建而非逐行删除，其底层通过新建空表、丢弃原表.ibd文件、重命名实现，绕过行锁、undo日志与触发器；DELETE则逐行扫描、写undo、触发检查，性能随数据量陡增。

TRUNCATE是删表重建，不是逐行删除

很多人误以为TRUNCATE TABLE只是DELETE FROM的加速版，其实它根本没走InnoDB的数据行处理路径。它的底层动作是：新建一个空表结构、把原表数据文件（.ibd）直接丢弃、再把新表重命名为原名。整个过程绕过了行级锁、undo日志写入、逐行标记删除这些开销，自然快得多。

DELETE要记undo日志+触发器+逐行扫描

DELETE FROM t哪怕不带WHERE，InnoDB也必须按聚簇索引顺序一行一行扫过去，对每条记录做三件事：写undo日志（支持回滚）、打删除标记、检查并触发BEFORE/AFTER DELETE触发器。数据量越大，undo日志暴涨、purge线程压力越大、锁等待越明显——这不是“慢”，而是设计使然。

• 500万行表实测：DELETE耗时6分钟，TRUNCATE仅2秒
• 大表DELETE期间可能拖垮从库延迟，TRUNCATE几乎不影响复制链路
• DELETE产生的binlog是逐行事件（ROW格式）或全表扫描事件（STATEMENT格式），而TRUNCATE只记一条DDL语句

TRUNCATE不释放空间？要看表空间模式

很多人执行TRUNCATE TABLE后发现.ibd文件大小没变，就怀疑“没生效”。这通常是因为启用了innodb_file_per_table=OFF，数据被存进系统表空间（ibdata1），TRUNCATE只能回收内部页，无法返还给操作系统。换成ON后，TRUNCATE会直接删除并重建独立.ibd文件，磁盘空间立刻下降。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 确认方式：SELECT @@innodb_file_per_table;
• 切换风险：需重启MySQL且涉及全局表空间迁移，生产环境慎操作
• 即使空间未缩，TRUNCATE后插入新数据也会复用刚清出的页，不像DELETE残留大量碎片

权限和外键约束让TRUNCATE更“挑剔”

TRUNCATE TABLE需要DROP权限，不是DELETE权限；如果表被其他表用外键引用，MySQL默认拒绝TRUNCATE（除非先禁用foreign_key_checks）。这点常被忽略，导致脚本在测试库跑通、上线就报错ERROR 1701 (42000)。

• 检查外键依赖：SELECT CONSTRAINT_NAME, TABLE_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'your_table';
• 临时关闭外键检查仅限单次会话：SET FOREIGN_KEY_CHECKS = 0;，但务必配对恢复
• 注意：从库上TRUNCATE会传播为DDL事件，若主从版本不一致（如5.7主 + 8.0从），可能引发复制中断

真正危险的不是TRUNCATE快，而是它快得让人忘了确认“是否真要清空全部”。一旦执行，没有ROLLBACK，binlog里只有一行DDL，备份恢复窗口极窄——这点比性能差异更值得盯紧。