MySQL在事务中如何实现串行化_使用select lock in share mode查询

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-based（SBR），而共享锁不记录在 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个任务。