CTE通过命名逻辑块提升sql可维护性，将嵌套子查询转为分段可读结构，支持复用、单点修改和语义化命名，但不改变执行计划且不缓存结果。
CTE 为什么能提升 SQL 可维护性
因为 CTE 把嵌套子查询变成带名字的逻辑块，让 SQL 从“一行到底”变成“分段可读”。它不改变执行计划，但把 select 拆成多个命名步骤，后续引用时直接用名字，不用反复抄写长子查询。
典型场景：报表中需要多次用到同一组清洗后的用户数据（比如剔除测试账号、合并多表关联结果），用 CTE 定义一次，后面 JOIN 或 WHERE 都能复用。
CTE 和子查询在可维护性上的实际差异
对比下面两个写法：
-- 子查询方式（难维护） SELECT u.name, o.total FROM ( SELECT id, name FROM users WHERE status = 'active' AND is_test = false ) u JOIN ( SELECT user_id, SUM(amount) AS total FROM orders GROUP BY user_id ) o ON u.id = o.user_id;如果要加一个“只看近30天订单”，就得在两个子查询里分别加 WHERE created_at >= ...，容易漏改或改错。
换成 CTE：
-- CTE 方式（易维护） WITH active_users AS ( SELECT id, name FROM users WHERE status = 'active' AND is_test = false ), recent_orders AS ( SELECT user_id, SUM(amount) AS total FROM orders WHERE created_at >= CURRENT_DATE - INTERVAL '30 days' GROUP BY user_id ) SELECT u.name, o.total FROM active_users u JOIN recent_orders o ON u.id = o.user_id;- 每个逻辑块职责单一，命名即文档（
active_users、recent_orders） - 修改时间范围只需动
recent_orders一处 - 调试时可单独运行
SELECT * FROM active_users（虽然 CTE 本身不能直接查，但把定义部分复制出来就能跑）
CTE 的常见误用和性能陷阱
CTE 不是视图，也不是物化表。在多数数据库（postgresql、SQL Server、Snowflake）中，CTE 是“语法糖”，会被内联展开——也就是说，如果同一个 CTE 被引用三次，底层可能执行三次相同计算。
- 不要假设 CTE 会缓存结果；需要复用中间结果且数据量大时，考虑用临时表或物化视图
-
RECURSIVE CTE写错容易无限循环，务必在WHERE或递归终止条件里限制层级（如depth ） - mysql 8.0+ 支持 CTE，但旧版本不支持，上线前确认数据库版本；sqlite 支持有限，不支持递归
什么时候该坚持用子查询而不是 CTE
不是所有嵌套都适合提成 CTE。当子查询非常短、只用一次、且上下文足够清晰时，硬套 CTE 反而增加冗余。
- 例如：
(SELECT MAX(created_at) FROM logs)这种单行标量子查询，提成 CTE 得不偿失 - CTE 块太多（超过 5 个）会让整体结构变重，不如拆成多个小 SQL 或用应用层组合
- 某些 OLAP 引擎（如老版本 Presto）对深层 CTE 展开优化不佳，可能导致计划变差，上线前建议看
EXPLaiN
可维护性的核心不是“用了多少 CTE”，而是“别人看三秒能不能懂你在筛什么、连什么、算什么”。名字是否准确、块是否正交、改动是否局部，比语法形式重要得多。