MySQL 事务隔离级别下普通 SELECT 为什么看不到新提交

在 InnoDB 里，普通 SELECT 看不到另一个会话刚提交的新数据，通常不是提交失败，而是当前事务仍在读取旧快照。MySQL 默认隔离级别是 REPEATABLE READ：同一个事务第一次快照读确定时间点，后续普通查询会沿用它。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/innodb-consistent-read.html

先用两个会话还原“明明提交了却查不到”

准备一张 InnoDB 表。下面的 SQL 只用于说明会话之间的时序，不要把示例结果当成服务器日志。

-- 建立一个可重复查询的小表，明确使用 InnoDB
CREATE TABLE demo_orders (
  id INT PRIMARY KEY,
  status VARCHAR(20) NOT NULL
) ENGINE=InnoDB;

-- 会话 A：关闭自动提交，第一次普通查询建立快照
SET autocommit = 0;
SELECT * FROM demo_orders;

-- 会话 B：插入一行并提交
INSERT INTO demo_orders VALUES (1, 'paid');
COMMIT;

-- 会话 A：仍在旧事务中，普通 SELECT 可能看不到 id=1
SELECT * FROM demo_orders;
COMMIT;

-- 会话 A：结束旧事务后重新查询，才能看到新提交
SELECT * FROM demo_orders;

关键不在于 B 是否执行了 COMMIT，而在于 A 的第二次查询是否仍属于同一个 REPEATABLE READ 事务。若连接池把连接借出后没有及时提交或回滚，应用代码就很容易把旧快照误认为数据库没有更新。

普通 SELECT 到底看的是哪个版本

InnoDB 会通过多版本并发控制为普通 SELECT 提供一致性视图。快照只看时间点之前已经提交的版本，不看时间点之后提交或尚未提交的版本；但当前事务自己早先写入的变化有特殊可见性规则，所以不要用“所有查询都绝对冻结”来概括。

因此，单独执行一条普通 SELECT 时是否能看到新提交，还要看它是不是被显式事务包住。autocommit=1 时，每条语句通常在自己的事务中完成；如果另一会话已经提交，下一条语句一般会建立新的读取时间点。

按“要一致”还是“要新鲜”选择修复方式

如果报表或一组关联查询要求前后一致，保留 REPEATABLE READ，在事务边界结束前接受旧快照。若业务要看到其他事务已经提交的最新状态，可以先结束当前事务，再开启新事务：

-- 先释放旧快照，再开始一组新的读取
COMMIT;
START TRANSACTION;
SELECT id, status FROM demo_orders WHERE id = 1;

-- 需要每次一致性读都更新视图时，显式使用 READ COMMITTED
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
SELECT id, status FROM demo_orders WHERE id = 1;
COMMIT;

若场景是“读取并准备修改”，可以使用 SELECT ... FOR SHARE 进行锁定读。它不是让普通 SELECT 变新鲜，而是改变读取模式，可能等待并影响并发；库存、余额等关键路径不要只靠改隔离级别解决，还要把锁、更新条件和事务边界一起设计。

连接池场景的排查清单

1. 查当前会话状态：确认 @@autocommit 和 @@transaction_isolation，不要只看服务器全局配置。
2. 查事务入口：确认上一次请求是否留下未提交事务，异常路径是否执行了回滚。
3. 查读取类型：普通 SELECT、FOR SHARE、FOR UPDATE 的语义不同，不能只看 SQL 的 SELECT 关键字。
4. 查业务目标：报表需要一致快照，实时状态需要新鲜读；两者的正确方案不同。

-- 查看当前连接的两个关键开关，帮助定位“旧快照”
SELECT @@autocommit AS autocommit_mode,
       @@transaction_isolation AS isolation_level;

这个问题最常见的修复不是反复执行同一条 SELECT，而是明确谁负责 COMMIT、谁负责 ROLLBACK，以及连接归还连接池前是否已经结束事务。

相关问题

为什么会话 B 提交了，会话 A 还是看不到行？

A 的普通 SELECT 仍在旧的 REPEATABLE READ 快照内。先提交或回滚 A，再重新查询。

READ COMMITTED 会不会自动锁住查询行？

普通一致性读仍是不加锁读取；它只是让同一事务中的每次一致性读使用更新的快照。

FOR SHARE 能否替代实时查询？

不能简单替代。它是锁定读，可能等待并带来并发成本；只有确实需要读取并保护当前版本时才使用。