cte本身不执行聚合，必须在内部显式写出group by和基础聚合函数（如sum、count），并为聚合列命名；外层引用时只能使用cte输出的列，二次聚合需在外层显式编写，嵌套聚合会报错。
CTE 必须先完成分组聚合，再作为数据源被外层引用
CTE 本身不执行聚合，它只是命名一个中间结果集。想用 CTE 配合聚合函数，第一步就得在 CTE 内部把 GROUP BY 和基础聚合写清楚——比如 SUM()、COUNT()、AVG() 等必须出现在 CTE 的 SELECT 列表里，且所有非聚合字段都要进 GROUP BY。
常见错误是把 CTE 当成“函数调用”，以为在外层 SELECT 里写 AVG(cte.total) 就自动触发二次计算——其实 CTE 只是临时表，外层能用的只有它 SELECT 出来的列。
- CTE 中漏写
GROUP BY→ 报错或返回单行（取决于数据库，默认行为不一致） - CTE 中没显式命名聚合列（如
SUM(sales) AS dept_total）→ 外层无法用别名引用 - CTE 名和真实表重名 → PostgreSQL/SQL Server 会优先解析为基表，导致逻辑错乱
二次聚合必须在外层查询中显式写出，不能藏在 CTE 里
想算“各部门平均薪资的中位数”或“客户总消费额的均值”，CTE 只负责产出第一层结果（每个部门的平均值 / 每个客户的总消费），外层查询才负责 AVG()、PERCENTILE_CONT() 这类操作。
直接在 CTE 里套两层聚合（比如 AVG(SUM(sales))）会报错，错误信息通常是：ERROR: aggregate function calls cannot be nested（PostgreSQL）、Invalid use of aggregate function（SQL Server）或 MySQL 的 Invalid group function nesting。
- MySQL 5.7 不支持 CTE，若需兼容旧版，只能退回派生表写法
-
PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY ...)这类窗口式聚合，必须在外层或另一个 CTE 中调用，不能放在同一 CTE 的聚合字段里 - CTE 定义后可被多次引用，适合同时算
AVG()和MAX()：外层一次查，不用重复跑聚合逻辑
UPDATE 场景下，CTE 的聚合列必须显式出现在 SELECT 列表中
SQL Server 或 PostgreSQL 里用 CTE 做聚合驱动的更新时，聚合结果不是“可用变量”，而是必须作为 CTE 输出列存在，才能在 UPDATE 的 SET 或 WHERE 中引用。
例如更新部门状态，条件是员工数 > 5，那 COUNT(e.EmployeeID) 就得写在 CTE 的 SELECT 里，并起别名（如 emp_count），否则 WHERE emp_count > 5 会报列不存在。
- CTE 前必须加分号（
;），否则 SQL Server 直接报Incorrect syntax near the keyword 'with' - 含
GROUP BY的 CTE 默认不可更新，但 SQL Server 允许更新——前提是目标列属于单个基表，且 CTE 没用DISTINCT、JOIN多表或窗口函数 - 如果用了
LEFT JOIN保留空部门，COUNT()返回0而不是NULL，注意WHERE emp_count > 5不会误筛掉这些行
CTE 与子查询性能差异不大，但可读性优势明显
CTE 和派生表（子查询）在执行计划里往往生成相同物理操作，性能基本一致。真正差别在于维护性和调试成本：CTE 把聚合逻辑独立命名，比嵌套三层子查询更容易定位问题。
不过要注意，CTE 不是视图，每次被引用都会重新执行——如果同一个 CTE 被外层多次引用（比如 JOIN 两次），数据库可能重复计算内部聚合。这时不如物化成临时表，或改用带 MATERIALIZED 提示的 CTE（PostgreSQL 12+ 支持）。
- CTE 中聚合字段若含
NULL，外层AVG()会自动忽略它们；但COUNT(*)和COUNT(col)行为不同，务必确认统计口径 - 跨数据库迁移时，CTE 兼容性比子查询略差：MySQL 5.7 不支持，SQLite 需要 3.8.3+，旧版 Oracle 需要
WITH后加AS - 真正容易被忽略的是：CTE 输出列的数据类型由内层表达式决定，比如
SUM(int_col)在某些库中返回BIGINT，外层做除法时可能隐式转成浮点，影响精度
