cte比嵌套子查询更易读，因其将逻辑分层具名化，避免多层括号嵌套和重复书写；例如同一子查询在select和where中各用一次时，嵌套写法需复制两遍，而cte定义一次即可多次引用。
为什么CTE比嵌套子查询更易读？
因为CTE把逻辑拆开命名，避免了多层括号嵌套和重复书写。比如一个子查询在SELECT和WHERE里各用一次，嵌套写法就得复制粘贴两遍；而CTE只需定义一次，后面直接引用cte_name即可。
但注意：CTE不是万能优化器——它不改变执行计划本质，只是语法糖。PostgreSQL和SQL Server会把简单CTE内联展开，而某些复杂CTE（含递归、窗口函数或多次引用）可能物化成临时结果，反而变慢。
怎么把三层嵌套子查询转成CTE？
按从内到外的依赖顺序逐层提取，每层起一个有意义的名字，比如raw_orders、filtered_orders、aggregated_summary。别用cte1、cte2这种名字，否则调试时根本不知道它干啥。
实操步骤：
- 先找出最内层子查询（通常在
FROM或WHERE里），把它拎出来作为第一个CTE - 把原SQL中调用它的位置，替换成
FROM cte_name - 重复这个过程，直到所有子查询都变成CTE，主查询只剩最外层逻辑
- 检查列名是否冲突：CTE里用了
AS别名，主查询引用时必须用那个别名，不能沿用原表字段名
示例：原SQL里有(SELECT SUM(amount) FROM orders WHERE user_id = u.id)，改写后应为：
WITH user_orders AS ( SELECT user_id, SUM(amount) AS total_spent FROM orders GROUP BY user_id ) SELECT u.name, o.total_spent FROM users u LEFT JOIN user_orders o ON u.id = o.user_id;
哪些情况CTE反而让SQL变慢？
当CTE被多次引用且数据量大时，有些数据库（如旧版MySQL）会重复执行它，而不是缓存结果。这时不如用临时表，或者干脆保留子查询——特别是只用一次的简单子查询，CTE纯属增加阅读负担。
容易踩的坑：
-
WITH RECURSIVE必须有终止条件，否则报错infinite recursion detected - CTE定义必须紧贴
SELECT前，中间不能插SET或注释（MySQL 8.0+允许部分注释，但Oracle不行） - CTE里的
ORDER BY无效，除非配合LIMIT（仅PostgreSQL支持），否则会被忽略 - 不能在同一个
WITH块里循环引用，比如cte1引用cte2，cte2又引用cte1
CTE和子查询在JOIN里怎么选？
如果子查询只用于JOIN右表，且结果集小、逻辑清晰，CTE更直观；但如果子查询带相关条件（比如WHERE t1.id = t2.ref_id），强行改成CTE会导致无法下推关联条件，性能暴跌。
判断依据很简单：运行EXPLAIN看执行计划。如果CTE版本出现Materialize节点且耗时明显上升，就该回退。
另外，CTE不能直接用在INSERT ... SELECT的SELECT部分里套多层CTE（某些MySQL版本报ERROR 1248: Every derived table must have its own alias），得在外层再包一层SELECT *。
真正麻烦的从来不是语法转换，而是搞清哪一层计算必须提前物化、哪一层应该留给优化器去合并——这得看执行计划，不是靠重写就能解决的。
