结论：group by 用于减少行数的分组汇总，over() 用于保留明细行并附加计算值；二者适用场景不同，不可互换。
直接说结论：在 Oracle 19c 中，分析函数（如 SUM() OVER()、COUNT() OVER()）不能替代 GROUP BY 做「减少行数」的分组汇总，但能解决它做不到的事——比如保留明细行的同时加小计、跨行累计、动态窗口统计。真要优化分组汇总，得先分清场景：是做报表小计/总计？还是想避免多次扫描？或是需要动态滚动计算？
什么时候该用 OVER() 而不是 GROUP BY
核心区别就一条：GROUP BY 把 100 行压成 10 行，OVER() 保持 100 行不变，但每行都带一个计算值。
- 需要展示原始明细（如每个员工记录），同时显示「所在部门平均工资」「部门累计薪资」「部门内薪资排名」——必须用
OVER() - 要做「按部门排序后，取前 3 名」或「薪资超过本部门平均值的员工」——
GROUP BY无法在 WHERE 或 HAVING 里引用聚合结果，而OVER()可以直接在 WHERE 外层过滤 - 想算移动平均（如最近 5 条记录的平均薪资）或滑动小计（按入职时间顺序累加）——只能靠
ROWS BETWEEN窗口定义，GROUP BY完全不支持
SUM() OVER() 和 GROUP BY 的性能差异在哪
表面看，SUM(salary) OVER(PARTITION BY department_id) 和 SELECT department_id, SUM(salary) FROM employees GROUP BY department_id 都算部门总和，但执行路径不同：
-
GROUP BY：Oracle 通常走 HASH GROUP BY，需哈希建表、去重、聚合，最后只返回 11 行（假设 11 个部门） -
SUM() OVER()：走 WINDOW SORT，对全表排序（或利用索引避免排序），再逐行累加；结果集仍是 107 行，每行多一列「部门总工资」 - 如果只想要部门总和，用
GROUP BY更快、内存更省；如果既要明细又要总和，OVER()只扫一次表，比GROUP BY+JOIN回原表快得多
ROLLUP / CUBE 与 OVER() 的分工边界
多维汇总（如部门+职位的小计、部门小计、总计）优先用 GROUP BY ROLLUP(department_id, job_id)，而不是硬套 OVER()：
-
ROLLUP是真正意义上的分层聚合，Oracle 会生成department_id, job_id、department_id、()三级结果，且自动标记GROUPING()值，语义清晰 -
OVER()没法天然表达「空维度」，强行模拟（如SUM() OVER()全局、SUM() OVER(PARTITION BY department_id)部门级）会导致重复计算、逻辑绕、难维护 - 例外情况：需要在明细行上同时显示「部门小计」和「公司总计」两列，这时可组合使用：
SUM(salary) OVER(PARTITION BY department_id)+SUM(salary) OVER()
容易被忽略的坑：NULL 值和排序依赖
OVER() 不像 GROUP BY 那样自动忽略 NULL 分组键，也不保证默认排序：
-
PARTITION BY department_id会把所有department_id IS NULL的行归为一组——如果你没意识到这点，小计结果可能包含一堆“未知部门”的脏数据 -
ORDER BY在OVER()里不是可选装饰：没有它，ROWS BETWEEN、RANGE、累计求和（SUM() OVER(ORDER BY ...)）都会出错或行为异常；即使只是分组，也建议显式写ORDER BY 1避免隐式排序抖动 -
COUNT(*) OVER(PARTITION BY x)统计的是每组行数，但COUNT(col) OVER(...)仍会跳过该列的 NULL 值——和聚合函数一致，这点常被误认为 bug
真正卡住人的从来不是语法，而是搞不清「我要压缩行」还是「我要扩增信息」。分组汇总优化的第一步，永远是画出目标结果集：几行？每行含哪些字段？哪些是原始数据？哪些是计算值？从这里出发，GROUP BY、OVER()、ROLLUP 才不会混用错位。
