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，就足以让下游排队雪崩。
