根本原因是事务持锁时间过长或锁粒度过大，InnoDB在RR级别下使用间隙锁，导致未命中数据时也阻塞插入；应优化索引、缩短事务、避免耗时操作、合理选择锁类型及批量策略。
为什么 SELECT ... FOR UPDATE 在高并发下会卡死？
根本原因不是锁本身，而是事务持有锁的时间过长，或锁粒度超出必要范围。InnoDB 默认在可重复读（RR）隔离级别下使用间隙锁（Gap Lock），SELECT ... FOR UPDATE 不仅锁住匹配行，还可能锁住索引间隙——哪怕 WHERE 条件没命中任何数据，也会阻塞其他事务插入相邻值。
实操建议：
- 确保被
FOR UPDATE查询的字段有有效索引，否则会升级为表级锁或全扫描加锁 - 把锁操作尽量靠近事务末尾，避免在锁住行后执行耗时逻辑（如远程调用、复杂计算）
- 若业务允许，改用
SELECT ... LOCK IN SHARE MODE+ 应用层校验，减少排他锁竞争 - 在 RR 级别下测试时，注意
INSERT INTO ... SELECT或UPDATE ... WHERE语句也可能隐式触发间隙锁，引发死锁
如何避免 INSERT ... ON DUPLICATE KEY UPDATE 的锁冲突？
该语句在唯一键冲突时会先尝试插入，失败后转为更新，但整个过程会对目标行（包括冲突前的插入意向锁）加锁。在高并发写同一主键/唯一键场景下，极易出现锁等待甚至死锁。
关键点：
- 它只对**实际命中或可能插入位置的索引记录**加锁，不是全表锁，但唯一索引上的竞争仍很激烈
- 如果唯一键是复合索引，且 WHERE 条件未覆盖最左前缀，可能导致锁范围扩大
- MySQL 8.0+ 中，
INSERT ... ON DUPLICATE KEY UPDATE在某些情况下会释放插入意向锁再获取更新锁，造成短暂窗口，但并发压力大时仍不可靠 - 替代方案：先
SELECT ... FOR UPDATE判断是否存在，再决定 INSERT 或 UPDATE——前提是能接受两次网络往返和更长的事务时间
innodb_lock_wait_timeout 调小就能解决超时问题？
不能。把 innodb_lock_wait_timeout 从默认 50 秒调成 1 秒，只是让等待更快失败，不减少锁争用本身。反而可能让应用频繁重试，加剧系统负载。
真正有效的做法：
- 用
SHOW ENGINE INNODB STATUS\G查看最近死锁详情，定位哪类 SQL 和索引组合高频冲突 - 监控
Innodb_row_lock_waits和Innodb_row_lock_time_avg，确认是否真存在锁瓶颈（而非 CPU 或磁盘 IO） - 检查慢查询日志中带
FOR UPDATE或LOCK IN SHARE MODE的语句，它们往往事务长、索引差、逻辑重 - 对热点行（如账户余额、库存计数器），考虑分段计数（如 10 个 bucket 取模更新）或异步化（写入消息队列后由消费者聚合）
批量更新时用 WHERE id IN (...) 还是逐条 UPDATE？
取决于数据分布与锁粒度。IN 列表若跨多个页、无序、或包含大量非聚集索引键，会导致锁顺序不一致，显著提升死锁概率；而逐条更新虽网络开销大，但锁获取顺序可控。
更稳妥的批量策略：
- 按主键升序排序后再拼 IN 列表，保证加锁顺序一致
- 拆成固定大小的批次（如每批 100 行），并控制批次间间隔，避免瞬时锁堆积
- 避免在 IN 列表中混入不存在的 ID——InnoDB 仍会对对应间隙加锁
- 对超大批量（>10k 行），优先考虑用临时表 + JOIN 更新：
UPDATE t1 JOIN tmp_ids ON t1.id = tmp_ids.id SET t1.status = 'done';
，比长 IN 更稳定且易观察执行计划
锁优化没有银弹。最常被忽略的是：事务边界是否真正由业务语义定义，还是被 ORM 自动开启、又因异常未关闭？一个未提交的事务，可能让一行记录被锁住数分钟——这比任何索引优化都致命。
