正确做法是用 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）区分，避免把补班计入常规累计
累计类计算一旦源头数据失真，下游所有报表都会偏移，比聚合错误更难追溯。务必在窗口函数之前完成时间域校验。
