select ... for update 会卡住查询链路，因其在可重复读下加临键锁，锁住匹配行及间隙，导致无关插入/更新被阻塞；需确保走索引、缩短事务、合理设计索引并用 show engine innodb status 定位锁等待。
为什么 SELECT ... FOR UPDATE 会卡住整个查询链路
因为 InnoDB 在可重复读隔离级别下，SELECT ... FOR UPDATE 不仅锁住匹配的行，还会锁住**间隙（gap）**，甚至可能升级为临键锁（next-key lock），导致看似不相关的插入或更新被阻塞。常见现象是：明明只查 ID=100 的记录，但插入 ID=99 或 101 的新行也被 hang 住。
- 只在事务内真正需要修改数据前才加锁，避免提前锁住资源；若只是读取校验，优先用
SELECT ... LOCK IN SHARE MODE或干脆去掉锁 - 确保 WHERE 条件走索引——没索引时会退化为表级锁，所有并发写操作排队等一把锁
- 避免在长事务里执行带锁查询；事务越长，锁持有时间越长，竞争越激烈
- 检查执行计划：
EXPLAIN输出中type字段不能是ALL或index，必须落到range、ref或更优级别
唯一索引 vs 普通索引对锁范围的影响差异
唯一索引能精确锁定单行，而普通索引即使查单值，也可能锁住多个间隙。比如 WHERE status = 2（status 是普通索引），InnoDB 无法确认值是否唯一，就会锁住所有满足 status=2 的行 + 它们之间的 gap，扩大锁粒度。
- 对高频更新+查询的字段，优先建唯一索引（哪怕逻辑上非严格唯一，也可配合应用层控制）
- 若只能用普通索引，考虑在 WHERE 中叠加主键或唯一字段缩小范围，例如
WHERE status = 2 AND id = 123 - 注意
INSERT ... ON DUPLICATE KEY UPDATE在普通索引下也会触发间隙锁，不是“只锁冲突行”
SHOW ENGINE INNODB STATUS 里怎么看真实锁等待
这个命令输出的 TRANSACTIONS 部分才是诊断锁竞争的核心依据，比慢日志更直接。重点看 *** (1) WAITING FOR THIS LOCK TO BE GRANTED: 和 *** (2) HOLDS THE LOCK(S): 两段。
- 别只盯着 “Lock wait timeout exceeded” 错误，它只是结果；先查 status 输出，定位哪个事务持有了谁要的锁
- 注意
lock_mode X locks rec but not gap表示只锁记录，安全；而lock_mode X locks gap before rec表示已锁间隙，容易引发阻塞 - 如果看到大量
lock_mode X locks rec but not gap却仍慢，大概率是锁争抢频繁，而非锁范围过大——这时该考虑拆事务或加缓存
UPDATE 语句没走索引却还在等锁？
是的。哪怕 UPDATE 最终没改任何行（WHERE 条件不匹配），只要扫描过程经过了索引 B+ 树的某些节点，InnoDB 仍会按规则加锁。全表扫描类 UPDATE 就是典型“零更新、高阻塞”场景。
- 执行前务必
EXPLAIN确认key字段非 NULL，且rows量级合理 - 避免在 WHERE 中对字段做函数操作，如
WHERE DATE(create_time) = '2024-01-01'—— 索引失效，变全扫 - 批量更新尽量按主键范围分片，例如
WHERE id BETWEEN 1000 AND 2000，而不是WHERE status = 0这种低区分度条件
锁竞争的根因往往不在 SQL 写得“错”，而在索引设计和事务边界没对齐。一个没被 EXPLAIN 验证过的 WHERE 条件，和一个没被 SHOW ENGINE INNODB STATUS 观察过的锁状态，都不算真正可控。
