仅靠 LIMIT 分批删除不安全，因未走索引会导致全表扫描、无 ORDER BY 易漏删重删、autocommit 设置不当易卡锁、缺乏延迟会打满 I/O，必须配合主键切片、显式事务和节奏控制。
直接 DELETE FROM table WHERE ... LIMIT N 不够安全，必须配合主键切片、显式事务控制和延迟节奏才能避免锁表和日志暴涨。
为什么不能只靠 LIMIT 分批删
很多人看到 LIMIT 就以为万事大吉，但实际踩坑最多的是：WHERE 条件没走索引、主键不连续、事务没提交、没控速。结果是——删着删着发现 SHOW PROCESSLIST 里全是 Waiting for table metadata lock，或者 innodb_log_waits 开始飙升。
- 没索引的 WHERE 条件会导致全表扫描，每批都扫一遍，越删越慢
- 用
DELETE ... LIMIT 1000但没加ORDER BY primary_key，可能重复删或漏删（尤其并发写入时） - 默认 autocommit=1 时，每条 DELETE 是独立事务，但日志刷写频率高；设成 autocommit=0 又容易忘 COMMIT，卡住 MDL 锁
- 不加延迟的话，5000 行/秒的删除速度可能瞬间打满 I/O，拖垮其他查询
必须用主键范围分片（不是 OFFSET 分页）
OFFSET 分页在大表上会越来越慢，因为 MySQL 仍要跳过前面所有行。正确做法是按主键值“滑动窗口”：
DELETE FROM orders WHERE status = 'cancelled' AND id > 1000000 AND id <= 1001000;
下一批就改成 id > 1001000 AND id 。关键点：
- WHERE 中必须包含
id > @last_id，不能只靠LIMIT - 先查出下一批起始 ID：
SELECT MIN(id) FROM orders WHERE id > @last_id AND status = 'cancelled' LIMIT 1 - 如果表无主键或主键稀疏，改用带索引的自增时间字段（如
created_at），但要注意时钟重复问题
存储过程中要显式控制事务与延迟
MySQL 存储过程里别依赖默认行为。下面这段逻辑能跑通，但生产环境必须调参：
DELIMITER //
CREATE PROCEDURE batch_delete_orders()
BEGIN
DECLARE done INT DEFAULT FALSE;
DECLARE low_id BIGINT DEFAULT 0;
DECLARE high_id BIGINT;
DECLARE batch_size INT DEFAULT 1000;
<p>WHILE NOT done DO
SELECT MIN(id) INTO high_id
FROM orders
WHERE id > low_id AND status = 'cancelled'
ORDER BY id
LIMIT 1 OFFSET batch_size - 1;</p><pre class='brush:php;toolbar:false;'>IF high_id IS NULL THEN
SET done = TRUE;
ELSE
DELETE FROM orders
WHERE id > low_id AND id <= high_id AND status = 'cancelled';
SET low_id = high_id;
DO SLEEP(0.05); -- 每批后强制暂停，单位秒
END IF;END WHILE; END // DELIMITER ;
-
DO SLEEP(0.05)是硬性要求，别省；0.05–0.2 秒之间根据负载调整 - 删除后建议手动执行
ANALYZE TABLE orders，否则优化器可能沿用旧统计信息，后续查询变慢 - 别在存储过程中塞太多逻辑（比如嵌套循环查 COUNT），容易超时或锁死
删完别忘了检查日志与统计信息
很多人删完就收工，但以下两件事不做，等于白删：
- 检查
SHOW GLOBAL STATUS LIKE 'Innodb_log_waits'，值大于 0 说明日志空间持续紧张，下次得调大innodb_log_file_size - 运行
SELECT table_name, table_rows FROM information_schema.tables看行数是否准——不准就说明统计信息没更新，ANALYZE TABLE没生效 - 如果用了
foreign_key_checks = 0，删完务必设回 1，否则后续 DDL 可能静默失败
最易被忽略的是：删除操作本身不释放磁盘空间（InnoDB 表空间不会自动收缩），OPTIMIZE TABLE 成本极高，一般不推荐；真正要腾空间，得用 mysqldump 重建或考虑归档到冷表。
