优先用 TRUNCATE TABLE 清空大表，因其直接释放数据页、仅记一条DDL日志，比逐行写undo/redo的DELETE快得多；但需满足无事务回滚需求、无触发器依赖、无外键引用且有DROP权限。
清空大表数据，优先用 TRUNCATE TABLE，而不是 DELETE FROM；但前提是：你不需要事务回滚、不依赖触发器、没有外键被其他表引用、且有 DROP 权限。
为什么 TRUNCATE 比 DELETE 快得多
TRUNCATE 不是逐行操作，它直接释放整张表的数据页（包括 .ibd 文件重建），只在日志里记一条 DDL 语句；而 DELETE 是 DML，每删一行都写 undo 和 redo 日志，还要加行锁、维护 MVCC 版本链。表越大，DELETE 耗时越不成比例——比如千万级表，DELETE FROM t 可能卡住十几分钟甚至更久，期间还可能拖慢其他查询。
常见错误现象：DELETE FROM big_table 执行半天没反应、SHOW PROCESSLIST 显示 Updating 状态、innodb_row_lock_waits 暴涨。
-
TRUNCATE在 InnoDB 中本质是“删表重建”：先 drop 原表，再用原名新建空表（结构不变） - 所以它会重置自增 ID（
AUTO_INCREMENT回到 1），而DELETE不会 -
TRUNCATE不走触发器，DELETE会触发BEFORE/AFTER DELETE
TRUNCATE 在什么情况下会失败
不是所有表都能安全 TRUNCATE，遇到以下任一条件就会报错：
- 表被其他表通过外键（
FOREIGN KEY）引用 —— 报错Cannot truncate a table referenced in a foreign key constraint - 当前用户没有
DROP权限（因为TRUNCATE隐式需要该权限） - 表正在被某个活跃事务持有元数据锁（
MDL），比如另一个连接正在执行ALTER TABLE或长事务未提交
此时只能退回到 DELETE，但必须加 WHERE 1=1 分批删，否则风险极高。
大表清空的折中方案：分批 DELETE + 空间回收
当 TRUNCATE 不可用，又不能接受单次 DELETE 锁表太久时，用带主键范围的分批删除：
DELETE FROM big_table WHERE id BETWEEN 1 AND 10000; DELETE FROM big_table WHERE id BETWEEN 10001 AND 20000;
注意要点：
- 务必基于主键或有高效索引的列做范围，避免全表扫描
- 每次删除后
COMMIT，防止事务过大撑爆undo log - 删完后执行
OPTIMIZE TABLE big_table—— 否则 InnoDB 不会真正释放磁盘空间（DATA_LENGTH不变） - 如果表有大量二级索引，分批删反而比
TRUNCATE慢很多，这时应评估是否可临时禁用外键约束或改用pt-archiver
误用 DROP 当 TRUNCATE 的危险
有人看到 TRUNCATE 失败，顺手改成 DROP TABLE big_table; CREATE TABLE ...，这是高危操作：
-
DROP会彻底删除表定义、分区、索引、触发器、权限绑定，重建时极易遗漏 -
DROP过程中 buffer pool 会被大量刷脏页，可能引发 IO 尖峰，影响线上查询延迟 - 如果表名被视图、存储过程、应用代码硬编码引用，
DROP后这些对象立即失效
真正要清空数据，就别碰 DROP —— 它解决的是“不要这张表了”，不是“只要空壳”。
