用LAG()和LEAD()识别打卡重叠：先按employee_id、work_date、clock_time排序，再用LAG()获取上一次打卡时间，通过间隔判断是否为无效插入，精准匹配有效进出对
怎么用 LAG() 和 LEAD() 识别打卡时间重叠
处理考勤数据，我们面对的往往是按时间顺序排列的原始打卡流水。但问题来了：一个员工一天内可能多次打卡，比如上午迟到补卡、午休前后反复打卡、或者加班时再次记录。如果简单地用 MIN() 和 MAX() 取最早和最晚时间作为上下班，就会把中间那些无效的、重叠的时间段也囊括进去，直接导致计算出的工时“虚胖”。
所以，核心思路不是找“最早和最晚”，而是精准定位“有效的进出对”。这时候，LAG() 和 LEAD() 这两个窗口函数就派上用场了——它们能让你清晰地看到当前打卡记录与它前一条、后一条记录的时间关系，从而像侦探一样，标记出哪些打卡是多余的“无效插入”。
具体操作时，可以遵循这几个步骤：
- 首先，务必按
employee_id、work_date、clock_time排序，这是保证时间线正确的基石。 - 接着，使用
LAG(clock_time) OVER (PARTITION BY employee_id, work_date ORDER BY clock_time)来获取上一次打卡的时间。 - 然后，通过计算当前打卡与上一次打卡的时间间隔，来判断是否属于重复。比如，间隔过短（例如小于1分钟）就可能被标记为重复。
- 这里有个关键点：不能只看绝对时间差。必须结合打卡类型（
IN或OUT）一起判断。连续两个IN显然可疑，而一个IN后面紧跟着一个OUT，那很可能就是一个正常的进出对。
用 ROW_NUMBER() 配合状态机分组有效进出对
剔除掉明显的重复打卡，事情就结束了吗？远没有。剩下的记录，我们需要把它们按照“进→出→进→出…”的逻辑顺序正确地配对起来。手动写复杂的 CASE WHEN 语句来覆盖所有异常情况（比如漏打卡、多打卡、时间倒置）不仅费力，而且容易出错。
一个更稳健的策略，是利用 ROW_NUMBER() 构造一个伪状态序列，然后通过奇偶性进行智能分组。
可以这样操作：
- 首先，对清洗后的打卡记录（已经去除了明显重复项），按员工、日期、时间排序，并使用
ROW_NUMBER() OVER (PARTITION BY employee_id, work_date ORDER BY clock_time)给每一条记录一个全局编号。 - 然后，再单独为“上班”（
IN）和“下班”（OUT）这两种类型各自编号，即ROW_NUMBER() OVER (PARTITION BY employee_id, work_date, clock_type ORDER BY clock_time)。 - 接下来，一个巧妙的技巧来了：用全局编号减去按类型编号，得到一个“组号”：
grp = rn_total - rn_by_type。这个操作的神奇之处在于，同一组号下的IN和OUT记录，在逻辑上就是配对的。 - 最后，通过
GROUP BY employee_id, work_date, grp进行分组，取每组内的MIN(clock_time)作为上班时间，MAX(clock_time)作为下班时间，一个清晰的工时区间就出来了。
用 OVERLAPS 或自连接检测并合并时间区间（PostgreSQL / SQL Server）
即使成功配对了进出，另一个常见问题又浮出水面：多个工时区间之间可能存在重叠，或者间隔极短（比如09:00–12:00，12:05–18:00，中间只隔了5分钟）。根据很多公司的考勤规则，这种紧邻的区间应该合并为一段（09:00–18:00）。
标准SQL中的 OVERLAPS 运算符可以直接判断两个时间区间是否重叠，但它本身不支持聚合合并操作。因此，在大多数实际场景中，我们还需要一些手动处理。
具体可以这么做：
- 在PostgreSQL中，你可以用
(start1, end1) OVERLAPS (start2, end2)作为条件来筛选出重叠的区间，但真正的合并工作，通常还需要借助递归CTE或窗口函数进行累计计算。 - 更通用的方法是：针对每个员工每天的各个进出段，使用自连接（Self-Join）来寻找“可以被前一段覆盖或紧密相邻的后一段”。然后，利用
MAX(end_time) OVER (ORDER BY start_time ROWS UNBOUNDED PRECEDING)这样的窗口函数，动态地累计扩展右边界，从而实现区间的合并。 - 这里有个关键陷阱需要注意：窗口函数中的
ORDER BY必须使用start_time，并且窗口定义最好用ROWS而不是RANGE。因为时间是连续值，使用RANGE很容易产生意想不到的合并结果。 - 另外，MySQL 8.0及以上版本不支持
OVERLAPS运算符，这时就需要用条件判断start2 <= end1来模拟宽松的重叠检测。
为什么不能跳过排序和分区，直接套用窗口函数
窗口函数非常强大，但它的计算完全依赖于你定义的窗口。如果使用不当，结果会南辕北辙。记住，窗口函数本身不改变结果集的行数，它只是在当前窗口的视角下进行计算。
如果 PARTITION BY 子句漏掉了 work_date，那么跨天的打卡记录（比如夜班从22:00到次日06:00）就会被错误地和第二天的早班记录混在一起计算。如果 ORDER BY 缺失或排序规则不明确，LAG() 函数返回的“上一行”可能就是随机的，基于此做的所有重叠判断都将失效。
因此，务必牢记：
PARTITION BY至少应包含employee_id和一个日期维度（可以是CAST(clock_time AS DATE)，也可以是业务表中独立的work_date字段）。ORDER BY必须是确定性的排序：时间字段是主力，必要时可以加上clock_type（例如规定IN优先于OUT）或者表自增ID，以防止时间完全相同导致的排序歧义。- 一个有效的测试方法是：故意构造一条跨天记录和一条同一天的重复打卡记录，然后检查你的
LAG()函数是否准确地返回了你期望的“上一条”记录。这是验证窗口定义是否正确的最直观手段。
说到底，技术实现从来不是最复杂的部分。真正的挑战往往在于业务细节：时间精度到底取到毫秒还是秒？多少分钟内的间隔算作重叠需要合并？午休时间是否要强制扣除？弹性打卡的边界如何界定？以及，数据质量本身——有没有缺失打卡类型、时间戳乱序、或者设备时区设置错误？这些因素，才是决定你整个窗口函数逻辑设计起点和成败的关键，而不是写完函数之后才考虑的终点。
