MySQL 事务里先查后改为什么会丢更新：锁定读与普通快照读的边界

在库存扣减、名额占用或余额变更中，先用普通 SELECT 读出数值，再执行 UPDATE，并不能自动保护这两步之间的间隔。InnoDB 的普通查询通常是快照读；如果下一步要依据刚读到的行继续修改，应明确使用锁定读，或把条件直接放进一条原子更新中。

需要“读出后再决定怎么改”的事务，优先让 SELECT ... FOR UPDATE 锁住目标行；只展示历史数据的查询才适合普通快照读。

先看一个会丢更新的库存扣减

假设 stock_item 中有一行 sku='A-100'、available=1。两个事务都执行同一段“先查库存，再扣一件”的逻辑：

START TRANSACTION;
SELECT available FROM stock_item WHERE sku = 'A-100';
-- 应用层判断 available > 0
UPDATE stock_item SET available = available - 1
WHERE sku = 'A-100';
COMMIT;

两个事务可能先后读到同一个快照值 1，随后都认为库存足够。这里的关键不是 UPDATE 没有锁，而是两个事务在“读到 1”和“准备改行”之间没有用读锁建立排他顺序；业务判断已经被两个并发请求同时通过。

普通 SELECT 为什么是快照读

在 InnoDB 中，普通 SELECT 属于一致性非锁定读。它从事务视图读取已提交版本，不会因为读到一行就替这行建立写保护。默认的 REPEATABLE READ 下，同一个事务的普通一致性读通常复用第一次读建立的快照。

这正适合列表页、历史报表和不准备立刻修改的展示场景，但不适合“我根据这个值马上做决定”的读改流程。图片展示了这条真实数据路径：普通 SELECT 进入 快照读，两个事务都可能得到 available=1，而 UPDATE 才在随后争用写锁。

把读改流程换成锁定读

如果业务必须先读取再判断，改为在同一事务中使用 SELECT ... FOR UPDATE：

START TRANSACTION;
SELECT available
FROM stock_item
WHERE sku = 'A-100'
FOR UPDATE;

-- 应用层判断 available > 0 后再更新
UPDATE stock_item
SET available = available - 1
WHERE sku = 'A-100';
COMMIT;

第一笔事务取得目标行的锁后，第二笔事务执行锁定读会等待第一笔事务提交或回滚，再读取最新版本。第二个事务不能继续沿用旧的判断结果，这就是 SELECT ... FOR UPDATE 和普通 SELECT 的边界。

图片对应的调用关系是 SELECT ... FOR UPDATE → 锁定读 → UPDATE，三个节点都在本节代码或叙述中出现。锁定读不是“查询更快”，而是把读、判断、改写串成可观察的事务顺序。

锁住的范围取决于条件和索引

锁定读并不意味着整张表都被锁住。使用唯一索引和唯一条件定位单行时，通常只需要关注目标索引记录；使用范围条件时，InnoDB 可能锁住搜索遇到的索引记录及其范围。没有合适索引时，扫描和锁覆盖范围都会扩大。

-- 单行语义：sku 应有唯一索引
SELECT available FROM stock_item
WHERE sku = 'A-100'
FOR UPDATE;

-- 范围语义：会影响需要检查的索引范围
SELECT id, available FROM stock_item
WHERE warehouse_id = 7 AND available > 0
FOR UPDATE;

因此验收时要同时检查 SHOW CREATE TABLE stock_item 的索引定义和 EXPLAIN 的访问路径，不能只凭 SQL 末尾出现了 FOR UPDATE 就断定锁范围。

什么时候不该加 FOR UPDATE

如果查询只是生成报表、展示商品详情或读取已经完成的订单状态，就不需要为了“保险”加锁。多余的锁会让并发修改等待更久，甚至把原本独立的读请求卷入锁等待。

如果业务规则可以表达成单条带条件的更新，也可以让数据库直接判断：

UPDATE stock_item
SET available = available - 1
WHERE sku = 'A-100' AND available > 0;

应用层再根据受影响行数判断是否扣减成功。这个写法省去了显式的先查步骤，但必须把“库存大于零”的条件完整放进更新条件，不能更新后再凭旧查询结果判断。

用两个会话复核行为

1. 会话 A 开启事务后执行锁定读，保持事务不提交；确认目标行已经被会话 A 持有。
2. 会话 B 对同一 sku 执行 SELECT ... FOR UPDATE；在会话 A 提交或回滚前，观察会话 B 进入等待。
3. 会话 A 提交后，会话 B 继续读取并依据最新值判断；再检查 UPDATE 的受影响行数。

复核时不要把“客户端没有立即返回”直接解释成死锁。锁等待可以在阻塞事务结束后继续；只有形成循环等待并被 InnoDB 选择回滚时，才是另一类需要单独处理的死锁问题。

常见误区与延伸问答

普通 SELECT 加了事务就会锁行吗？

不会。事务保证语句组合的边界，但普通 InnoDB SELECT 仍是快照读；需要读时保护目标行时，应选择锁定读或改写为带条件的原子更新。

FOR UPDATE 能替代所有并发校验吗？

不能。还要确认事务没有提前提交、条件命中了正确索引，并处理锁等待、超时、死锁回滚和业务重试。它解决的是读改顺序，不是自动补齐业务幂等。

为什么同一条 SQL 的锁范围会不同？

唯一条件、范围条件、索引选择和事务隔离级别都会影响访问与锁定路径。用表结构和 EXPLAIN 复核实际访问路径，比凭 SQL 外观猜测更可靠。

小结

普通 SELECT 负责以快照方式读数据，SELECT ... FOR UPDATE 负责在读后还要改的事务中建立锁定顺序。先判断是否存在“读出的值会决定下一步修改”，再选择读法；最后用索引、双会话和受影响行数完成验证。