应根据是否保留原始行粒度选择：需压缩行数出报表用 GROUP BY，需每行带统计值用窗口函数；GROUP BY 结果行数≤原始行数，窗口函数行数=原始行数。
该选 GROUP BY 还是窗口函数，取决于你是否需要保留原始行粒度。需要压缩行数、出汇总报表，就用 GROUP BY；需要每行都带统计值（比如“本部门平均薪资”“累计订单金额”“当前用户排名”），就用窗口函数。
输出行数决定函数类型
这是最直观的判断依据：看你要的结果是不是还保留每一笔明细。
-
GROUP BY后结果行数 ≤ 原始行数，例如 100 行订单按用户分组后只剩 20 行——原始订单记录彻底丢失 - 窗口函数输出行数 = 原始行数，100 行订单仍返回 100 行，只是每行多了一列
SUM(amount) OVER (PARTITION BY user_id) - 错误典型：
SELECT user_id, amount, SUM(amount) OVER (PARTITION BY user_id)能跑通；但SELECT user_id, amount, SUM(amount)不加GROUP BY user_id就会报错（MySQL 5.7 或严格模式下）
聚合字段混用时容易踩坑
当 SELECT 中同时出现非分组字段和聚合函数，又没用窗口函数包裹，SQL 引擎会直接拒绝执行。
- 错误写法：
SELECT dept, name, AVG(salary)——name未被分组，也没被聚合，MySQL 8.0 严格模式下报错ERROR 1055 - 正确解法一（用
GROUP BY）：SELECT dept, ANY_VALUE(name), AVG(salary) FROM emp GROUP BY dept - 正确解法二（用窗口函数）：
SELECT dept, name, AVG(salary) OVER (PARTITION BY dept) FROM emp——name保持原样，不需ANY_VALUE() - 注意：
ANY_VALUE()是 MySQL 特有，PostgreSQL 和 SQL Server 必须显式分组或改用窗口函数
多个统计维度并存时窗口函数更自然
当你需要同一行数据上叠加不同逻辑的统计值（比如“个人销售额 + 部门平均 + 全公司占比 + 同岗位排名”），硬套 GROUP BY 会导致嵌套子查询爆炸。
- 窗口函数可并行定义：
AVG(salary) OVER (PARTITION BY dept)、RANK() OVER (PARTITION BY role ORDER BY salary DESC)、SUM(salary) OVER () / SUM(salary) OVER (PARTITION BY dept)全部写在同一层SELECT - 而用
GROUP BY实现等效效果，得先GROUP BY dept算部门均值，再GROUP BY role算岗位排名，最后 JOIN 回原始表——语义割裂、性能差、易出错 - MySQL 8.0+ 对共用
PARTITION BY和ORDER BY的多个窗口函数有合并优化；但若分区键不同（如一个按dept，一个按region），引擎仍可能扫描多次基础数据
性能敏感场景要留意执行计划
窗口函数不是银弹，尤其在大数据量下，ORDER BY 和 PARTITION BY 的组合可能引发隐式排序开销。
-
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW这类累积计算，如果ORDER BY字段无索引，会强制触发排序节点（WindowAgg或Sort） -
PARTITION BY键选择不当（如高基数列 + NULL 值多）会导致分区倾斜，某些分区极大，拖慢整体执行 - 用
EXPLAIN ANALYZE检查是否出现多个Sort或WindowAgg节点——多个不同OVER子句很可能被分别执行 - 全局统计（如
SUM(x) OVER ()）比子查询(SELECT SUM(x) FROM t)更高效，且避免关联；但若只用一次，CTE 预计算未必更优，反而增加中间结果集大小
真正难的不是语法，而是想清楚你要的是“一份报表”，还是“一份带背景信息的明细”。前者交给 GROUP BY，后者交给窗口函数——别让 PARTITION BY 写得像 GROUP BY，也别把 GROUP BY 当成窗口函数的替代品。NULL 处理、执行顺序、分区倾斜，这些细节往往在上线后才暴露。
