子查询单独执行与嵌套结果不一致最常见原因是子查询返回空集或null导致外层条件静默失效，如not in遇null整体判unknown、dependent subquery引发嵌套循环放大、隐式类型转换使索引失效，以及事务隔离级别下快照不一致。
子查询单独执行结果和嵌套时对不上
最常见的情况是子查询本身返回了意外结果，但嵌套后被外层逻辑“消化”得无声无息。比如 WHERE id IN (SELECT user_id FROM logs)，如果子查询返回空集，整个条件为 false，外层查不到数据——不是报错，是静默失效。
- 把子查询语句完整复制出来，在新窗口单独执行，看它是否真返回预期的单列、多行、非 NULL 值
- 用
SELECT COUNT(*)和SELECT MIN(), MAX()快速确认值域和数量级，比SELECT *更高效 - 注意隐式类型转换：子查询返回
VARCHAR，外层IN比较的是INT，MySQL 可能转但索引失效，PostgreSQL 直接不匹配
EXPLAIN 显示 DEPENDENT SUBQUERY 或 rows 异常高
这是性能+逻辑双崩的典型信号。DEPENDENT SUBQUERY 表示子查询每行外层都重跑一次；rows 值远超实际返回行数（比如扫描 200 万行只吐出 10 行），基本坐实嵌套循环放大+索引失效。
- 重点盯
Extra字段：出现Using temporary; Using filesort，说明子查询内部已失控 - 检查子查询
WHERE条件字段是否有联合索引，尤其当含多个过滤条件时（如user_id = ? AND status = 'error'，单列索引无效） - 避免在子查询里用函数：
DATE(create_time) = '2026-07-20'会让create_time索引完全失效
NOT EXISTS / NOT IN 返回空但逻辑应有结果
NOT IN 遇到子查询返回任何 NULL 就整体判为 UNKNOWN，结果集为空；NOT EXISTS 虽更可靠，但若子查询漏写相关条件（如 WHERE b.id = a.ref_id），就会变成全表扫描，查不到匹配行却也不报错。
- 一律改用
NOT EXISTS (SELECT 1 FROM ... WHERE related_condition)，别写SELECT *或带聚合的子查询 - 确保关联字段类型一致：
DESCRIBE对比两边字段，INT和VARCHAR混用会触发隐式转换，可能丢数据或不走索引 - 子查询里永远用
SELECT 1，语义干净且兼容所有主流数据库
事务中嵌套查询看到的数据和外层不一致
根本不是语法问题，而是隔离级别下快照时间点不同步。比如 DELETE FROM t1 WHERE id IN (SELECT id FROM t2 WHERE status = 'pending')，子查询和主语句可能读到不同版本的数据，导致删少了或报唯一键冲突。
- MySQL 8.0.22+ / PostgreSQL 支持
WITH ... FOR UPDATE，必须锁住 CTE 结果，而不是往子查询里硬塞FOR UPDATE - 旧版 MySQL 只能拆成两步：先
CREATE TEMPORARY TABLE存 ID 集合，再SELECT ... FOR UPDATE加锁，最后删 - 别指望
REPEATABLE READ一劳永逸——优化器仍可能为子查询选不同快照，不可靠
EXPLAIN、不单独跑子查询，光靠肉眼几乎无法定位。
