必须先过滤再聚合。CTE中应将高选择性WHERE条件（如created_at >= '2026-01-01'）提前写入，避免全表扫描后再过滤；需配合复合索引，且只选必要列，链式CTE应分阶段处理，PostgreSQL默认物化需谨慎，MySQL 8.0链式更安全但依赖谓词下推。
CTE里该不该先过滤再聚合？
必须先过滤。很多慢查询的根源是把 WHERE 条件放在主查询里，导致 CTE 内部先扫全表、再算聚合——哪怕只有 0.1% 的数据符合条件。
常见错误现象：EXPLAIN ANALYZE 显示 Seq Scan on orders 扫了上百万行，但最终结果只几百条。
- 把高选择性条件（如
status = 'completed'、created_at >= '2026-01-01'）直接写进 CTE 的SELECT子句中 - 确保过滤字段上有索引，尤其是复合索引要匹配后续
GROUP BY和ORDER BY的顺序 - 别在 CTE 里用
SELECT *，只选真正需要的列，减少内存和排序开销
多个聚合步骤怎么链式写才不掉坑？
用逗号分隔多个 CTE，每个负责一个原子操作：过滤 → 聚合 → 衍生计算 → 关联补全。不能指望一个 CTE 同时干所有事。
典型翻车点：GROUP BY 列不一致报错（PostgreSQL 严格）、MySQL 在宽松模式下静默出错但结果偏差。
- 每个 CTE 的输出列名必须显式定义，不能依赖
SELECT *推导 - 第二个 CTE 可以引用第一个，但列名要完全匹配，大小写敏感（尤其在 PostgreSQL 中）
- 若需跨 CTE 做比较（比如部门均薪 vs 公司均薪），用
CROSS JOIN连接单行结果集，避免漏连接条件触发笛卡尔积
PostgreSQL 中 CTE 真的“不物化”吗？
默认物化。PG 把每个 CTE 当作临时表处理，即使只引用一次，也可能多扫一遍基表——这对窗口函数 + 多层聚合尤其危险。
现象：执行计划里出现两次 Seq Scan on orders，或明显 I/O 等待飙升。
- PG 12+ 可加
MATERIALIZED或NOT MATERIALIZED提示，但后者只是建议，不保证内联 - 更稳妥的做法是：当 CTE 只被引用一次且无递归时，直接改写成子查询，让优化器有机会内联
- 如果确实需要复用且数据量大（>1 万行），优先考虑
#temp_table而非依赖 CTE 缓存
MySQL 8.0 的 CTE 能放心链式调用吗？
可以，而且比 PG 更轻量。MySQL 8.0 默认不强制物化 CTE（除非递归或显式声明 WITH RECURSIVE），链式结构基本等价于语法糖。
但别因此忽略谓词下推——索引能否生效，仍取决于 CTE 内部是否提前过滤。
- 链式 CTE 中，每一步的
WHERE和GROUP BY都可能触发索引下推，但前提是字段上有合适索引 -
UNION ALL拼接多个 CTE 分支时，各分支输出列数、类型、顺序必须严格一致，否则报错all queries in a UNION must have the same number of columns - 避免在 CTE 里写
ORDER BY（除非配合OFFSET/FETCH），MySQL 会直接报错
