TRUNCATE TABLE 不支持 WHERE 条件，因其本质是 DDL 操作，通过释放数据页、重置高水位线和自增计数器来快速清空整表，不扫描行、不写行级日志，故语法上禁止条件且无法实现部分删除。
直接用 TRUNCATE TABLE 最快，但前提是能接受“整表清空、不可回滚、自增ID重置、外键约束报错”这四个硬限制；如果只是删大部分数据（比如留1%），TRUNCATE 就完全不能用，必须换策略。
为什么 TRUNCATE TABLE 不能加 WHERE 条件？
它根本不是 DML 操作，而是 DDL：MySQL 内部会先 DROP 原表，再按原结构重建一个空表。所以语法上就不允许写条件——TRUNCATE TABLE users WHERE status = 'inactive' 会直接报 ERROR 1064。有人试过给字段加索引想“加速条件截断”，毫无意义，因为 TRUNCATE 根本不查数据。
常见误判点：
- 以为在事务里执行
TRUNCATE能回滚 → 实际上它会隐式提交，事务立刻结束 - 在有外键引用的表上执行 → MySQL 直接报错，PostgreSQL 默认级联清空（可能误删其他表）
- 清完发现自增主键从 1 开始 → 这是正常行为，
DELETE才保留原值
删 90% 以上数据时，别碰 DELETE，用“创建-迁移-替换”法
当你要保留的数据远少于要删的（例如 1.6 亿行中只留 250 万），逐条 DELETE 不仅慢，还会让 undo log 疯涨、锁表十几分钟、主从延迟飙升。此时最稳的方式是绕开删除本身：
- 用
CREATE TABLE new_table LIKE old_table复制结构（含索引、字符集、分区规则） -
INSERT INTO new_table SELECT * FROM old_table WHERE keep_condition—— 这步要确保keep_condition走索引，否则全表扫描更伤 -
RENAME TABLE old_table TO old_table_bak, new_table TO old_table—— 原子操作，业务无感 - 确认新表数据、查询、写入都正常后，再
DROP TABLE old_table_bak
注意：如果原表用了 AUTO_INCREMENT，新表的起始值默认为 1，需手动 ALTER TABLE new_table AUTO_INCREMENT = N 补上。
必须带条件删、且无法建新表？那就分批，但别用 LIMIT ... OFFSET
比如要删所有 create_time 的日志，又不能停业务，只能分批 <code>DELETE。但千万别写 DELETE ... LIMIT 1000 OFFSET 1000000 —— OFFSET 越大，MySQL 越要先扫 100 万行才能跳到下一批，实际是 O(n²) 复杂度。
正确做法是基于主键或时间字段做游标分片：
- 先查出最小
id：SELECT MIN(id) FROM logs WHERE create_time - 循环执行：
DELETE FROM logs WHERE id BETWEEN ? AND ? AND create_time - 每次取完一批后，把
?更新为上一批最大id + 1，避免重复或遗漏 - 每批后
COMMIT并SLEEP 0.1，防止 I/O 扛不住
关键点：条件字段（如 create_time）和分片字段（如 id）必须都有索引，否则还是全表扫。
真正容易被忽略的是磁盘空间——哪怕你用 TRUNCATE 或替换法，InnoDB 表空间文件（.ibd）通常不会自动缩回，删完可能仍占上百 GB。需要后续执行 OPTIMIZE TABLE（会锁表）或考虑启用 innodb_file_per_table=ON + ALTER TABLE ... ENGINE=InnoDB 重建，但这又是一轮资源消耗。线上操作前，务必在从库或测试环境跑通全流程。
