长事务删除会卡死数据库，因其长期持有大量行锁、可能全表加锁，并导致binlog/redo log膨胀；应按主键分批删除，每批独立事务+COMMIT，避免LIMIT循环和非安全WHERE条件。
为什么长事务删除会卡死数据库
长事务删除本质是把大量行锁一直占着不放，直到整个事务提交。MySQL 的 DELETE 在非只读隔离级别下会加行级锁（甚至可能升级为间隙锁），锁住的范围远超实际要删的行——尤其带 WHERE 条件但没走索引时，容易全表扫描+全表加锁。另一个隐形杀手是 binlog 和 redo log 持续膨胀，主从延迟、刷盘压力、甚至磁盘打满都可能由此触发。
常见错误现象：SHOW PROCESSLIST 里看到状态长期卡在 Updating 或 Waiting for table metadata lock；监控里 Innodb_row_lock_time_avg 突增；从库 SQL 线程延迟飙升。
- 别指望加索引就万事大吉——即使走了索引，如果删除量占表比例高（比如 >20%），优化器仍可能放弃索引走全表扫描
- 用
EXPLAIN DELETE ...不生效，得改写成EXPLAIN SELECT对应条件来预判执行计划 - 在从库上直接删更危险：语句级复制（SBR）下，大
DELETE会在从库重放一次，锁时间翻倍
怎么安全地拆成小批量删除
核心思路不是“删多少”，而是“每次删完立刻释放锁+控制节奏”。关键不在 LIMIT，而在 WHERE 条件必须能稳定推进——靠自增主键最可靠，靠时间字段次之，靠业务字段（如 status）风险极高（重复值、空值、更新干扰）。
实操建议：
- 优先用主键分段：
DELETE FROM t WHERE id BETWEEN ? AND ?，每次取 1000–5000 行，间隔由应用层控制 - 避免用
DELETE ... LIMIT循环：MySQL 5.7+ 虽支持，但每次都要重新扫描前 N 行，越往后越慢；且无法保证跳过已删行，易漏删或重复删 - WHERE 条件必须覆盖索引最左前缀，且该索引不能被其他高频 UPDATE 频繁修改（否则导致 delete 时频繁回表或锁冲突）
- 每批执行后加
SLEEP(0.1)（应用层控制），别让 MySQL 线程饿死其他请求
示例（伪代码逻辑）：
start_id = 1
batch_size = 5000
while True:
end_id = start_id + batch_size - 1
rows_affected = execute("DELETE FROM orders WHERE id BETWEEN %s AND %s", (start_id, end_id))
if rows_affected == 0:
break
time.sleep(0.1)
start_id = end_id + 1WHERE 条件选错会导致批量失效
用非主键字段分批，表面看代码更“业务友好”，实际极易崩。比如按 created_at < '2022-01-01' 删除，看似合理，但一旦该字段没索引、或存在大量 NULL、或有并发 INSERT/UPDATE 修改该字段，就会出现：删着删着跳过一批、某批反复重试、甚至误删新数据。
真实踩坑场景：
-
created_at有索引，但类型是DATETIME，而查询用字符串'2022-01-01'——隐式类型转换导致索引失效 - 用
status = 'archived'分批，但业务逻辑里不断有新记录写入该状态，导致 delete 条件永远“追不上”新数据，无限循环 - 复合索引
(a,b,c)，WHERE 只用了b = ?，无法走索引，批量变全表扫
验证方法很简单：对你要用的 WHERE 条件单独跑 EXPLAIN SELECT id FROM t WHERE ...，确认 key 列显示用了哪个索引，rows 估算值接近你设的 batch_size，才算靠谱。
事务边界和 autocommit 怎么设才不翻车
批量删除必须关掉自动提交（autocommit=0），但又不能整个大事务包到底——那是换汤不换药。正确做法是：每个小批量自己开事务、删完立刻 COMMIT，靠应用层控制总进度。
容易忽略的点：
- 别在存储过程中用循环+事务——MySQL 存储过程事务不可部分提交，整个过程还是单事务
- 用
START TRANSACTION包裹每批，而不是靠连接默认事务模式，避免连接复用时残留事务状态 - 如果用连接池，确保每次批量操作用独立连接，或显式
ROLLBACK清理失败批次的残留锁 - 注意隔离级别：
REPEATABLE READ下，第一次 SELECT 后的快照会持续到事务结束，导致后续批次看到“旧数据”，建议改用READ COMMITTED
最后提醒一句：批量删除没有银弹。主键连续、无写入、数据冷——这种理想情况才能跑得稳。只要表上有高频 UPDATE 或业务逻辑依赖被删行的关联状态，就得提前评估外键约束、触发器、应用缓存一致性这些隐藏成本。
