SQL怎么计算员工入职以来的累计奖金_SUM OVER分区计算

SQL里用SUM() OVER()算累计奖金，核心是按入职时间排序

开门见山，先说一个关键结论：想用SUM() OVER()准确计算员工入职以来的累计奖金，必须配合ORDER BY hire_date（或者你的入职时间字段）以及ROWS UNBOUNDED PRECEDING子句。否则，这个窗口函数默认只会按逻辑顺序累加，而不是你想要的、严格遵循时间先后的累计。很多朋友明明写了OVER(PARTITION BY dept_id ORDER BY hire_date)，却看不到“累计”效果，问题往往就出在漏掉了窗口帧的定义，或者排序字段本身存在重复值，导致顺序不确定。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

• 如果hire_date存在重复（比如多人同一天入职），稳妥起见，建议补上ORDER BY hire_date, emp_id，用员工ID作为第二排序键，避免结果飘忽不定。
• 关于ROWS UNBOUNDED PRECEDING，这里有个重要提示：在多数主流数据库（如PostgreSQL、SQL Server、Oracle、Doris）中，当ORDER BY存在且未显式指定帧时，它们会自动采用RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW作为默认行为，基本能达到累计效果。但请注意，MySQL 8.0+是个例外，它必须显式写出这个帧，否则计算结果就只是当前行的值。
• 还有一个隐蔽的坑：千万别在WHERE子句里过滤掉早期员工之后，再套用OVER()。那样的话，累计值会从被过滤后的结果集第一条开始算，完全失去了“入职以来”的真实意义。

必须用ORDER BY hire_date配合ROWS UNBOUNDED PRECEDING，否则SUM() OVER()无法实现按时间顺序的累计；MySQL 8.0+必须显式指定该帧，而其他数据库可能默认启用。

分区（PARTITION BY）加不加，取决于你要“全公司累计”还是“部门内累计”

这里有个常见的理解误区：以为做“累计”就必须得用PARTITION BY。其实不然。是否添加分区，完全取决于你的计算范围。

• 不写PARTITION BY，那就是在全表范围内进行累计，从公司最早入职的员工一直累加到当前行。
• 加上PARTITION BY dept_id，计算就变成了在每个部门内部独立进行，各自从本部门第一个入职的员工开始累加。

所以，具体怎么选？

• 想看每个员工在自己部门的奖金排名和累计值？那就用OVER(PARTITION BY dept_id ORDER BY hire_date)。
• 想看从公司元老到当前员工的总奖金池变化？去掉PARTITION BY，只保留ORDER BY hire_date即可。
• 需要警惕的是：如果PARTITION BY的字段（如dept_id）存在NULL值，那么所有NULL行会被归到同一组进行聚合，这可能产生意料之外的结果。保险的做法是提前用COALESCE(dept_id, 'unknown')处理一下。

MySQL 8.0+和旧版MySQL处理方式完全不同

数据库版本差异，是另一个导致结果“翻车”的重灾区。MySQL 5.7及更早的版本根本不支持OVER()语法，写了就会直接报ERROR 1064。而升级到8.0+之后，事情也没那么简单——它对于窗口函数帧的默认行为和其他数据库不同。

具体来说，在MySQL 8.0+里，如果你不显式写出ROWS子句，它不会自动设为UNBOUNDED PRECEDING，而是等价于ROWS BETWEEN CURRENT ROW AND CURRENT ROW。结果就是，每行都只显示自己的奖金，所谓的累计查询毫无效果。

• 所以，在MySQL 8.0+里必须显式写明：SUM(bonus) OVER(ORDER BY hire_date ROWS UNBOUNDED PRECEDING)。
• 如何验证是否生效？一个简单的测试：查询结果中，入职早的那一行的sum_bonus应该等于它自己的bonus，而入职晚的那一行应该等于两者奖金之和。
• 另外，也别太依赖客户端工具的“智能格式化”，有些工具可能会把ROWS UNBOUNDED PRECEDING折叠或简化掉，让你误以为代码正确，实则不然。

奖金字段含NULL时，SUM() OVER()会自动跳过，但得确认业务是否允许

SUM()函数本身会忽略NULL值，这个特性也延续到了窗口函数中。这意味着，如果bonus字段有空值，那么该行不会参与累计计算，后续行的累计值里也不会包含它。

这在大多数情况下符合直觉，但务必和你的业务规则对齐。如果你们的规则是“未发放奖金视作0”，那么直接计算就会出错。

• 错误写法：SUM(bonus) OVER(...) → 遇到NULL直接跳过，累计值偏低。
• 正确对齐业务：SUM(COALESCE(bonus, 0)) OVER(...) → 先将NULL转为0，再进行累计。
• 这里推荐使用COALESCE，因为它是标准SQL函数，跨数据库兼容性最好，比IFNULL或ISNULL这类数据库特有函数更稳妥。

话说回来，实际开发中最容易被忽略的，其实就是两件事：一是排序字段是否具备唯一性以保证确定的顺序，二是不同数据库版本对窗口帧的默认行为差异。很可能同一个SQL脚本，在PostgreSQL里运行完美，一到MySQL 8.0上结果就全错了，根源往往就是少了那行ROWS UNBOUNDED PRECEDING。这才是关键所在。