TRUNCATE TABLE 能直接使用，但须满足三条件：表无外键引用、无需事务回滚、不依赖触发器；否则应改用带索引锚点和分批提交的 DELETE。
优先用 TRUNCATE TABLE，但必须确认表没被外键引用、不需要回滚、不依赖触发器——否则只能退到分批 DELETE FROM。
TRUNCATE TABLE 能不能直接上？先看这三个报错
执行 TRUNCATE TABLE 瞬间完成，但它不是万能钥匙。一执行就卡住或报错？基本逃不出这三类：
-
ERROR 1701 (HY000): Cannot truncate a table referenced in a foreign key constraint→ 表被其他表外键引用，得先SET FOREIGN_KEY_CHECKS = 0，删完立刻设回= 1 -
ERROR 1142 (42000): TRUNCATE command denied→ 当前账号缺DROP权限（不是DELETE权限），DBA 得补GRANT DROP ON db.table TO 'user'@'%' - 执行后
SELECT COUNT(*)是 0，但磁盘空间没缩？说明innodb_file_per_table = OFF，空间归还给共享表空间，OS 看不见——此时只能低峰期跑OPTIMIZE TABLE，或迁移到独立表空间
必须用 DELETE 时，别只靠 LIMIT 分批删
很多人以为 DELETE FROM t WHERE condition LIMIT 1000 就安全了，结果删着删着 SHOW PROCESSLIST 里全是 Waiting for table metadata lock，或者 innodb_log_waits 开始飙升。真正可控的写法要满足四个硬条件：
- WHERE 条件字段必须有索引（最好是主键或带索引的时间字段），否则每批都全表扫描，越删越慢
- 不能只靠
LIMIT，得锚定有序值做“滑动窗口”，例如：DELETE FROM logs WHERE created_at < '2022-01-01' AND id > @last_id ORDER BY id LIMIT 1000 - 每次删完必须
COMMIT，且应用层加SLEEP(0.1)控节奏，避免 I/O 打满 - 每批行数建议 1000–5000：超 5000 行 InnoDB 可能升级为页锁；低于 500 行事务开销占比过高
大表清空前必须检查的 4 件事
别急着敲命令，先验证这几点，否则可能锁库数小时或直接中断业务：
- 查外键依赖：
SELECT CONSTRAINT_NAME, TABLE_NAME, COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'your_table'; - 确认无活跃触发器：
SELECT * FROM INFORMATION_SCHEMA.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'your_table'; - 检查当前是否有长事务占着 MDL 锁：
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 60; - 验证磁盘空间是否足够容纳临时日志：
SHOW VARIABLES LIKE 'innodb_log_file_size';× 2，再留 20% 余量
最易被忽略的是：TRUNCATE 后 AUTO_INCREMENT 重置为 1，而 DELETE 不重置——如果下游有分库分表路由逻辑依赖 ID 连续性，这个差异会直接导致数据错位。
