面试时被问到"累计加班时长"，十有八九的回答就是简简单单一个 SUM() OVER()。但真正落地计算"入职以来"的累计值，细节比想象中多不少。今天就来拆解几个容易翻车的细节，看看你真的写对了吗。
先看一个正确示例。用窗口函数计算累计加班，核心语句是：
SUM(overtime_hours) OVER (
PARTITION BY employee_id
ORDER BY work_date
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
)
关键在于，work_date 必须非空、严格有序，并且符合业务逻辑。必要的时候还得关联一下入职日期，把那些入职前就产生的"幽灵加班"过滤掉。
用 SUM() OVER() 计算按时间顺序的累计加班时长
核心思路很直接：按员工分组，按加班发生的时间（比如打卡日期或时钟时间）升序排列，然后逐行累加。千万别只写 SUM(overtime_hours) 就完事了——缺了 ORDER BY，窗口默认取的是整个分区的所有行，结果每一行得出来的累计值都一样，那就彻底错了。
常见的坑是漏掉 ORDER BY，或者用错了排序字段。比如有人拿 employee_id 来排序，结果累计出来的逻辑是按员工ID的数值递增，根本不是按时间。正确做法一定是用实际发生加班的日期或时间字段，比如 work_date 或 clock_in_time。
OVER (PARTITION BY employee_id ORDER BY work_date)—— 这才是正解：按人分组，按日期递增累计- 如果同一天有多次加班记录，记得加次级排序，比如
ORDER BY work_date, id，避免窗口行为不确定 work_date如果为空，会被排在第一位，第一条累计值直接就被污染了。提前加个WHERE work_date IS NOT NULL非常有必要
处理入职时间早于首条加班记录的"零起点"问题
累计值理论上应该从员工入职日开始计算。但现实是，加班表里往往只有加班记录，没有入职日期。如果直接硬算，第一条记录的累计值就是它自己的加班时长，完全不是"入职至今"的累计值。
怎么解决？看数据结构：
- 如果员工主表里有
hire_date，而且能通过employee_id关联加班表，那就先LEFT JOIN把入职时间补全，然后再用CASE WHEN work_date >= hire_date THEN overtime_hours ELSE 0 END把入职前的记录清掉。 - 如果连不上入职表，那就只能假设首条加班记录就是入职后的第一次加班。这种情况下累计逻辑本身没问题，但业务口径一定要说清楚，别让下游的人误解。
- 千万不能用
MIN(work_date) OVER (PARTITION BY employee_id)来替代hire_date——有些员工入职半年才第一次打卡加班，这么干会严重低估累计时长。
MySQL 8.0+ 和 PostgreSQL 中 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW 的必要性
这个框架看着挺长，还带点冗余味道，但实际写的时候还真不能偷懒。不显式声明窗口范围时，不同数据库的行为差异挺大的。PostgreSQL 对带 ORDER BY 的窗口函数默认用的是 RANGE 模式？不对，实际上 PostgreSQL 默认是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，但 MySQL 8.0 在某些版本里也类似。关键区别在于 RANGE 和 ROWS 对"同值行"的处理逻辑完全不同——RANGE 会把相同 ORDER BY 值的所有行合并计算，结果两条2小时的加班加在一起，却只出来一个2小时，明明应该累计成4小时。
强制指定 ROWS 模式就是为了确保逐行累加，不被合并：
- 写全：
SUM(overtime_hours) OVER (PARTITION BY employee_id ORDER BY work_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) - PostgreSQL 虽然可以省略，但加上更安全，跨数据库移植时可读性也好很多
- SQL Server 同样推荐显式声明，避免跟
RANGE语义混淆
当加班记录含未来日期或乱序数据时的应对策略
业务系统里什么都可能发生。测试数据没删干净、补录操作出现、时区配置错误——这些都会让 work_date 冒出未来时间或者明显倒流的数据，比如2025-01-01后面突然蹦出一个2024-06-01。这种脏数据一进来，累计曲线直接跳变，严重的时候还会出现负向回滚，报表没法看。
别指望应用层去清洗。SQL层面就要前置拦截：
- 加个时间合理性判断：
WHERE work_date >= DATE_SUB(CURRENT_DATE, INTERVAL 5 YEAR) - 对每个员工用
LAG(work_date) OVER (PARTITION BY employee_id ORDER BY work_date)检查前后顺序，标记出倒序行并排除掉 - 如果业务上允许"补班"操作，那还得加个字段比如
is_makeup BOOLEAN来区分，避免把补班记录混入常规累计
累计类计算，源头数据一旦失真，下游的所有报表都会跑偏。这种错误比单纯的聚合错误更难追溯——等发现的时候，数据已经污染了若干层。所以，务必在窗口函数跑起来之前，先把时间域的数据质量校验做好。
