能，GROUP BY 后可用窗口函数，因其在聚合之后执行，操作的是已分组汇总的行；典型用法是先 GROUP BY 汇总指标，再用窗口函数对汇总结果排序、排名或累计。
能结合，但必须分清执行顺序和数据形态——窗口函数在 GROUP BY 之后运行，操作的是已聚合的行，不是原始明细。
GROUP BY 后还能用窗口函数吗
能，而且很常用。关键在于理解 SQL 执行顺序：FROM → WHERE → GROUP BY → 聚合函数 → HAVING → 窗口函数 → SELECT → ORDER BY。这意味着你写 RANK() OVER (ORDER BY SUM(sales)) 时，SUM(sales) 已经算完了，窗口函数看到的是每组一行的结果。
- 错误认知：以为窗口函数能“穿透”到原始行做计算——它不能，除非你没写
GROUP BY - 正确姿势：先用
GROUP BY汇总出部门/年份/产品线等维度的指标，再用窗口函数对这些汇总行排序、排名、累计 - 典型场景：部门销售额排名、年度同比增速、Top N 分组（如“销售额前3的部门”）
SELECT 中混用聚合列和窗口函数的写法限制
只要所有非聚合字段都出现在 GROUP BY 子句里，就可以安全混用。但要注意别让数据库报错：
-
SELECT dept, SUM(salary), RANK() OVER (ORDER BY SUM(salary) DESC)✅ 合法：dept 是分组字段，SUM(salary) 是聚合结果，RANK() 作用于聚合后结果集 -
SELECT dept, name, SUM(salary)❌ 报错（strict mode 下）：name 既没分组也没聚合，SQL 不知道该取哪一行的 name - 想保留员工姓名又做部门排名？得换路子：用窗口函数替代 GROUP BY（如
SUM(salary) OVER (PARTITION BY dept)），而不是硬塞进 GROUP BY 查询里
CTE 是最稳妥的组合方式
把 GROUP BY 结果先存进 CTE，再在外层加窗口函数，逻辑清晰、调试方便、避免歧义：
WITH dept_summary AS (
SELECT dept, SUM(sales) AS total_sales
FROM sales
GROUP BY dept
)
SELECT dept, total_sales,
RANK() OVER (ORDER BY total_sales DESC) AS rank_by_sales
FROM dept_summary;
- CTE 内部可加
HAVING过滤分组结果（比如只保留total_sales > 10000的部门），外层不能再用HAVING - 列名必须明确：CTE 中别写
SUM(sales)不起别名，否则外层引用RANK() OVER (ORDER BY SUM(sales))会失败或语义模糊 - 如果后续还要按 rank 区间统计（比如“排名前3的部门占总销售额多少”），就得再套一层 SELECT，因为窗口函数结果不能直接被外层
GROUP BY
PARTITION BY 在 GROUP BY 后基本无意义
一旦 GROUP BY 完成，结果只剩每组一行，此时再写 PARTITION BY dept 就等于每个分区只有 1 行——所有窗口函数退化为单行计算，毫无必要：
-
AVG(total_sales) OVER (PARTITION BY dept)❌ 白写：每个 dept 只有一行，avg 就是它自己 -
ROW_NUMBER() OVER (PARTITION BY dept ORDER BY total_sales)❌ 同样无效：partition 内只有一行，row_number 永远是 1 - 真正需要
PARTITION BY的场景，是没用 GROUP BY 时对原始明细做分组内计算（如“每个部门员工薪资排名”）
最容易被忽略的其实是 NULL：如果分组字段含 NULL，GROUP BY 会把所有 NULL 归为一组；而窗口函数默认把 NULL 排在最前或最后（取决于数据库），排序时容易漏掉这一组。动手前先查查你的分组字段有没有 NULL，要不要 WHERE dept IS NOT NULL 过滤掉。
