为什么 SELECT ... FOR UPDATE
会锁住整张表而不是只锁行
MySQL 的 InnoDB 引擎默认在可重复读（
REPEATABLE READ）隔离级别下使用行级锁，但前提是查询能命中索引。如果
SELECT ... FOR UPDATE中的
WHERE条件没走索引（比如对非索引字段查询、或用了函数/隐式类型转换），InnoDB 无法精确定位记录，就会升级为表级锁（或更准确地说：锁住聚簇索引的全部范围，效果等同于锁表）。
实操建议：
用EXPLAIN检查语句是否走了索引 —— 特别关注
type字段是否为
range、
ref或更优，避免出现
ALL确保被
WHERE过滤的列上有合适索引，复合条件时注意最左前缀原则 避免在索引列上使用函数，例如
WHERE YEAR(create_time) = 2024会让索引失效；改用
WHERE create_time >= '2024-01-01' AND create_time确认字段类型匹配：比如
user_id是
BIGINT，但传入字符串
'123'，可能触发隐式转换导致索引失效
什么时候该用 SELECT ... LOCK IN SHARE MODE
而不是 FOR UPDATE
LOCK IN SHARE MODE加的是共享锁（S 锁），允许多个事务同时读；
FOR UPDATE加的是排他锁（X 锁），会阻塞其他事务的读写。选错会导致不必要的并发阻塞或数据不一致。
实操建议：
仅需校验数据存在性、且后续操作不修改该行（如“检查用户余额是否充足”后由另一条UPDATE扣款），用
LOCK IN SHARE MODE更轻量 若后续紧跟
UPDATE或
DELETE，直接用
FOR UPDATE—— 否则在间隙锁场景下，两次加锁之间可能被其他事务插入冲突数据（即“幻读”风险） 注意：在唯一索引 + 等值查询下，
LOCK IN SHARE MODE和
FOR UPDATE锁定的记录范围相同；但在范围查询（如
WHERE id > 100）中，两者产生的间隙锁（Gap Lock）行为一致，区别只在锁类型本身
如何用 SHOW ENGINE INNODB STATUS
快速定位锁等待和死锁
当事务卡住或报错
Lock wait timeout exceeded，不能只看应用日志。InnoDB 的状态输出是诊断锁问题的第一手资料，重点在
TRANSACTIONS和
LATEST DETECTED DEADLOCK区块。
实操建议：
执行SHOW ENGINE INNODB STATUS\G（注意末尾
\G让输出更易读） 搜索
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:查看哪个事务在等什么锁 对照
*** (2) HOLDS THE LOCK(S):找到持锁事务的
TRANSACTIONID 和 SQL 留意
lock_mode X locks rec but not gap表示只锁记录，
lock_mode X locks gap before rec表示有间隙锁 —— 后者常是范围查询引发阻塞的根源 死锁日志里会明确列出两个事务各自的持有锁和等待锁，据此可反推是否因索引缺失或锁顺序不一致导致
用 innodb_lock_wait_timeout
控制等待时长，但别盲目调大
该参数控制事务等待锁的最长时间（单位秒），默认 50。调大看似缓解超时，实则掩盖了锁竞争本质问题，还可能拖垮连接池和整体响应时间。
实操建议：
线上环境建议保持默认或设为 10–30 秒，配合应用层重试逻辑（如幂等更新 + 指数退避） 若频繁触发超时，优先排查是否缺少索引、事务过长、或存在循环依赖的锁顺序（如 A→B→C→A） 不要在单条 SQL 前临时 SET：SET innodb_lock_wait_timeout = 300;—— 它只影响当前会话，且无法解决根本竞争，反而让问题更隐蔽 监控指标应包括
Innodb_row_lock_waits和
Innodb_row_lock_time_avg（通过
SHOW STATUS LIKE 'Innodb_row_lock%'获取），持续升高说明锁粒度或事务设计有问题
锁粒度优化不是调参游戏，核心在于让每条带锁查询都精准命中索引，并严格控制事务边界。最容易被忽略的，其实是业务代码里那些没显式加锁、却依赖“先查后更”逻辑的场景——它们在高并发下天然容易演变成锁竞争热点。
