应优先使用 TRUNCATE TABLE 清空整表，因其直接释放数据页、瞬时完成、不触发触发器；仅当需保留自增值、执行级联删除或条件删除时才用 DELETE。
直接清空表用 TRUNCATE，别用 DELETE（除非要触发器或条件删除）
想快速清空整张表？TRUNCATE TABLE 是唯一合理选择。DELETE FROM table_name 看似一样，但底层机制完全不同：它逐行扫描、逐行标记、走事务日志、支持回滚，还可能触发 ON DELETE 规则；而 TRUNCATE 是 DDL 操作，直接释放数据页，不记逐行日志，不可回滚，也不触发触发器。
常见错误现象：DELETE 在百万级表上执行几十秒甚至卡住，SHOW PROCESSLIST 显示状态为 Updating 或 Writing to net；而 TRUNCATE 几乎瞬时完成。
-
TRUNCATE要求对表有DROP权限（MySQL 8.0+ 默认包含在ALTER中），不是所有应用账号都具备 -
TRUNCATE会重置AUTO_INCREMENT计数器，DELETE不会（除非显式ALTER TABLE ... AUTO_INCREMENT = 1） - 如果表被外键引用（且未启用
FOREIGN_KEY_CHECKS=0），TRUNCATE直接报错：Cannot truncate a table referenced in a foreign key constraint
TRUNCATE 失败的三个典型场景及绕过方式
不是所有表都能无脑 TRUNCATE。以下情况会直接报错，必须提前识别：
- 表被其他表通过外键引用 → 先执行
SET FOREIGN_KEY_CHECKS = 0，再TRUNCATE，完后记得SET FOREIGN_KEY_CHECKS = 1 - 使用了
MyISAM引擎以外的引擎（比如InnoDB）但开启了innodb_file_per_table=OFF→TRUNCATE仍有效，但不会立即释放磁盘空间（需后续OPTIMIZE TABLE） - 表上有活跃的事务或锁（如长事务未提交）→
TRUNCATE会被阻塞，查INFORMATION_SCHEMA.INNODB_TRX定位并 kill 掉对应线程
注意：TRUNCATE 是隐式提交操作，执行后无法回滚，也不受当前事务控制。
DELETE 什么时候不得不选？看这三点硬约束
只有当满足以下任一条件时，才应放弃 TRUNCATE，改用 DELETE：
- 需要保留
AUTO_INCREMENT当前值（比如下游依赖自增 ID 连续性） - 表上有
ON DELETE CASCADE或ON DELETE SET NULL触发逻辑，且你希望这些动作被执行 - 只清空部分数据（哪怕写成
DELETE FROM t WHERE 1=1）——这种写法看似全删，但仍是逐行操作，性能灾难，纯属反模式
若真要用 DELETE 清空全表，务必加 WHERE 子句（哪怕恒真），否则 MySQL 5.7+ 会报错（ERROR 1175）；同时确认 SQL_SAFE_UPDATES=0 已关闭，否则执行失败。
清空后磁盘空间没释放？别急着 OPTIMIZE TABLE
TRUNCATE 后 SELECT COUNT(*) 返回 0，但 du -sh /var/lib/mysql/dbname/table.ibd 发现文件大小没变——这是 InnoDB 正常行为。因为 TRUNCATE 只是把数据页归还给表空间，并不收缩物理文件。
- 如果用的是共享表空间（
innodb_file_per_table=OFF），空间会留给整个实例复用，无需干预 - 如果启用了
innodb_file_per_table=ON（推荐），且希望立刻回收磁盘空间，才需执行OPTIMIZE TABLE table_name -
OPTIMIZE TABLE本质是重建表，期间加排他锁，大表会阻塞读写；生产环境建议配合维护窗口或用pt-online-schema-change
真正容易被忽略的是：很多 DBA 在 TRUNCATE 后立刻 OPTIMIZE，却忘了检查 innodb_file_per_table 设置，结果白等十分钟还发现空间没少。
