SQL SELECT FOR UPDATE 的使用边界

select for UPDATE只锁实际扫描并返回的行（需走索引），否则可能锁全表；RR级加临键锁（记录+间隙），RC级仅记录锁；须避免索引失效、混用普通SELECT、长事务持锁。

SELECT FOR UPDATE 会锁住哪些行

它只锁 SELECT 实际扫描并返回的行，不是 WHERE 条件匹配的所有行，更不是整张表——前提是查询能走索引。如果 WHERE 条件没命中索引，InnoDB 可能退化为锁全表（准确说是锁所有聚簇索引记录，即“锁表效果”）。

常见踩坑点：

• 用 LIKE '%abc' 或函数包裹字段（如 WHERE UPPER(name) = 'ABC'），导致索引失效，进而扩大锁范围
• 联合索引中只用到非最左前缀（如索引是 (a,b,c)，却查 WHERE b = 1），同样可能引发全扫描加锁
• 在 RR 隔离级别下，还会对“间隙（gap）”加锁，防止幻读；这意味着即使某条记录不存在，它前后的位置也可能被锁住

FOR UPDATE 在不同隔离级别下的行为差异

mysql 默认的 REPEATABLE READ 下，SELECT ... FOR UPDATE 会加临键锁（next-key lock），即记录锁 + 间隙锁；而 READ COMMITTED 下只加记录锁，不锁间隙——这直接影响并发插入是否被阻塞。

实操建议：

• 若业务允许幻读（比如只是更新已存在订单的状态），可考虑把事务隔离级别设为 READ COMMITTED，减少锁冲突
• 但注意：RC 级别下，同一个事务内多次执行相同 SELECT ... FOR UPDATE，可能拿到不同结果集（因其他事务已提交新行），逻辑需自行兜底
• 不要依赖 AUTOCOMMIT=1 时的 FOR UPDATE——它会立刻提交，锁也随即释放，起不到保护作用

FOR UPDATE 和普通 SELECT 混用的风险

在一个事务里，先执行普通 SELECT，再执行 SELECT ... FOR UPDATE，前者查到的数据可能已被其他事务修改，而你基于旧值做判断再加锁更新，容易引发覆盖写或状态错乱。

典型场景：

• “余额扣减”：先 SELECT balance FROM account WHERE id = 123，再判断是否足够，最后 UPDATE ... SET balance = balance - 100 WHERE id = 123
• 问题在于两次查询之间，balance 可能已被他人改过；正确做法是直接 SELECT balance FROM account WHERE id = 123 FOR UPDATE，然后在应用层校验并更新
• 更稳妥的是用原子 SQL：UPDATE account SET balance = balance - 100 WHERE id = 123 AND balance >= 100，再检查 ROW_COUNT()

长时间持有 FOR UPDATE 锁的后果

FOR UPDATE 的锁会持续到事务结束（COMMIT 或 ROLLBACK），而不是语句执行完。一旦应用层处理慢、网络卡顿、或忘了提交，就会让锁长期挂着，阻塞其他事务。

关键控制点：

• 确保事务粒度尽量小：加锁 → 修改 → 提交，中间不要掺杂 http 调用、日志打印、复杂计算等耗时操作
• 设置合理的 innodb_lock_wait_timeout（默认 50 秒），避免无限等待；应用层捕获 Lock wait timeout exceeded 错误后应重试或降级
• 监控活跃事务：SELECT * FROM information_schema.INNODB_TRX，重点关注 TRX_STARTED 和 TRX_STATE，及时发现长事务

真正难处理的从来不是语法怎么写，而是锁的生命周期和业务流程是否对齐——一个本该 200ms 完成的事务，因为加了日志埋点拖到 3s，就足以让下游排队雪崩。