必须用主键范围切片而非 limit + order by：因无索引时 limit 全表扫描，order by id 导致每轮排序+跳过已处理行而越删越慢；应按主键“滑动窗口”推进，如 delete from logs where id > @last_id and id
不能靠 DELETE ... LIMIT 循环加 COMMIT 就算完事——没走索引、没控节奏、没显式事务边界，照样卡死 MDL 锁、拖垮主从同步。
必须用主键范围切片，而不是 LIMIT + ORDER BY
MySQL 的 LIMIT 在无索引 WHERE 下会全表扫描；加上 ORDER BY id 后，每轮仍要排序+跳过已处理行，越删越慢。真正可扩展的做法是按主键值“滑动窗口”推进：
DELETE FROM logs WHERE id > 1000000 AND id- 下一批改用
id > 1001000 AND id ，依此类推 - 起始值必须来自
SELECT MIN(id) FROM logs WHERE id > @last_id AND created_at ，避免因主键空洞漏删 - 若表无主键或主键稀疏，改用带索引的
created_at字段，但得加id做二级去重（防时钟重复）
存储过程里必须显式控制事务与延迟
默认 autocommit=1 会让每条 DELETE 成独立事务，日志刷写频繁；设成 0 又容易忘 COMMIT，锁住 MDL。正确做法是在存储过程中手动开事务、提交、休眠：
- 每次只删 5000～10000 行，
DELETE ... WHERE id BETWEEN x AND y必须命中索引 - 执行后立刻
COMMIT，释放锁和 undo 空间 - 加
DO SLEEP(0.1)或SELECT SLEEP(0.1)控制节奏，防止 I/O 打满 - 循环退出条件不是“删完为止”，而是
ROW_COUNT() = 0或总耗时超阈值（防误写条件无限删）
SQL Server 的 TOP + WHILE 方案要注意锁升级
SQL Server 默认在 5000 行锁后自动升级为表锁，TOP (10000) 极易触发。不加干预，删着删着就阻塞所有查询：
- 删前执行
ALTER TABLE logs SET (LOCK_ESCALATION = DISABLE)（仅限 SQL Server 2008+） -
WHERE条件字段（如created_date）必须有索引，否则每次全表扫描 - 每批后加
CHECKPOINT（简单恢复模式下促日志截断） - 用
WAITFOR DELAY '00:00:00.01'缓解压力，尤其高峰时段
最容易被忽略的是：删完不 ANALYZE TABLE，后续查询可能持续走错执行计划；碎片率高了也不 OPTIMIZE TABLE（或等下次维护窗口），缓冲池压力会悄悄累积。这些动作不是“做完就结束”的收尾，而是删除操作本身的一部分。
