CTE不是语法糖，它支持递归查询、影响执行计划与性能优化、增强模块化与维护性，但有作用域限制和物化开销等实际约束。
不是语法糖。CTE（Common Table Expression）用 WITH 定义，表面看只是让子查询更易读，但它有不可替代的实际能力。
支持递归查询，子查询做不到
普通子查询无法引用自身，而 CTE 可以通过自引用实现树形结构遍历、路径展开、层级计数等操作。
- 例如：查某个部门的所有下级部门（无限层级），只需在 CTE 中
UNION ALL自身，配合终止条件即可 - 递归 CTE 有明确的锚点（anchor）和递归成员（recursive member），SQL 引擎会迭代执行，这是子查询语法完全无法模拟的
提升可读性的同时，影响执行计划和性能优化
CTE 不是“先算完再用”，多数数据库（如 PostgreSQL、SQL Server）会将其内联展开，但某些场景下它会改变优化器行为：
- 多次引用同一 CTE 时，PostgreSQL 默认会物化（materialize）结果（尤其带
OFFSET/LIMIT或复杂逻辑时），避免重复计算；SQL Server 则通常内联，但可用OPTION (USE HINT('ENABLE_QUERY_OPTIMIZER_HOTFIXES'))等干预 - CTE 提供了逻辑命名边界，让优化器更容易识别公共表达式，有时反而触发更好的计划选择
增强模块化与维护性，不止于“写起来顺”
CTE 允许把复杂查询拆成多个带名步骤，每个步骤专注单一职责：
- 比如先过滤原始数据（
raw_data），再聚合（summary），最后关联维度表（enriched）——各步可独立测试、复用、加注释 - 相比嵌套多层子查询，CTE 的缩进和命名让逻辑流向更清晰，大幅降低后期排查和修改成本
- 部分数据库（如 BigQuery）还支持 CTE 嵌套定义、多个 CTE 并列，进一步支撑分析逻辑分层
存在实际限制，不能随意替代子查询
CTE 有作用域和生命周期约束，这反而是它的设计特性：
- 只在紧随其后的单个 SQL 语句中有效，不能跨语句复用（除非用临时表或视图）
- 不能在视图定义里直接引用外部参数（需结合函数或动态 SQL），而某些子查询形式更灵活
- 过度嵌套或滥用物化可能增加内存开销，尤其在大数据量递归或多次引用时需留意执行计划
CTE 是兼具表达力、功能性和工程价值的语言特性，不是简化写法的包装纸。
