嵌套查询本身不引发脏读，但会加剧脏读的隐蔽性与修复难度；问题根源在于事务隔离级别设置不当，而非嵌套语法本身。
嵌套查询本身不引发脏读，但会让脏读更难察觉、更难修复——问题根源永远在隔离级别，不是子查询写法。
为什么 SET TRANSACTION ISOLATION LEVEL READ COMMITTED 必须放在 BEGIN TRANSACTION 之前
SQL Server 中，SET TRANSACTION ISOLATION LEVEL 的生效时机是“语句执行前”，不是“事务开启时”。如果写成：
BEGIN TRANSACTION; SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
那么 BEGIN TRANSACTION 后第一条 SELECT（哪怕只是嵌套子查询里的）已经按会话默认级别（可能是 READ UNCOMMITTED）执行了——脏读已发生，再设级别也晚了。
- 正确顺序：先
SET TRANSACTION ISOLATION LEVEL READ COMMITTED，再BEGIN TRANSACTION - ORM 场景下尤其危险：比如 Entity Framework 默认不显式设级别，连接池复用可能继承上一个会话的
READ UNCOMMITTED - 验证当前级别：运行
SELECT @@TRANSACTION_ISOLATION，返回值 2 = READ COMMITTED，1 = READ UNCOMMITTED
MySQL 嵌套查询里混用快照读和当前读，等于主动打开脏读后门
MySQL 的 REPEATABLE READ 默认对纯 SELECT JOIN 是快照读，但只要嵌套结构里出现以下任一情况，整个外层查询就退化为当前读，可能读到未提交数据：
- 子查询含
SELECT ... FOR UPDATE或LOCK IN SHARE MODE - JOIN 的 ON 条件中调用了带触发器或外键约束的列（隐式触发当前读）
- 子查询用了
UNION或临时表物化，且该物化过程被其他事务并发修改
实操建议：EXPLAIN FORMAT=TREE 查看执行计划，重点确认是否出现 materialize + lock 组合；避免在子查询 WHERE 中写 status IN (SELECT ...) 这类易触发物化的结构。
别信 NOLOCK 能“解决”嵌套查询性能问题
WITH (NOLOCK) 在 SQL Server 里不是优化手段，是隔离性放弃声明。它对嵌套查询的杀伤力是倍增的：
- 内层子查询加
WITH (NOLOCK)→ 读到未提交数据 → 外层 JOIN 拿这个脏结果做关联 → 可能关联出根本不存在的订单用户组合 - 即使外层加了
READ COMMITTED，也无法覆盖内层NOLOCK的行为 - 线上查到“用户余额突变为负数但查不到扣款记录”，八成是某处嵌套子查询用了
WITH (NOLOCK)
真正该做的：给子查询涉及的字段建索引，让数据库能走索引查找而非全表扫描——这比加 NOLOCK 更安全、更稳定。
嵌套查询的脏读风险不在语法嵌套本身，而在你没意识到：子查询可能独立触发锁、独立生成快照、独立受隔离级别控制。最容易被忽略的是跨层读取一致性——外层事务级别管不住内层子查询的读行为，必须每一层都明确约束。
