如何通过事务与控制批量大小解决MySQL大批量更新导致的锁等待问题？

本文共计989个文字，预计阅读时间需要4分钟。

MySQL的行锁在执行UPDATE时并非按需加锁，而是先定位再加锁——即使用WHERE id IN (1,2,3,...)这样的条件，只扫描范围大、执行时间长，就会持续持有锁，阻塞其他事务对这些行的读写。更糟糕的是，如果找不到索引，可能升级为间隙锁或表锁，直接影响性能。

常见现象：SHOW PROCESSLIST 里一堆 Locked 或 Waiting for table metadata lock；业务侧出现超时、重试雪崩；INFORMATION_SCHEMA.INNODB_TRX 显示事务长时间未提交。

• 别指望加个索引就万事大吉——即使 WHERE 条件走索引，更新本身仍要加 X 锁，锁住所有命中的聚簇索引记录和二级索引项
• 事务越长，锁持有时间越长；批量越大，锁覆盖行数越多；两者叠加就是锁等待温床
• AUTOCOMMIT=1 下每个 UPDATE 是独立事务，看似安全，但高并发下仍可能因锁竞争排队

怎么拆分 UPDATE 才不丢数据又不拖慢

核心是控制单次事务的「行数」和「执行时间」，而不是简单按固定条数切分。1000 行在 SSD 上可能 50ms，但在机械盘或高负载下可能 300ms+，反而更易触发锁等待。