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文件，磁盘空间立刻下降。
- 确认方式：
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，备份恢复窗口极窄——这点比性能差异更值得盯紧。
