TRUNCATE TABLE最快但不总是安全，需根据并发写入、外键依赖和结构保留需求选择操作路径：被引用时失败、隐式提交不可回滚、重置自增ID；DELETE适合条件清空或需事务控制场景。
直接 TRUNCATE TABLE 最快，但不是所有场景都安全；真正要“安全清空”，得看表是否被并发写入、是否有外键依赖、是否需要保留表结构但删光数据——这三类情况对应三种完全不同的操作路径。
TRUNCATE TABLE 为什么有时不能用
它快（毫秒级），但会重置自增主键、隐式提交、无法回滚，且在以下情况会失败或引发连锁问题：
- 表被其他事务正在读/写：
ERROR 1785 (HY000): When @@GLOBAL.ENFORCE_GTID_CONSISTENCY = 1, statements that cause implicit commits are not allowed - 表有外键被引用：
ERROR 1701 (HY000): Cannot truncate a table referenced in a foreign key constraint - 使用 InnoDB 且启用了
innodb_file_per_table=OFF：TRUNCATE 实际是 DROP + CREATE，会触发全局表空间重建，可能卡住 purge 线程 - 应用层没做表不存在兜底：TRUNCATE 后立刻查表，直接报
Table 'db.t' doesn't exist，而非空结果集
DELETE FROM ... LIMIT + 主键滑动窗口（适合需条件过滤的清空）
当你要“清空”其实是“删掉旧数据、留最新 N 条”，或者 WHERE 条件不能覆盖全表时，必须用带主键切片的分批 DELETE，而不是裸 DELETE FROM t LIMIT 1000：
- 错误写法：
DELETE FROM log_table WHERE created_at —— 若 <code>created_at无索引或重复值多，每批都全表扫描，越删越慢 - 正确做法：先确保
id是主键或有高效索引，然后按范围推进：DELETE FROM log_table WHERE id > 1000000 AND id - 每次执行前查下一批起始：
SELECT MIN(id) FROM log_table WHERE id > @last_id AND created_at - 务必显式事务：
START TRANSACTION; ... COMMIT;，避免 autocommit=1 导致日志刷写风暴
RENAME + DROP（最稳妥的“逻辑清空”）
适用于真正要彻底删光、且允许短暂业务报错（如凌晨维护窗口）的场景。核心是把“删数据”变成“换表名+后台清理”：
- 第一步原子重命名：
RENAME TABLE big_log TO big_log_to_drop—— 耗时 - 第二步异步清理：
DROP TABLE big_log_to_drop—— 放后台慢慢 purge，不影响线上 - 关键前提：应用必须能容忍“表不存在”错误并自动重试或降级，否则请求直接 500
- 若表有外键，先禁用检查：
SET FOREIGN_KEY_CHECKS = 0;，删完再开
INSERT INTO ... SELECT + RENAME（删多留少时最快）
当你要清空的是“99% 的数据”，只留最新几十万行，这个方案比任何 DELETE 都快，且不锁原表：
- 建空表：
CREATE TABLE big_log_new LIKE big_log - 搬幸存数据：
INSERT INTO big_log_new SELECT * FROM big_log WHERE id > 9900000（假设最大 id 是 1000 万） - 原子切换：
RENAME TABLE big_log TO big_log_old, big_log_new TO big_log - 注意：目标字段顺序、默认值、注释需严格一致；时间戳字段如
created_at DEFAULT CURRENT_TIMESTAMP在 INSERT 时不自动填充，需显式指定
最容易被忽略的点：无论选哪种方式，innodb_change_buffering 建议临时设为 none（尤其在 DELETE 或 DROP 前），否则大量随机页更新会拖慢 purge 进度；另外，删完别急着 OPTIMIZE TABLE —— 它会锁表、重建 B+ 树，在大表上可能比删本身还慢。
