为什么 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 自动开启、又因异常未关闭？一个未提交的事务，可能让一行记录被锁住数分钟——这比任何索引优化都致命。
