SELECT ... FOR UPDATE 在高并发下拖慢查询，因其加写锁导致阻塞、死锁或锁升级；仅适用于“读取后立刻精准更新”的场景，且 WHERE 条件必须有有效索引。
为什么 SELECT ... FOR UPDATE 在高并发更新场景下反而拖慢查询
不是所有“加锁”都能优化性能，SELECT ... FOR UPDATE 本质是给符合条件的行加写锁，如果查询条件没走索引、或锁住范围过大，会导致大量事务阻塞，甚至触发锁升级和死锁。它真正适合的场景，是「读取后立刻更新」且能精准定位行的业务逻辑（比如扣库存、抢优惠券），而不是单纯想“让查询更快”。
- 常见错误现象：
Lock wait timeout exceeded或大量SHOW PROCESSLIST显示Locked状态 - 必须确保 WHERE 条件字段有有效索引，否则会锁全表或全索引扫描范围
- 在 RR 隔离级别下，
SELECT ... FOR UPDATE还会加 gap lock，可能意外锁住不存在但“本该存在”的间隙（比如查id > 100，却锁住 (100, 200) 区间） - 如果只是读多写少的报表类查询，加锁不仅无益，还会抢占 MVCC 快照资源，拖慢其他事务
UPDATE 语句里隐式锁 vs 显式加锁的区别
UPDATE 本身就会加锁，但加什么锁、锁多少，取决于执行计划。显式用 SELECT ... FOR UPDATE 是提前占位，而直接 UPDATE 是边查边锁、一气呵成——后者更轻量，也更可控。
- 使用场景：你要更新某条记录，且更新逻辑简单（比如
UPDATE t SET status=2 WHERE id=123），直接写UPDATE就行，不用先SELECT ... FOR UPDATE - 参数差异：显式加锁需要两次网络往返（查+更），而单条
UPDATE一次完成；若中间有业务判断逻辑（比如“只有 status=1 才能改成 2”），才考虑先加锁再检查 - 性能影响：显式加锁会延长锁持有时间（从查完到事务提交），而
UPDATE的锁只持到语句结束（除非在事务中后续还有操作）
什么时候该用 SELECT ... LOCK IN SHARE MODE
共享锁适合“读取后仅做校验、不修改，但又不能容忍被其他人改”的场景，比如风控校验余额是否充足、订单状态是否可取消。它比 FOR UPDATE 冲突概率低，允许其他事务同时读，但阻止写。
- 常见错误现象：用了
LOCK IN SHARE MODE却还在同一事务里去UPDATE同些行——会触发锁升级冲突，报Deadlock found when trying to get lock - 兼容性注意：MySQL 5.7+ 支持，但某些 ORM（如旧版 Django ORM）默认不生成该语法，需手写 raw SQL 或启用特定选项
- 别误以为它能提升读性能：它不加速查询，只保一致性；若只是要“看到最新数据”，
READ COMMITTED隔离级别 + 普通SELECT更高效
锁粒度失控的典型信号和快速排查方法
锁不是越细越好，也不是越多越好。一旦发现慢查询突然伴随锁等待，优先看执行计划是否走了索引、是否用了 OR/LIKE '%xxx' 导致全表扫描锁行，以及事务是否过长。
- 快速定位：执行
SELECT * FROM performance_schema.data_locks（MySQL 8.0+）或SHOW ENGINE INNODB STATUS\G查TRANSACTIONS和LOCK WAIT部分 - 容易踩的坑：在存储过程中用
SELECT ... FOR UPDATE遍历游标，结果每行都锁住，且锁持续到事务结束；应尽量改用单条带条件的UPDATE - 一个硬指标：如果
EXPLAIN显示type是ALL或index，又带了FOR UPDATE，基本等于主动给自己挖坑
锁从来不是性能优化的银弹，而是精确控制并发副作用的手术刀。用错位置，切口比病灶还疼。
