窗口函数不能与聚合函数混用在同一级SELECT，必须拆分为子查询或CTE；它不减少行数，无法替代多对多JOIN后的预聚合；QUALIFY在PostgreSQL和MySQL中不支持，需用子查询+WHERE替代。
窗口函数不能和聚合函数混用在同一级 SELECT
这是硬性语法限制，不是性能建议。比如 SUM(amount) 和 AVG(amount) OVER (PARTITION BY status) 不能同时出现在同一个 SELECT 子句里——MySQL 8.0、PostgreSQL、SQL Server 都会直接报错 invalid reference to FROM-clause entry 或类似错误。
常见错误写法：SELECT order_id, SUM(price), AVG(price) OVER (PARTITION BY category) —— 看似想既算总和又算分组均值，但数据库解析器会在语法校验阶段拒绝。
- 必须拆成两层：外层用子查询或 CTE 先完成聚合，再在外层加窗口函数
- 或者反过来：先用窗口函数计算明细层指标（如
SUM(price) OVER (PARTITION BY order_id)），再用GROUP BY做上层汇总 - 注意窗口函数只能出现在
SELECT和ORDER BY中，不能用于WHERE、HAVING或ON条件
窗口函数无法消除多对多 JOIN 后的行数膨胀
窗口函数本身不减少行数，它只是在现有结果集上附加计算列。如果你已经 JOIN 了多对多关联表（比如 users ↔ user_role ↔ roles），那一条用户记录可能变成 5 行（对应 5 个角色），COUNT(*) OVER (PARTITION BY user_id) 算出来确实是 5，但这不是“该用户有几个角色”的业务含义——它只是告诉你当前结果集里这条用户出现了几次。
真正要统计角色数量，得先预聚合中间表：(SELECT user_id, COUNT(*) AS role_count FROM user_role GROUP BY user_id)，再 LEFT JOIN 回主表。
- 窗口函数适合“广播已知聚合值”，比如把预聚合好的
role_count用FIRST_VALUE()或MAX()复制到每行，但它不能替代聚合逻辑本身 - 若强行用
COUNT(DISTINCT role_id) OVER (PARTITION BY user_id)，部分引擎（如 Presto/Trino）支持，但 PostgreSQL 和 MySQL 8.0 不支持该语法 - 别指望
ROW_NUMBER() OVER (PARTITION BY user_id)能“修复”膨胀——它只是编号，不是去重
QUALIFY 在主流数据库中不可用
QUALIFY 是 Snowflake、BigQuery、Doris 等引擎的语法糖，用来直接过滤窗口计算结果（比如只取每个用户的最新角色记录）。但 PostgreSQL 和 MySQL 8.0+ 不支持 QUALIFY，你写 SELECT * FROM t QUALIFY ROW_NUMBER() OVER (...) = 1 会报错 syntax error near QUALIFY。
替代方案必须显式套一层：
- MySQL/PostgreSQL：用 CTE 或子查询，再
WHERE rn = 1 - 别漏掉子查询别名，否则 MySQL 报
Error Code: 1248. Every derived table must have its own alias - 如果只是去重取首行，PostgreSQL 可用
DISTINCT ON (user_id) ORDER BY user_id, updated_at DESC，更简洁且无需嵌套
窗口函数依赖 JOIN 后的数据分布，而多对多关系天然破坏分布一致性
当你对多对多关联后的结果使用 PARTITION BY，比如 SUM(price) OVER (PARTITION BY user_id)，这个 user_id 的分区范围取决于 JOIN 输出的行——而这些行已经因中间表膨胀变得不可控。同一 user_id 下的 price 可能来自不同角色上下文，甚至来自错误的笛卡尔组合（如用户 A 关联角色 1 和角色 2，但 price 却被错误地交叉分配到两个角色行上）。
这比单纯行数翻倍更危险：数值没放大，但语义已错乱。
- 根本解法是避免让多对多表直接参与窗口计算层；先用子查询按
user_id预聚合price，再把结果作为单值字段带入主查询 - 如果业务强依赖明细（比如要展示“每个用户每条角色对应的最高订单额”），那就必须用
LATERAL子查询或相关子查询，确保每条主表行只关联其真实对应的明细集合 - 窗口函数的
PARTITION BY字段必须是确定、唯一、无歧义的键——多对多场景下，仅靠user_id往往不够，常需联合中间表主键（如(user_id, role_id)）才能准确定义分区边界
