SQL窗口函数计算员工入职累计加班时长

面试时被问到"累计加班时长"，十有八九的回答就是简简单单一个 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 来区分，避免把补班记录混入常规累计

累计类计算，源头数据一旦失真，下游的所有报表都会跑偏。这种错误比单纯的聚合错误更难追溯——等发现的时候，数据已经污染了若干层。所以，务必在窗口函数跑起来之前，先把时间域的数据质量校验做好。