嵌套子查询在超过数据库硬性解析深度限制时直接报错：sql server达32层报msg 319，mysql 5.7+超31层优化器主动拒绝，oracle抛ora-00935，均无法通过参数调优绕过。
CTE 不是“更好”，而是解决特定问题的更合适工具——当嵌套超过两层、逻辑需复用、或调试困难时，CTE 就成了事实标准；但单层子查询在简单场景下更轻量、无额外语法负担。
嵌套子查询在什么情况下会直接报错？
不是性能慢，而是根本跑不起来：SQL Server 报 Msg 319（最大嵌套32层）、MySQL 5.7+ 在深度嵌套时优化器主动放弃重写、Oracle 抛 ORA-00935。这些限制无法通过调优参数绕过。
- 三层以上相关子查询（如
WHERE x IN (SELECT ... WHERE y IN (SELECT ...))）已逼近危险区 - 同一子查询在
SELECT和WHERE中重复出现，实际执行可能被展开为四层甚至更多 -
EXPLAIN输出里看不到嵌套层级对应关系，你无法确认哪段 SQL 对应哪层子查询
CTE 的命名和引用规则怎么避免常见错误？
很多人把 WITH 当成“高级括号”，结果写出不可执行的循环依赖或作用域混乱。
- CTE 必须按顺序定义：后面定义的
cte_b可以FROM cte_a，但cte_a不能引用cte_b - 别名字段必须显式声明：
WITH user_stats AS (SELECT user_id, COUNT(*) cnt FROM orders GROUP BY user_id)——漏写cnt别名，后续引用时会报Unknown column 'cnt' -
WITH只作用于紧随其后的**单条语句**；想复用？得重写WITH，或改用临时表
哪些嵌套子查询不该强行改成 CTE？
不是所有嵌套都该“手术”。盲目重构反而增加维护成本。
- 单层非相关子查询（如
SELECT name FROM users WHERE id = (SELECT manager_id FROM dept WHERE dept_name = 'sales')）——结构清晰，改 CTE 纯属多此一举 - 带
LIMIT/TOP的子查询（如 MySQL 中(SELECT * FROM log ORDER BY ts DESC LIMIT 1)）——CTE 无法直接加LIMIT，需套一层子查询，反而更啰嗦 - 被引用仅一次、且不含聚合/JOIN 的简单过滤（如
WHERE status IN (SELECT code FROM status_ref WHERE active = 1)）——CTE 带来零收益，还多一行WITH
CTE 的真正门槛不在语法，而在判断：这一步是否承载明确业务含义、是否会被多处消费、是否需要单独验证。漏掉这三点中的任意一个，就只是把嵌套换了个写法，没解决根本问题。
