CTE能提升SQL可读性、可调性和可复用性，但作用域仅限紧随其后的单条DML语句；多层嵌套可拆解为命名步骤，递归CTE需设终止条件防溢出，且多数数据库中CTE不缓存结果，大数据量时性能未必优于临时表。
直接说结论：用 WITH 定义多个逻辑块，把嵌套子查询“拉平”，能立刻让复杂 SELECT 可读、可调、可复用——但必须紧贴主查询写，且不能跨语句复用。
CTE 必须紧跟主查询，否则直接失效
很多人写完 WITH 后加了一行注释、空行或调试 SELECT，再写真正要用的语句，结果报错 Invalid object name 'xxx'。这是因为 CTE 的作用域仅限于紧随其后的那一条 DML 语句（SELECT/INSERT/UPDATE/DELETE）。
-
WITH user_total AS (SELECT user_id, SUM(amount) FROM orders GROUP BY user_id)后面必须立刻跟SELECT ... FROM user_total - 中间插一句
SELECT * FROM users就会让user_total失效 - 想复用？得重新定义一遍，或者拆成视图/临时表（但那就不是 CTE 了）
多层嵌套 SELECT 拆成命名步骤更安全
原始写法像套娃：SELECT * FROM (SELECT * FROM (SELECT user_id, COUNT(*) c FROM logs GROUP BY user_id) t1 WHERE c > 5) t2 JOIN users u ON t2.user_id = u.id。从里往外读，改一处容易漏掉关联列名或别名。
换成 CTE，每步有名字、有职责：
WITH log_count AS ( SELECT user_id, COUNT(*) AS cnt FROM logs GROUP BY user_id ), high_freq AS ( SELECT user_id FROM log_count WHERE cnt > 5 ) SELECT u.*, h.cnt FROM high_freq h JOIN users u ON h.user_id = u.id;
- 列名在
log_count里定义清楚，后续步骤直接引用，不怕拼错 - 调试时可单独运行
SELECT * FROM log_count或SELECT * FROM high_freq验证中间结果 - 如果某步要加过滤条件（比如只查最近7天），只改对应 CTE 内部，不影响其他逻辑
递归 CTE 容易栈溢出，必须设终止条件
查组织架构、BOM 清单这类树形结构时，WITH RECURSIVE 是刚需，但没写好会卡死或报错 Maximum recursion exceeded。
- 递归部分（
UNION ALL后）必须包含能收敛的条件，比如level < 10或parent_id IS NOT NULL - SQL Server 默认递归上限是 100，超了要加
OPTION (MAXRECURSION n)，但不建议盲目调高，先确认数据是否有环 - MySQL 8.0+ 和 PostgreSQL 支持
RECURSIVE，但旧版 MySQL 不支持，得换方案（如存储过程或应用层迭代）
CTE 不是万能缓存，大数据量时性能未必优于临时表
有人以为 CTE 是“内存临时表”，其实多数数据库（如 SQL Server、PostgreSQL）对 CTE 是**重计算**策略：如果主查询里多次引用同一个 CTE，它可能被反复执行，而不是只算一次。
- 比如
SELECT * FROM a_cte t1 JOIN a_cte t2 ON t1.id = t2.parent_id，a_cte很可能跑两遍 - 真要复用且数据量大，不如显式建
#temp_table或物化视图 - CTE 的优势在逻辑清晰，不在性能优化；想提速，优先看索引和执行计划，而不是硬套 CTE
CTE 的价值不在语法炫技，而在把“人脑难跟踪的嵌套”变成“眼睛一眼扫清的步骤”。但每一步都得自己负责——命名是否准确、依赖是否闭环、终止条件是否兜底，这些地方一松懈，反而比原来更难 debug。
