CTE 应用于聚合结果需复用、分步验证或递归的场景，而非简单 GROUP BY 套壳；满足引用≥2次、逻辑分层、复杂组合或需单独验证时才值得拆分，并须规范命名、显式列名、避免同名列与窗口别名误用。
CTE 不是用来给简单 GROUP BY 套壳的，它真正起作用的地方，是当你需要把聚合结果反复用、分步验、或带递归时。
什么时候该用 CTE 拆聚合？
不是所有聚合都值得拆进 CTE。关键看是否满足以下任一条件：
- 同一组聚合结果在主查询中被引用 ≥ 2 次（比如既要算平均值，又要算高于平均的占比）
- 后续步骤依赖前一步的聚合结果，且逻辑明显分层（如先按用户聚合订单总额，再按总额分档统计人数）
- 聚合涉及多表 JOIN + 窗口函数 + 过滤组合，直接写嵌套子查询已难以调试
- 你需要单独执行某一层验证数据合理性（例如单独跑
user_revenueCTE 看 sum(amount) 是否异常）
怎么写才不翻车？显式列名和字段别名是底线
漏写 CTE 的列名列表，或者在 JOIN 后直接用 *，是高频报错源头。尤其跨数据库时行为不一致：
- 必须写
WITH user_summary(user_id, total_spent, order_count) AS (...)，不能只写WITH user_summary AS (...) - JOIN 多张表时，禁止出现同名列未限定，例如
orders.id和users.id都返回，又没加别名 → 后续 CTE 引用id必报column reference "id" is ambiguous - 避免在 CTE 内部用
SELECT *，尤其含窗口函数时——字段顺序一旦变动，下游所有引用都会错位
WHERE 里不能直接用窗口别名，这是硬限制
写了 RANK() OVER (...) AS rnk，想在后续过滤中写 WHERE rnk = 1？多数数据库会拒绝执行：
- 窗口函数在 SQL 执行顺序中晚于
WHERE，所以别名不可见；必须用子查询或外层 CTE 包裹 - 正确写法是：先在 CTE 中计算
rnk，再在主查询中SELECT * FROM ranked WHERE rnk = 1（PostgreSQL/SQL Server 支持；旧版 SQLite 可能仍报错） - 如果还要对窗口结果做聚合（如统计每组 top3 的平均值），就得再套一层 CTE，不能试图在同一个 SELECT 中混用
GROUP BY和未包裹的窗口别名
MySQL 版本和物化行为要提前确认
CTE 不是“写了就快”，它的执行策略受数据库版本和优化器影响很大：
- MySQL 5.7 及更早版本不支持
WITH，直接报ERROR 1064；必须升级到 8.0+ - PostgreSQL 默认物化 CTE（即先算完再用），即使只引用一次，也可能比等效子查询慢——因为绕过了索引下推；若确定只用一次，优先考虑子查询
- SQL Server 对 CTE 的物化控制更细，可用
OPTION (USE HINT('DISABLE_OPTIMIZER_ROWGOAL'))干预，但非常规操作
最常被忽略的一点：CTE 的命名不是为了缩写，而是为了暴露语义。写 WITH high_value_users AS ... 比 WITH t1 AS ... 多花两秒，但能省下十分钟解释逻辑的时间。而一旦开始为调试单独执行某层 CTE，你就再也回不去全堆在主查询里的写法了。
