能，CTE与窗口函数可配合使用：先用CTE准备基础数据，再在主查询SELECT或ORDER BY中调用窗口函数；窗口函数不可出现在CTE定义内部，否则报错。
CTE和窗口函数能一起用吗？当然能，但得按顺序写
CTE本身不执行计算，它只是给查询结果起个名字；窗口函数必须出现在SELECT或ORDER BY里，不能直接塞进CTE定义中。所以正确顺序是：先用CTE把基础数据准备好（比如过滤、JOIN、去重），再在主查询里对CTE结果调用ROW_NUMBER()、RANK()、SUM() OVER()这类函数。
常见错误是试图在CTE内部写OVER子句却漏掉SELECT上下文，或者把窗口函数放在CTE的WHERE里——这会直接报错ERROR: window functions are not allowed in WHERE。
- CTE里只能有普通SELECT语句，支持
GROUP BY、HAVING、JOIN，但不能有OVER、QUALIFY或WINDOW子句 - 窗口函数必须放在主查询的
SELECT列表或ORDER BY中，作用对象是CTE输出的整张临时表 - 如果需要多层窗口逻辑（比如先分组排名，再按排名聚合），就用多个CTE嵌套，每层只做一件事
为什么不用子查询而选CTE+窗口函数？性能和可读性都更稳
子查询在FROM里当派生表时，优化器可能无法下推谓词，导致全表扫描；而CTE在PostgreSQL 12+和MySQL 8.0+默认采用“内联”策略（除非显式加MATERIALIZED），实际执行计划和手写JOIN几乎一样。加上窗口函数本身是一次扫描完成计算，避免了自连接或相关子查询的N²开销。
比如查“每个部门薪资前3的员工”，用子查询要嵌套两层WHERE加IN，CTE+窗口函数只需：
WITH ranked_emp AS (
SELECT id, name, department, salary,
ROW_NUMBER() OVER (PARTITION BY department ORDER BY salary DESC) AS rn
FROM employees
WHERE hire_date >= '2020-01-01'
)
SELECT id, name, department, salary
FROM ranked_emp
WHERE rn <= 3;
- 过滤条件
hire_date写在CTE里，能走索引；若写在主查询WHERE，可能被优化器延迟执行 -
ROW_NUMBER()在CTE输出后计算，分区和排序逻辑清晰可见 - 后续想加累计薪资、部门平均差值，只要在主查询SELECT里追加
SUM(salary) OVER (PARTITION BY department)就行，不用动CTE
递归CTE里能用窗口函数吗？不能，但可以分两步走
递归CTE的锚成员和递归成员都禁止使用窗口函数，否则会报ERROR: window functions are not allowed in recursive query。这不是语法限制，而是执行模型冲突：递归过程需要逐层迭代生成中间结果，而窗口函数依赖完整结果集才能计算分区边界。
真实场景如组织架构树+员工绩效排名，得拆成两步：
- 第一步用
WITH RECURSIVE拉出完整下属链，输出employee_id、manager_id、level - 第二步把这个结果和
employees表JOIN，再用普通CTE或直接主查询加RANK() OVER (PARTITION BY manager_id ORDER BY performance_score DESC)
强行在递归CTE里塞窗口函数，要么报错，要么被优化器静默忽略——后者更危险，容易返回错数据。
CTE物化会影响窗口函数性能吗？看数据库版本和提示
PostgreSQL 12之前默认物化CTE（即强制执行并缓存结果），可能导致内存暴涨；12之后改为默认内联，但遇到复杂CTE或显式写MATERIALIZED时仍会物化。MySQL 8.0则始终内联，除非用/*+ MATERIALIZE */提示。
物化对窗口函数的影响很直接：如果CTE被物化，窗口函数就在物化后的结果上运行，数据量已压缩，性能好；但如果物化过程本身慢（比如没索引的大表GROUP BY），整体就卡在第一步。
- 查执行计划时重点看
CTE Scan节点是否出现，出现说明被物化 - PostgreSQL里加
NOT MATERIALIZED提示可强制内联，但需确认该CTE被引用多次且逻辑简单 - 窗口函数的
PARTITION BY列最好也是CTE里的索引字段，否则排序阶段可能触发磁盘临时文件
