cte本身不加速聚合，但能精准控制聚合时机、避免中间结果膨胀；多数慢查询源于将cte当子查询语法糖使用，导致全表扫描后再过滤，正确做法是先在cte内完成高选择性过滤和单层聚合，并配合复合索引。
CTE 本身不加速聚合，但能帮你把聚合时机卡准、避免中间结果膨胀——多数“慢”不是因为用了 CTE，而是它被当成了子查询的语法糖来用。
先在 CTE 里完成过滤和单层聚合，别留到主查询
很多慢查询的执行计划里能看到 Seq Scan on orders 扫了上百万行，但最终只返回几百条。根源是 WHERE 条件（比如 created_at >= '2026-01-01' 或 status = 'completed'）写在主查询里，导致 CTE 先全表聚合再过滤。
- 正确做法：把高选择性条件直接塞进 CTE 的
SELECT子句中，配合对应字段上的复合索引（例如(status, created_at, user_id)） - 别在 CTE 里写
SELECT *，只选后续真正需要的列；多一个order_date字段，就多一份排序和内存开销 - 如果主查询还要按
users.city分组，那 CTE 里就不能只GROUP BY order_id，得提前关联并带上user_id，否则外层 JOIN 后分组会错乱
链式 CTE 必须分阶段：过滤 → 聚合 → 衍生计算 → 关联补全
一个 CTE 同时干四件事，等于把所有逻辑压进黑盒，出错了没法定位，优化器也难生成好计划。链式结构不是炫技，是让每一步输出可控、可验、可复用。
- 第一层 CTE（如
filtered_orders）只做带索引字段的过滤，不 JOIN、不聚合 - 第二层（如
user_summary）基于第一层做GROUP BY user_id，算SUM(amount)、COUNT(*)等 - 第三层（如
high_value_users）引用第二层，加HAVING SUM(amount) > 1000这类基于聚合结果的过滤 - 最后一层主查询才
JOIN users补姓名、城市等维度信息——避免在聚合前就把大维表拖进来
PostgreSQL 默认物化，MySQL 8.0 更倾向内联，别默认“CTE 就是缓存”
你在 PostgreSQL 里看到执行计划里出现两次 Seq Scan on orders，大概率是因为 CTE 被物化了——哪怕只被引用一次，它也被当成临时表重算一遍。这不是 bug，是设计行为。
- PG 12+ 可显式加
MATERIALIZED或NOT MATERIALIZED提示，但后者只是建议，优化器不一定听 - 更稳妥的做法：如果 CTE 只被引用一次，且无递归，直接改写成子查询（
(SELECT ...) AS t），让优化器有机会内联 - MySQL 8.0 对 CTE 的谓词下推更激进，同一 CTE 引用多次时，常能复用中间结果；但若跨 CTE 做
CROSS JOIN比较均值，仍要小心笛卡尔积 - SQL Server 和 Oracle 的行为介于两者之间，依赖版本和统计信息，不能假设“写了 WITH 就省事”
递归 CTE 处理层级聚合时，展开和二次分组必须分离
递归 CTE 不能直接套 SUM() 或 GROUP BY level，它本质是逐行展开的迭代过程。想算“每层总奖金”，就得先展开成平表，再在外层做聚合。
- 锚点查询（顶层节点）和递归成员必须用
UNION ALL连接，缺一不可，否则报错Msg 530 - 必须加
OPTION (MAXRECURSION n)，SQL Server 默认限 100 层；不确定深度时可用OPTION (MAXRECURSION 0)，但得监控栈使用 - 展开完成后，用外层
SELECT level, SUM(amount) FROM (...) GROUP BY level才是安全做法；在递归体内部加聚合函数会直接报错或静默失败 - 如果层级深度超 200，或者单层节点数过万，优先考虑预生成路径字段（如
path = '/1/2/4/'），用字符串函数替代递归，性能更稳
最常被忽略的一点：CTE 的列名必须显式定义，尤其在 PostgreSQL 中大小写敏感；而 SQL Server 不同版本对 SELECT * 推导列序的行为不一致——看似能跑通的语句，在升级后可能突然报错或结果错位。
