mysql默认可重复读隔离级别下，子查询读不到未提交变更属正常行为，因其复用事务启动时的一致性视图（readview），遵循mvcc快照读机制，而非bug。
子查询读不到未提交的变更，不是 bug 是隔离级别行为
MySQL 默认 REPEATABLE READ，PostgreSQL 和 SQL Server 默认 READ COMMITTED——这意味着子查询执行时看到的数据快照，取决于事务启动时刻（或语句启动时刻）的已提交状态。你在同一事务里刚 INSERT 了一条记录但没 COMMIT，另一个会话里的子查询就不可能查到它；哪怕在同一个会话里，如果子查询是独立语句（比如 SELECT id FROM (SELECT * FROM orders) t WHERE status = 'pending'），它也不会“感知”到本事务中尚未提交的中间状态。
常见误判场景：
- 在应用里先
UPDATE users SET balance = balance - 100 WHERE id = 123，紧接着用子查询SELECT balance FROM users WHERE id = (SELECT user_id FROM orders WHERE order_no = 'ORD-001')判断余额，结果还是旧值——这不是子查询问题，是隔离机制使然 - 用子查询做存在性校验：
WHERE EXISTS (SELECT 1 FROM audit_log WHERE user_id = u.id AND status = 'locked')，但 audit_log 的新记录还在另一事务中未提交，该子查询就返回false
子查询嵌套过深 + 长事务导致 MVCC 快照不一致
MySQL 的 MVCC 为每个事务分配一个一致性视图（read view），而子查询本身不创建新事务，它复用外层事务的 read view。但如果子查询里又调用了函数、触发了物化临时表，或涉及多表 JOIN，优化器可能在不同阶段取不同时间点的快照——尤其当子查询跨多个基表，而这些表被不同长事务修改时，就可能出现“部分新、部分旧”的混合结果。
典型表现：
- 视图里含子查询，且关联了
orders和payments两张表；orders表刚被事务 A 更新并提交，payments表还卡在事务 B 的未提交状态，此时视图查出来订单已更新但付款状态仍是旧的 -
EXPLAIN FORMAT=TREE显示子查询节点有MATERIALIZED提示，说明 MySQL 把它当临时表处理，而该临时表生成时刻的快照可能早于外层其他部分 - 避免方式：尽量让子查询只访问单表，或改用显式
JOIN并控制ON条件范围，减少跨表快照漂移风险
子查询中用了非确定性函数，让“一致性”本身失去意义
像 GETDATE()（SQL Server）、NOW()（MySQL）、RAND() 或 NEWID() 这类函数，每次执行都返回不同结果。一旦它们出现在子查询中（尤其是相关子查询或视图定义里），就等于把“时间”或“随机性”固化进了查询逻辑——你反复执行同一条语句，子查询结果自然不同，根本谈不上“是否一致”。
排查要点：
- 检查子查询文本是否含
NOW()、CURRENT_TIMESTAMP、RAND()等；SQL Server 可查sys.sql_modules中定义 - MySQL 8.0+ 中，若子查询含
ORDER BY ... LIMIT 1但没加确定性排序字段（如只按created_at排序，而该字段有重复值），也会导致每次取到的“第一行”不同 - 不要依赖
DISTINCT或GROUP BY来掩盖不确定性——它们不解决源头，只掩盖表现
并发写入时子查询被阻塞，却返回了“看似正确”的旧数据
子查询本身不加锁，但它访问的底表可能正被其他事务独占。比如一个长事务正在 UPDATE orders SET status = 'shipped' WHERE id = 1001，还没提交；此时你的子查询 SELECT * FROM (SELECT id, status FROM orders) t WHERE id = 1001 不会报错，但在 REPEATABLE READ 下会直接读取事务开始前的快照，看起来“数据没变”，实则是被 MVCC 隐式保护了——你没等到锁释放，也没看到新值，更没收到任何提示。
这种静默不一致最难排查，因为：
- 没有错误、没有超时、没有日志告警
-
SELECT * FROM performance_schema.data_locks可能显示该行正被持有X锁，但你的查询早已走完快照路径 - 只有当你对比主库 binlog 时间戳、或用
SELECT * FROM information_schema.INNODB_TRX发现长时间运行事务时，才能反向定位
真正容易被忽略的是：子查询是否“应该看到最新已提交数据”，而不是“是否出错”。如果业务强依赖实时性（比如风控拦截、库存扣减），就不能靠子查询被动读快照，得主动用 SELECT ... FOR UPDATE 或改用 READ COMMITTED 隔离级别，并接受可能的不可重复读代价。
