根本原因是事务持锁时间过长或锁粒度过大，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 更稳定且易观察执行计划