MySQL 隔离级别下快照读为什么看不到刚提交数据：一致性读与当前读

订单详情页偶尔显示旧库存，后台同事却已经在另一个连接里提交了扣减。把问题缩成两个 InnoDB 事务后，答案很明确：普通 SELECT 做的是一致性读，读取由事务快照决定；需要看到最新已提交版本并锁住行时，应改用当前读，例如 SELECT ... FOR UPDATE。

在默认的 REPEATABLE READ 下，同一事务第一次普通读取建立读视图，后续快照读会继续沿用它；READ COMMITTED 会为每次一致性读建立新快照，而 FOR UPDATE 走当前版本并承担锁等待。

两个事务的时间线：为什么提交了仍然读到旧值

先准备一行库存数据：

CREATE TABLE stock_item (
  id BIGINT PRIMARY KEY,
  available INT NOT NULL
) ENGINE = InnoDB;

INSERT INTO stock_item (id, available) VALUES (7, 10);

连接 A 使用默认的 REPEATABLE READ，先开启事务并执行一次普通查询：

START TRANSACTION;
SELECT available FROM stock_item WHERE id = 7; -- 10

此时连接 B 完成扣减并提交：

START TRANSACTION;
UPDATE stock_item SET available = 9 WHERE id = 7;
COMMIT;

连接 A 再次执行相同的普通查询，仍可能得到 10。不是 B 的提交失效，而是 A 的快照读在读视图里只接受符合可见性规则的版本；InnoDB 会利用 undo 记录重建旧版本。把这段顺序写成审计记录，就是“事务A”先快照读取，再由“事务B提交”，最后事务A仍返回旧版本。

REPEATABLE READ 和 READ COMMITTED 的分界

这个现象首先要排除“连接设置不一致”。在两个连接分别执行：

SELECT @@transaction_isolation;

InnoDB 的 REPEATABLE READ 会让事务内一致性读保持同一读视图；切换到 READ COMMITTED 后，每次普通 SELECT 都按当次读取建立新快照，所以 B 已提交的 9 通常会在 A 的下一次查询中可见。

可以用会话级设置做一个不影响其他连接的验证：

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
SELECT available FROM stock_item WHERE id = 7;
COMMIT;

这里别急着把全局隔离级别改掉。READ COMMITTED 改变的不只是“能否看到新值”，还会影响同一事务多次查询的重复读语义；订单结算、报表和库存服务应按业务一致性要求分别决定。

要拿最新值并保护后续更新，使用当前读

如果目标是“读出当前库存，确认足够后立即扣减”，普通快照读不是合适的保护手段。可以让读取本身参与锁定：

START TRANSACTION;
SELECT available FROM stock_item WHERE id = 7 FOR UPDATE;
UPDATE stock_item
SET available = available - 1
WHERE id = 7 AND available > 0;
COMMIT;

FOR UPDATE 是当前读：它会读取最新版本，并对搜索到的索引记录加排他锁。若另一个事务已经持锁，查询会等待；这正是保护“检查后更新”窗口的代价。

锁的范围仍然取决于索引和查询条件。WHERE id = 7 命中主键时范围很小；如果条件没有合适索引，InnoDB 可能扫描并锁住更多记录。线上变慢时要同时看执行计划、锁等待和事务持续时间，不能只把问题归咎于隔离级别。

常见误区与可审计的排查记录

排查记录至少写下四项：连接标识、@@transaction_isolation 返回值、每条 SQL 的执行顺序、事务是否已提交。否则只截取“我已经 COMMIT 了”的聊天记录，很难判断查询到底是快照读还是当前读。

相关问题

普通 SELECT 会等待别的事务提交吗？

在常见的 READ COMMITTED 和 REPEATABLE READ 场景中，一致性非锁定读通常不等待已有行锁，而是读取可见版本；锁定读则可能等待。

READ COMMITTED 能彻底避免库存超卖吗？

不能。它只改变一致性读的快照时机，仍需条件 UPDATE、锁定读或其他并发控制方案。

FOR SHARE 和 FOR UPDATE 应该怎么选？

只需要阻止别人修改已检查的行时可考虑 FOR SHARE；检查后要在同一事务内修改时，通常使用 FOR UPDATE，并控制事务尽快提交。

把读视图和锁当成两种不同工具

“刚提交却看不到”通常是快照语义，不是数据丢失。先按事务时间线确认读类型，再决定是继续使用稳定读视图，还是用 READ COMMITTED 获取按次更新的可见性；需要把读取结果保护到后续写入时，再引入 FOR UPDATE 并核对索引与锁范围。