为什么GROUP BY不行，而窗口函数可以？
很多朋友一开始会想，既然要分组求和，那直接用GROUP BY不就好了？但仔细一想就发现不对。GROUP BY会把数据“压缩”成每组一行，只给你一个最终的总和。而我们想要的是“分组内的累计和”——它需要保留原始数据中的每一行，并按照入职时间这样的顺序，一行一行地把数值累加起来。这完全是两码事。
所以，正确的路径是使用窗口函数。它最大的好处就是不改变查询结果的行数，允许你在分组内部再定义一套排序和累积的逻辑，完美契合“运行总计”的需求。
为什么 SUM() 加 GROUP BY 不能直接得到分组内累计和
举个例子，如果你直接写 SELECT dept, SUM(salary) FROM emp GROUP BY dept，得到的结果只是每个部门薪资的总和，而不是我们想要的“按入职时间顺序逐行累加”的运行总计。
这里有个常见的“坑”：很多人会把窗口函数里的ORDER BY漏掉，或者放错位置。记住，这个ORDER BY必须出现在OVER()子句的内部，而且它的顺序必须和你想累计的方向一致。如果漏了，在有些数据库里，结果会直接退化成整组的总和（相当于没起作用）；在另一些数据库（比如MySQL 8.0之前的版本）里，甚至可能会直接报错。
SUM() OVER(PARTITION BY ... ORDER BY ...) 的写法要点
标准的写法结构是固定的：SUM(salary) OVER(PARTITION BY dept ORDER BY hire_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)。我们来拆解一下：
PARTITION BY dept：这是划定“战场”的，它告诉数据库，按部门分区，每个部门独立计算自己的累计值，互不干扰。ORDER BY hire_date：这是决定“顺序”的，累计必须有个方向，这里我们按入职时间先后累加。切记，尽量使用业务上确定性的排序字段，避免用id这类可能重复或者无明确业务意义的列。ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW：这是定义“窗口框架”的，意思是“从分区的第一行累加到当前行”。这个子句其实是默认值，可以省略，但显式写出来会让代码意图更清晰。只有当你需要计算滑动窗口（比如包含当前行之后若干行）时，才需要去调整它。
不同数据库对 ORDER BY 的强制要求差异
这一点需要特别注意，不同数据库的“脾气”不一样。像PostgreSQL和SQL Server就比较严格，它们要求窗口函数里只要有聚合，就必须配上ORDER BY，否则直接报错。而MySQL 8.0+和Oracle相对宽松，允许你省略，但结果会退化成组内无序的累计，这个值是不可预测的，基本没用。
所以，最稳妥的实践就是：一律显式写上ORDER BY，这样代码跨数据库迁移时问题最少。
另一个容易踩坑的地方是排序字段的类型。如果你用hire_date这种日期类型，通常没问题。但如果你用salary作为排序依据，当有多条记录的薪资相同时，它们的累计顺序就可能不稳定（在使用ROW_NUMBER()或需要精确对齐的场景下尤其麻烦）。解决办法是追加一个二级排序字段，确保唯一性，比如ORDER BY salary, emp_id。
累计和与累计占比的联动写法
实际业务中，我们经常不仅要累计和，还想知道“当前累计额占本组总和的比例”。这时候，你不能直接嵌套窗口函数（比如SUM(SUM() OVER(...)) OVER(...)这种写法是非法的），而需要借助子查询或者CTE（公共表表达式）来分步计算。
WITH grouped AS (
SELECT dept, salary, hire_date,
SUM(salary) OVER(PARTITION BY dept ORDER BY hire_date) AS running_sum,
SUM(salary) OVER(PARTITION BY dept) AS total_dept
FROM emp
)
SELECT dept, salary, hire_date,
running_sum,
ROUND(running_sum * 100.0 / total_dept, 2) AS pct
FROM grouped;
注意看，计算total_dept（部门总薪资）的窗口定义里，是没有ORDER BY的，所以它返回的是每一行所在部门的固定总和。而running_sum是动态变化的累计值。把这两个值组合起来，才能安全地算出比例。
最后提一个真正麻烦的情况：当分组键本身存在NULL值时。PARTITION BY dept会把所有dept IS NULL的行都归到同一组里。但在大多数业务场景下，我们可能希望把这些空值记录排除掉，或者单独处理。正确的做法是在窗口函数计算之前，就用WHERE dept IS NOT NULL提前过滤掉，不要指望窗口函数自己来处理这个边界问题。
