MySQL 事务隔离级别切换后快照为什么没变化

我排查这类问题时，最先看的是“第一次普通查询发生在什么时候”，而不是马上把隔离级别改得更高。对 InnoDB 来说，REPEATABLE READ 下同一事务的普通一致性读会沿用第一次读建立的快照；如果只是切换了会话变量，或者事务已经开始，当前快照不会被重写。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/

先看结论：隔离级别切换不会改写已经建立的快照

这里有三个容易混淆的时间点：设置隔离级别的时间、事务开始的时间，以及第一次一致性读的时间。SET TRANSACTION ISOLATION LEVEL ... 只决定事务采用哪种规则；在 REPEATABLE READ 中，第一次普通 SELECT 才把读视图固定下来。此后即使另一个会话提交了更新，当前事务再次普通查询仍可能看到旧版本。

如果你在事务中途执行切换，MySQL 也不会把已经出现的结果“刷新”成新规则。最稳妥的做法是先结束当前事务，再为下一次事务设置级别，然后重新开始测试。

用两个会话复现快照创建时机

先准备一行测试数据。下面的 SQL 只用于说明实验步骤，建议在独立测试库执行：

-- 建立最小 InnoDB 实验表，避免其他表或存储引擎干扰
CREATE TABLE account_snapshot_demo (
  id INT PRIMARY KEY,
  balance INT NOT NULL
) ENGINE = InnoDB;

-- 重置测试行，重复实验前先恢复同一个起点
INSERT INTO account_snapshot_demo (id, balance)
VALUES (1, 100)
ON DUPLICATE KEY UPDATE balance = 100;

会话 A 执行：

-- 只对当前连接的下一事务指定隔离级别
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION;

-- 这次普通 SELECT 会建立当前事务的一致性读快照
SELECT balance FROM account_snapshot_demo WHERE id = 1;
-- 示意结果：100

保持会话 A 不提交，在会话 B 执行：

-- 另一个会话修改并提交，让变化对后续事务可见
START TRANSACTION;
UPDATE account_snapshot_demo SET balance = 150 WHERE id = 1;
COMMIT;

回到会话 A 再查一次：

-- 同一事务中的第二次普通读仍沿用第一次读的快照
SELECT balance FROM account_snapshot_demo WHERE id = 1;
-- 示意结果：100

-- 结束事务，释放本次实验的事务状态
ROLLBACK;

这不是更新失败，而是快照读的预期表现。会话 A 结束事务后重新查询，才会在新的事务视角下看到 150。

切换到 READ COMMITTED，为什么第二次查询会变

把实验改成 READ COMMITTED 后，普通一致性读不再固定整个事务的第一次快照，而是每次读取时建立自己的新快照。因此会话 A 第一次读到 100，会话 B 提交 150 后，会话 A 第二次普通查询通常就能读到 150。

-- 先结束旧事务，再让下一事务使用 READ COMMITTED
ROLLBACK;
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;

-- 第一次一致性读读取提交值
SELECT balance FROM account_snapshot_demo WHERE id = 1;
-- 示意结果：100

-- 此处让会话 B 更新并提交后，再在 A 中执行同一条 SELECT
SELECT balance FROM account_snapshot_demo WHERE id = 1;
-- 示意结果：150

-- 实验结束要显式结束事务，避免连接池交回脏事务
COMMIT;

实际排查时先区分四个边界

我通常会先执行 SELECT @@SESSION.transaction_isolation, @@autocommit;，再确认两次查询之间是否真的跨过了会话 B 的 COMMIT。如果结果仍旧不符合预期，再检查是否存在长事务、隐式提交或应用层把两个请求复用了同一连接。

常见问题

只执行 SET SESSION 就能刷新当前快照吗？

不能。它改变连接后续事务采用的设置，不会重建已经建立的读视图。先提交或回滚当前事务，再重新开始更容易判断。

为什么加了 FOR UPDATE 后读到的值不同？

这是锁定读，读取和加锁遵循另一套规则，不能拿它与普通一致性读直接比较。排查快照时先去掉锁定子句，单独验证普通 SELECT。

READ COMMITTED 一定更好吗？

不一定。它适合希望同一事务内多次读取看到较新已提交数据的场景，但会改变重复读取的一致性语义。应根据业务是否需要稳定快照来选择。