大事务更新导致锁等待超时的根本原因是“锁不放”而非“慢”，即事务未提交前持续持有大量行锁，后续操作被完全阻塞；必须通过limit+commit拆分事务并确保索引优化来释放锁，而非调大innodb_lock_wait_timeout。
大事务更新导致行锁等待超时，不是因为“慢”，而是因为“锁不放”——事务一开，每改一行就加一个行锁，不提交就不释放，后续所有想碰这些行的操作全被堵死，等满 innodb_lock_wait_timeout（默认 50 秒）就直接报错。
为什么大事务会让锁堆积成“路障”
InnoDB 的行锁是事务级的：事务开启后，UPDATE 或 INSERT ... SELECT 每影响一行，就持有一个行锁；直到 COMMIT 或 ROLLBACK，锁才批量释放。如果一次更新 10 万行：
- 相当于连续持有 10 万个行锁（甚至更多，取决于索引结构和间隙锁范围）
- 业务请求只要涉及其中任意一行（比如
UPDATE ... WHERE buyer_user_id = ?），就得排队等这个大事务结束 - 排队不是“慢慢来”，而是完全阻塞——MySQL 不会跳过、重试或降级，只等，超时即崩
WHERE 条件没走索引，锁范围会爆炸
你以为只锁目标行？没索引时，MySQL 找不到数据，只能全表扫描，过程中对扫过的每一行都加锁（哪怕最终不修改）。结果就是：
-
UPDATE t SET x=1 WHERE created_at > '2025-01-01'没索引 → 锁住全部 80 万行 - 哪怕你只想改最近 100 条，其他事务一碰这张表就卡住
- 用
EXPLAIN看执行计划：type是ALL就危险；必须是range或ref - 缺失索引（如
buyer_user_id、created_at）要提前建好，别等迁移时补
别调 innodb_lock_wait_timeout，那是掩耳盗铃
把超时从 50 秒改成 300 秒，不会让锁变少，只会让业务请求卡得更久、更难察觉：
-
SET GLOBAL innodb_lock_wait_timeout = 300对已连接会话无效 - 应用层 HTTP 请求早超时了（Nginx 默认 60 秒），数据库还在傻等
- 真正该动的是事务粒度，不是超时阈值
- 临时调试可用
SET SESSION innodb_lock_wait_timeout = 5快速暴露问题，但不能上线
拆分事务必须带 COMMIT，且控制批大小
光用 LIMIT 不够，关键在每次执行后立刻 COMMIT，让锁真正释放：
- 批量
INSERT INTO t2 SELECT * FROM t1 WHERE ... LIMIT 5000→ 每次后面紧跟COMMIT - 应用层做逐条
UPDATE时，每 100–500 行一批，执行完立刻COMMIT，别攒着 - 避免拼接超长 SQL：单次
INSERT太多行可能触发max_allowed_packet限制而失败 - 用主键区间分片比
LIMIT offset, size更稳：WHERE id BETWEEN ? AND ?，避免偏移量扫描放大
最容易被忽略的点是：事务里混了非 DB 操作（比如调外部 API、写文件、sleep()），它们不产生锁，但拖长事务时间，等于主动给行锁续命。锁本身很轻，拖太久才是病根。
