SQL 中批量删除数据，关键不在“删得多”，而在“删得稳、删得快、不锁表、不拖垮系统”。盲目用 DELETE FROM table WHERE ... 一次性删百万行，极易引发长事务、锁表、日志暴涨、主从延迟甚至 OOM。高效批量删除的核心是：分批控制、减少锁粒度、避开全表扫描、配合索引与事务管理。
按主键/索引范围分批删除（最推荐）
避免无条件或低效条件的 WHERE（如 WHERE status = 'old' 但 status 无索引），优先利用主键或高选择性索引做切片。例如：
假设要删除 orders 表中创建时间早于 2022 年的记录，且表有自增主键 id 和索引 idx_created_at：
- 先查出待删数据的最小和最大 id 范围：
SELECT MIN(id), MAX(id) FROM orders WHERE created_at - 按每 5000 行一批，用主键区间驱动删除：
DELETE FROM orders WHERE id BETWEEN 10000 AND 14999 AND created_at - 循环执行，每次更新区间，直到无匹配行。工具脚本中可自动推进起始 id。
优势：走索引、单次事务小、锁行不锁表、便于暂停/重试、对复制延迟影响小。
用 JOIN 或临时表辅助精准筛选
当删除条件复杂（如关联多表判断）、或目标数据分散难以用范围定位时，先落库再删更可控：
- 将待删主键存入临时表：
CREATE TEMPORARY TABLE tmp_del_ids AS SELECT id FROM orders o JOIN users u ON o.user_id = u.id WHERE u.status = 'inactive' AND o.created_at - 分批从临时表取 ID 删除主表：
DELETE o FROM orders o INNER JOIN tmp_del_ids t ON o.id = t.id ORDER BY t.id LIMIT 5000; - 删完一批后，从临时表中
DELETE FROM tmp_del_ids ORDER BY id LIMIT 5000，继续下一轮。
注意：临时表需建在相同库、加索引（如 ALTER TABLE tmp_del_ids ADD INDEX idx_id (id);），否则 JOIN 效率骤降。
善用分区表或归档替代删除
若业务允许，比“删”更高效的是“不删”：
- 对按时间划分的数据（如日志、订单），建
PARTITION BY RANGE (TO_DAYS(created_at))分区表，删除旧数据直接ALTER TABLE t DROP PARTITION p2021;—— 秒级完成，无锁、无日志压力。 - 无法改表结构？可新建归档表
orders_archive，用INSERT INTO ... SELECT ... LIMIT 10000分批导出旧数据，再DELETE对应批次——相当于把 I/O 和计算压力拆开，也便于校验。
归档后记得 OPTIMIZE TABLE（InnoDB 可选）或 ALTER TABLE ... ENGINE=InnoDB 回收空间（注意会锁表，建议低峰期）。
规避常见陷阱
这些细节常被忽略，却直接决定批量删除是否成功：
- 禁用 autocommit 后必须显式 COMMIT/ROLLBACK：脚本中开启事务后忘提交，会导致连接长期占用、锁不释放。
-
避免在 WHERE 中对字段做函数操作：如
WHERE DATE(created_at) 无法走索引，应改写为 <code>WHERE created_at 。 -
监控 slow log 和 performance_schema：重点关注
rows_affected、lock_time、tmp_tables，及时发现隐式全表扫描或临时表膨胀。 -
生产环境务必先在备库或影子库验证语句执行计划：用
EXPLAIN DELETE ...（MySQL 8.0+ 支持）确认是否命中预期索引。
不复杂但容易忽略。
