MySQL 一致性读为什么看不到刚提交的数据

MySQL 普通 SELECT 看不到另一个会话刚提交的数据，通常不是提交失败，而是当前事务还在使用较早建立的一致性读快照。InnoDB 默认隔离级别是 REPEATABLE READ：同一事务里的第一次一致性读确定时间点，后续普通查询继续按这个快照判断可见版本。

MySQL 8.4 官方资料：https://dev.mysql.com/doc/refman/8.4/en/innodb-consistent-read.html

先分清“已提交”与“对当前快照可见”

事务 B 提交，只能说明它的版本已经成为数据库中的已提交版本；事务 A 是否能读到，还取决于 A 的一致性读快照。普通 SELECT 不加锁，InnoDB 会使用多版本并发控制，从符合快照时间点的版本中返回结果。

因此，排查时要把两个问题分开：B 有没有执行 COMMIT，以及 A 的第一次一致性读发生在 B 提交之前还是之后。后者决定了“刚提交”是否已经落在 A 的可见范围里。

默认 REPEATABLE READ 为什么会重复看到旧结果

假设 A 关闭自动提交，先执行一次普通查询；随后 B 插入一行并提交。A 再执行同一条件的 SELECT，仍可能看不到这行，因为 A 会复用第一次一致性读建立的快照。这里的“重复读”不是缓存了上一条 SQL 的文本结果，而是每次查询都根据同一个事务快照筛选版本。

-- 会话 A：关闭自动提交，第一次普通读取会建立一致性快照
SET autocommit = 0;
SELECT * FROM orders WHERE order_id = 1001;

-- 会话 B：这次提交发生在会话 A 的快照建立之后
INSERT INTO orders(order_id, status) VALUES (1001, 'paid');
COMMIT;

-- 会话 A：仍按原事务快照读取，可能看不到 B 刚提交的行
SELECT * FROM orders WHERE order_id = 1001;

-- 会话 A：提交后再读，事务时间点前进到新的查询
COMMIT;
SELECT * FROM orders WHERE order_id = 1001;

上面的 SQL 只用于说明两个会话的关系，不代表本文在本机执行过的输出。要读取更新后的视图，最直接的做法是让 A 结束当前事务再重新查询；继续在原事务里加条件或重复执行普通 SELECT，不会自动刷新 REPEATABLE READ 快照。

三种处理方式该怎么选

处理方式取决于“需要稳定视图”还是“需要更接近当前已提交状态”。如果事务需要多次读取同一批数据并保持一致，保留 REPEATABLE READ，在合适边界提交事务；如果每次查询都应看到查询开始前已经提交的版本，可以把当前事务设置为 READ COMMITTED。

-- 只影响当前会话：每次一致性读建立新的已提交快照
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;

-- 新事务中执行查询，避免沿用旧事务的快照
START TRANSACTION;
SELECT * FROM orders WHERE order_id = 1001;
COMMIT;

如果目标是读取最新已提交行并愿意承担锁等待，可以使用锁定读，例如 SELECT ... FOR SHARE。它与普通一致性读不同，可能要等持有最新版本的事务结束；不要仅仅为了“刷新页面”就在所有查询上加锁。

排查时容易混淆的边界

另外，SELECT 语句所在的事务边界经常由连接池、ORM 或框架隐藏。如果手写 SQL 看起来已经提交，但应用仍读不到数据，应先确认同一连接是否开启了自动提交、事务是否真的结束，以及查询是否被复用在旧事务中。

小结

“刚提交但看不到”关键在于版本可见性，不是简单的缓存刷新。默认 REPEATABLE READ 会在事务内复用第一次一致性读的快照；提交事务可以推进时间点，READ COMMITTED 让每次一致性读获取新快照，锁定读则用等待锁的方式接近最新已提交版本。先确定业务需要稳定视图还是新鲜视图，再选择处理方式。

相关问题

• 为什么提交当前事务后再次 SELECT 就能看到数据？因为旧事务结束后，新的查询会建立新的可见性时间点。
• READ COMMITTED 会不会让同一事务两次查询结果不同？会；每次一致性读可能使用不同的新快照，这是它与 REPEATABLE READ 的核心差异。
• FOR SHARE 是否一定能立即看到最新行？不一定；它可能等待仍持有相关最新版本的事务结束。