子查询位置决定功能：WHERE 中作条件过滤，FROM 中作临时表（须起别名），SELECT 中作标量值（须单行单列）；相关子查询性能差，应优先转 JOIN；NOT IN 遇 NULL 失效，改用 NOT EXISTS。
子查询写在哪？WHERE、FROM、SELECT 三处行为完全不同
子查询不是随便塞进去就能跑通的，位置决定它能干啥。在 WHERE 里是条件过滤，在 FROM 里是临时表，在 SELECT 里是标量值——三者语法约束和执行逻辑差得远。
常见错误：把返回多行的子查询直接塞进 SELECT 或 WHERE 后面用等号比较，立刻报错 Subquery returns more than 1 row。
-
WHERE中用=或IN要严格匹配子查询结果行数：单值用=，多值必须用IN -
FROM子句里的子查询必须起别名（MySQL 强制，PostgreSQL 允许省略但建议写），否则报Every derived table must have its own alias -
SELECT列表里的子查询必须确保只返回一行一列，否则语法直接不通过
相关子查询 vs 非相关子查询：性能差别可能十倍起跳
非相关子查询（inner query 不依赖 outer query）只执行一次；相关子查询（比如 WHERE t1.id = (SELECT t2.ref_id FROM t2 WHERE t2.status = t1.status)）会为外层每一行重复执行——数据量一大就卡死。
典型场景：查每个用户最新一条订单时间，用相关子查询写法看着直观，但比用窗口函数或 JOIN + GROUP BY 慢得多。
- 先看执行计划：
EXPLAIN输出里如果出现DEPENDENT SUBQUERY，基本可以认定是相关子查询，要警惕 - 能转成
JOIN的尽量转，尤其是涉及聚合或排序时，数据库优化器对JOIN的处理更成熟 - MySQL 8.0+ 支持 CTE，用
WITH把子查询提出来重用，既清晰又避免重复计算
NULL 值穿透：子查询结果含 NULL 时 WHERE 条件常静默失效
这是最隐蔽也最容易被忽略的问题。当子查询返回 NULL，而你用 NOT IN 过滤时，整条语句结果直接变空——不是没数据，是逻辑被 NULL 截断了。
比如：SELECT * FROM orders WHERE user_id NOT IN (SELECT id FROM users WHERE type = 'test')，只要子查询里有一个 id 是 NULL，整个 NOT IN 就判定为未知（UNKNOWN），该行被排除。
- 用
NOT EXISTS替代NOT IN，它对NULL不敏感 - 显式过滤掉
NULL：SELECT id FROM users WHERE type = 'test' AND id IS NOT NULL - 记住：任何与
NULL的比较（=、!=、IN、NOT IN）结果都是UNKNOWN，不是TRUE或FALSE
CTE 和子查询选哪个？别只看写起来顺不顺
CTE（WITH）看起来只是子查询加了个名字，但实际影响执行策略。有些数据库（如 PostgreSQL）会对 CTE 做物化（materialize），也就是先算完再用；而 MySQL 8.0 默认不物化，只是语法糖，执行计划跟内联子查询一样。
这意味着：你以为把子查询拎出来能提升复用性，结果发现执行两次，还多了临时表开销。
- PostgreSQL 中 CTE 默认物化，适合“算一次、用多次”的场景；但加
NOT MATERIALIZED可以强制不物化，让优化器自由选择 - MySQL 8.0 的 CTE 不物化，性能等价于子查询，主要价值在可读性和递归支持
- 如果子查询本身很重（比如带聚合 + 多表 JOIN），又需要反复引用，优先考虑建物化视图或临时表，而不是硬靠 CTE
模块化不是把 SQL 拆成小块就完事，关键是拆出来的每一块是否真正独立、可验证、不影响执行路径。很多所谓“清晰”的子查询，其实悄悄拖慢了整个查询。
