共享锁适用于读多写少且需强一致性的场景，如库存预占、余额校验等前置校验环节，必须在事务内使用LOCK IN SHARE MODE防止其他事务修改已读数据，避免读-写竞态。
共享锁适合「读多写少」且需要强一致性的场景
共享锁（LOCK IN SHARE MODE）不是为了提升读性能而加的——MySQL 默认的 MVCC 已经能高效支持并发读。它真正起作用的地方，是当「这次读的结果必须立刻用于后续写逻辑」，且你不能容忍其他事务在中间改掉这行数据。典型如库存预占、余额校验、订单状态检查等前置校验环节。
常见错误现象：不加锁时，两个请求同时查到库存=5，都判断“够用”，然后都扣减1，最终库存变成3而不是预期的4。这就是典型的「读-写」竞态，LOCK IN SHARE MODE 能堵住这个漏洞。
- 必须在
BEGIN/START TRANSACTION内使用，否则锁在语句执行完就释放，失去意义 - 只对 InnoDB 有效；MyISAM 不支持行级锁，
LOCK IN SHARE MODE会退化为表锁 - 如果查询条件没走索引，InnoDB 可能升级为表级共享锁，导致大面积阻塞
电商下单时校验商品状态和库存必须用共享锁
用户点击“立即购买”后，服务端通常要连查多张表：先确认商品是否上架（products.status），再查当前库存（stocks.quantity），最后才决定是否生成订单。这三个读操作之间不能被其他事务插队修改，否则就会出现“页面显示有货，下单却提示缺货”或更糟的超卖。
正确做法是把关键校验行用共享锁锁定：
START TRANSACTION; SELECT * FROM products WHERE id = 123 LOCK IN SHARE MODE; SELECT * FROM stocks WHERE product_id = 123 LOCK IN SHARE MODE; -- 此时其他事务无法 UPDATE/DELETE 这两行，但可以继续 SELECT -- 校验通过后，再执行 INSERT 订单 + UPDATE 库存 COMMIT;
注意：SELECT ... LOCK IN SHARE MODE 不会阻止其他事务加共享锁，所以多个用户可以同时发起校验；但只要有人开始 UPDATE stocks（触发排他锁），所有等待中的共享锁查询都会被阻塞，直到更新完成。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
共享锁和 MVCC 的区别不能模糊处理
很多人误以为加了 LOCK IN SHARE MODE 就是“强制读最新数据”，其实不是。它只是给当前读到的版本加了一把 S 锁，防止别人改；但读取本身仍受事务隔离级别影响。比如在 REPEATABLE READ 下，即使加了共享锁，你也看不到其他事务已提交但发生在你事务启动之后的变更。
- 想读最新已提交数据 → 用
SELECT ... FOR UPDATE（排他锁）或切换到READ COMMITTED隔离级别 - 只想防别人改我刚读到的那几行 →
LOCK IN SHARE MODE正确且轻量 - 用错成
SELECT ... FOR UPDATE去做纯校验，会无谓阻塞其他只读请求，降低吞吐
容易忽略的隐式锁升级和死锁风险
共享锁本身不会直接导致死锁，但它参与死锁环。例如：事务 A 先 SELECT ... LOCK IN SHARE MODE 行 X，再尝试 UPDATE 行 Y；事务 B 反过来先锁 Y 再锁 X。这时 MySQL 检测到循环等待，会回滚其中一个事务。
更隐蔽的问题是锁升级：当 SELECT ... LOCK IN SHARE MODE 的 WHERE 条件没命中索引，InnoDB 可能对整个聚簇索引扫描并逐行加 S 锁，实际效果接近表锁。线上曾有案例因此导致后台报表任务阻塞全部前端下单请求。
验证方式很简单：执行后立刻查 information_schema.INNODB_TRX 和 INNODB_LOCKS，看锁范围是否符合预期。生产环境务必确保相关字段建了有效索引。
