如何在SQL中使用窗口函数计算员工入职以来的累计加班时长

正确做法是用 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 的窗口函数默认使用该范围，但 MySQL 8.0 在某些版本中会退化为 RANGE 模式，导致同时间戳的多条记录被合并累加——明明有两条 2 小时加班，却只算出 2 小时。

强制指定行模式能确保逐行累加：

• 写全：SUM(overtime_hours) OVER (PARTITION BY employee_id ORDER BY work_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)
• PostgreSQL 可省略 ROWS...，但加上更安全、跨库可读性更好
• 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）区分，避免把补班计入常规累计

累计类计算一旦源头数据失真，下游所有报表都会偏移，比聚合错误更难追溯。务必在窗口函数之前完成时间域校验。