三层嵌套子查询本质是设计信号而非语法许可，主流数据库在三层以上常放弃条件下推导致性能骤降，应优先用WITH分层、JOIN替代或拆为视图/临时表。
三层嵌套子查询本质是设计信号，不是语法许可
数据库允许写 SELECT * FROM (SELECT * FROM (SELECT * FROM t) AS a) AS b，但不等于你应该这么写。MySQL 8.0、PostgreSQL、SQL Server 等主流引擎在三层及以上嵌套时，常放弃条件下推（condition pushdown），导致中间结果全量计算；EXPLAIN 中常出现 type=ALL 和 rows 暴涨，而单独执行最内层却很快。这不是你 SQL 写得“不够熟练”，而是优化器主动放弃了精确代价估算。
- 标量子查询（如
WHERE score > (SELECT AVG(score) FROM ...)）可读性尚可，但一旦嵌套两层以上（比如WHERE x IN (SELECT y FROM (SELECT z FROM ...))），字段作用域和别名链就极易断裂 - 派生表嵌套（
FROM (SELECT ...) t1 JOIN (SELECT ...) t2）若超过两层，调试时连EXPLAIN FORMAT=TREE都难以定位哪一层丢了索引 - 相关子查询（带外层引用的
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id AND ...)）在百万级表上逐行触发，性能雪崩风险极高
用 WITH 替代嵌套：不是美化，是逻辑分层
WITH 不是“把括号换成 AS”的语法糖，它强制你给每一段独立逻辑命名，从而切断隐式依赖链。多数引擎（MySQL 8.0+、PostgreSQL 9.5+、SQL Server 2005+）会将 CTE 重写为子查询，但可读性提升是确定的，且便于后续加索引、拆测试、做单元比对。
- 必须显式声明字段名：
WITH shipped_orders AS (SELECT order_id, user_id FROM orders WHERE status = 'shipped')—— 不能用SELECT *，否则跨版本迁移时列序变化会导致字段错位 - 多个 CTE 用逗号分隔：
WITH avg_salary AS (...), top_dept AS (...)，不能漏掉逗号 - CTE 执行顺序从上到下，
top_dept可以引用avg_salary，但不能反过来；也不能循环引用（如A AS (SELECT ... FROM B),B AS (SELECT ... FROM A)） - CTE 默认不物化，若中间结果被引用 ≥2 次（如既用于
JOIN又用于WHERE EXISTS），MySQL 8.0.23+ 可加MATERIALIZED提示，SQL Server 需配OPTION (RECOMPILE)
什么情况下必须拆成独立视图或临时表
当某段子查询逻辑需要跨多条语句复用、或涉及权限/列名强约束时，硬建视图比 CTE 更合适——但要避开三个翻车点：
- 权限陷阱：视图执行检查的是**调用者权限**，不是创建者权限。若
v_user_stats查询了orders表，而用户没SELECT权，直接报ERROR 1142 (42000): SELECT command denied - 列名冲突：子查询里写了
SELECT a.id, b.id，建视图会报ERROR 1059 (42000): Identifier name 'id' is too long，必须写成a.id AS a_id, b.id AS b_id - MySQL 5.7 及以前无视图合并：哪怕你只
SELECT a_id FROM v_user_stats WHERE a_id = 123，也会先算完整视图再过滤，WHERE白加
替代方案优先级：JOIN > EXISTS > IN > 多层子查询
绝大多数三层嵌套场景，其实源于误用 IN (SELECT ...) 或相关子查询。这些本可用更稳定的方式表达：
- 用
JOIN替代WHERE x IN (SELECT y FROM ...)：避免NULL导致整个条件失效（IN遇NULL返回UNKNOWN），且天然支持索引下推 - 用
EXISTS替代IN处理大结果集：EXISTS是半连接（semi-join），找到第一条匹配即停，不加载全部子查询结果 - LEFT JOIN 后过滤右表字段，必须写进
ON：写成LEFT JOIN b ON a.id = b.a_id AND b.status = 'paid'，而非LEFT JOIN b ON a.id = b.a_id WHERE b.status = 'paid'（后者实际变成 INNER JOIN） - 跨库/跨引擎 JOIN 时，注意字符集和排序规则是否一致，否则可能静默转类型、丢索引
真正难处理的，从来不是“怎么写出三层嵌套”，而是“怎么让团队其他人一眼看懂你在查什么”。命名、分层、拆解——这三步做完，嵌套本身反而不重要了。
