仅靠 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 <p>下一批就改成 <code>id > 1001000 AND id 。关键点：</code></p><div class="aritcle_card flexRow artxards"> <div class="artcardd flexRow"> <a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill2334" title="MySQL"><img src="https://img.php.cn/upload/skill/000/000/081/178900927846657.jpg" alt="MySQL" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a> <div class="aritcle_card_info flexColumn"> <a rel="nofollow" href="/xiazai/skill2334" title="MySQL" class="overflowclass">MySQL</a> <p class="overflowclass">编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。</p> </div> <a rel="nofollow" href="/xiazai/skill2334" title="MySQL" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span> </a> </div> </div>
- 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 <p>END WHILE;
END //
DELIMITER ;</p>
-
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 重建或考虑归档到冷表。
