窗口函数不能与group by混用在同一层select中，因二者语义冲突：group by压缩行，窗口函数需原始行粒度；必须通过子查询或cte分两层实现，先窗口计算再聚合。
窗口函数不能和GROUP BY混用在同一层SELECT中
直接在含 GROUP BY 的查询里写 ROW_NUMBER() OVER(...) 或 COUNT(*) OVER(...) 会报错（MySQL 8.0+、PostgreSQL、SQL Server 均如此）。因为 GROUP BY 已将多行压缩为一组，而窗口函数需要原始行粒度才能划分窗口。两者语义冲突：一个要“压平”，一个要“保行”。
常见错误现象：ERROR 1055 (42000): Expression #1 of SELECT list is not in GROUP BY clause（尤其在 MySQL 严格模式下）或 PostgreSQL 报 window function requires an OVER clause 但实际是上下文不匹配。
- 想统计每个部门的员工数，同时显示每位员工的入职顺序 → 先不
GROUP BY，用窗口函数算序号，再按需聚合 - 想查出订单量 Top 3 的用户，并附上其订单占比 → 必须分两层：内层窗口算占比，外层
GROUP BY或过滤 - 误以为
COUNT(*) OVER(PARTITION BY dept)能替代GROUP BY dept→ 它只是给每行加个值，不会减少行数
先窗口后分组：典型两层结构
绝大多数协同场景都得靠子查询或 CTE 拆成两步：第一层保留明细 + 窗口计算，第二层对结果做 GROUP BY 或过滤。这是最可控、兼容性最好的做法。
例如：统计每个城市的平均订单金额，并标记该城市订单金额是否高于全站均值
WITH city_orders AS (
SELECT
city,
amount,
AVG(amount) OVER(PARTITION BY city) AS city_avg,
AVG(amount) OVER() AS global_avg
FROM orders
)
SELECT
city,
ROUND(city_avg, 2) AS avg_amount,
COUNT(*) AS order_cnt,
MAX(CASE WHEN city_avg > global_avg THEN 1 ELSE 0 END) AS above_global
FROM city_orders
GROUP BY city;
-
AVG(amount) OVER(PARTITION BY city)在明细层算出每行所属城市的均值（所有行值相同） -
AVG(amount) OVER()算全站均值，也广播到每行 - 外层
GROUP BY city聚合时，city_avg和global_avg已是确定值，可安全参与COUNT、MAX等操作 - 避免在
HAVING或WHERE中直接引用窗口函数结果——必须先落到子查询列里
GROUP BY 后还想看明细？用窗口函数替代自连接
当原始需求是“既要分组汇总，又要保留原始记录”，比如展示每个用户的每笔订单，同时附上该用户的总订单数、首单时间、最新订单金额——这时候不该用 GROUP BY + 子查询关联，而应直接跳过 GROUP BY，全靠窗口函数。
示例：
SELECT user_id, order_id, amount, COUNT(*) OVER(PARTITION BY user_id) AS total_orders, MIN(order_time) OVER(PARTITION BY user_id) AS first_order_time, FIRST_VALUE(amount) OVER(PARTITION BY user_id ORDER BY order_time DESC) AS latest_amount FROM orders;
- 没有
GROUP BY，所以每行订单都保留；窗口函数自动按user_id分组并计算聚合值 -
FIRST_VALUE(...) OVER(... ORDER BY ...)比MAX()更精准，能取到对应行的完整字段值 - 性能上通常优于
LEFT JOIN (SELECT user_id, COUNT(*) ...) u_cnt ON ...，尤其数据量大时 - 注意
ORDER BY在窗口定义中的必要性：像MIN(order_time)不依赖排序，但FIRST_VALUE必须指定
GROUPING SETS / CUBE 和窗口函数不兼容
GROUPING SETS、CUBE 是扩展的分组语法，用于生成多维小计。它们和窗口函数无法共存于同一查询层级——因为这些语法本身已改变结果集结构（引入 GROUPING() 标记、空维度等），窗口函数无法可靠识别分区边界。
如果你需要在小计行上再加动态指标（比如“各部门销售额占全公司比例”），必须：
- 先用
GROUPING SETS产出带小计的宽表（含GROUPING(dept)列） - 再套一层查询，用
SUM() OVER()计算全公司总计，然后做除法 - 不能指望
ROUND(SUM(sales) / SUM(sales) OVER(), 4)在GROUPING SETS查询里直接生效——某些数据库会报错，或返回意外的 NULL
真正容易被忽略的是：窗口函数的 PARTITION BY 表达式，必须和 GROUP BY（或 GROUPING SETS）的维度逻辑对齐。一旦错位，比如 PARTITION BY dept 却在 GROUP BY city 结果上运行，数值就完全不可信了。
