SELECT ... LOCK IN SHARE MODE 只阻塞其他事务的 SELECT ... FOR UPDATE 和 UPDATE/DELETE不阻塞普通 SELECT 或其他共享锁它允许多个事务同时读但无法防止并发修改需配合排他锁或原子更新使用。SELECT ... LOCK IN SHARE MODE 会阻塞哪些操作它只阻塞其他事务对同一行执行 SELECT ... FOR UPDATE 或 UPDATE/DELETE但不阻塞普通 SELECT也不阻塞其他事务的 SELECT ... LOCK IN SHARE MODE可共享读锁。换句话说它允许多个事务同时加共享锁但会排队等排他锁。常见错误现象以为加了 LOCK IN SHARE MODE 就能防止并发修改结果两个事务都读到旧值、都执行更新造成覆盖写。这不是锁失效而是共享锁本来就不排斥别的共享锁——你需要的是排他锁或者配合 UPDATE 原子操作。使用场景适合“读取后校验再决定是否更新”的流程比如库存预占查剩余量 ≥1 → 再扣减但必须确保后续有 UPDATE 或显式等待逻辑注意隔离级别在 REPEATABLE READ 下该语句会加间隙锁gap lock可能意外锁住不存在的行若只想锁命中行需确认 where 条件走唯一索引性能影响锁粒度是行级但若条件不走索引会退化为表锁直接拖慢整个表的写操作为什么有时候 LOCK IN SHARE MODE 不生效最常见原因是事务没开启或自动提交开着SET autocommit 1 下每条语句都是独立事务锁在语句结束就释放根本起不到保护作用。另一个隐蔽坑是MySQL 的 LOCK IN SHARE MODE 在主从复制中默认是 statement-basedSBR而共享锁不记录在 binlog从库不会复现锁行为导致主从一致性逻辑错乱。如果依赖锁做业务控制务必用 ROW 格式复制并确认从库也启用相同隔离级别。检查方式执行 SELECT autocommit 和 SELECT tx_isolation确保为 0 和 REPEATABLE-READ参数差异innodb_lock_wait_timeout 控制等待超时默认 50 秒线上建议设为 5–10 秒避免长等待拖垮连接池不要和 SELECT ... FOR UPDATE 混用在同一事务里除非明确需要升级锁否则可能引发死锁尤其当多行锁顺序不一致时替代方案什么时候该用 SELECT FOR UPDATE 而不是 LOCK IN SHARE MODE当你读完数据后几乎必然要更新比如查余额 → 扣款直接用 SELECT ... FOR UPDATE 更安全。它加的是排他锁天然阻止其他事务读写同一行省去锁升级步骤也规避了“先共享再更新”中间的时间窗口。 There’s An AI For That 全球领先的 AI 聚合器收集10,225个AI工具可用于超过2,548个任务。