LEAD函数本身不判断“是否为上班卡”，仅将下条记录字段并排到当前行，真正判断需配合CASE WHEN；必须按员工、日期、时间排序并PARTITION BY emp_id和日期，再结合时间差等逻辑识别打卡状态。
LEAD函数怎么用在考勤打卡序列里判断“是否为上班卡”
直接说结论：LEAD 本身不判断状态，它只是把下一条记录的字段“拉上来”和当前行并排——真正做判断的是你跟它配合的 CASE WHEN 表达式。关键不是函数多高级，而是你得先按人、按天、按时间排序好，否则 LEAD 拉出来的就是错的。
常见错误现象：同一人同一天的打卡被跨天分组、或时间没排序导致 LEAD(time) 拉出昨天的下班时间；还有人忘了加 PARTITION BY emp_id, CAST(check_time AS DATE)，结果张三的下班卡被拿来当李四的上班卡比。
实操建议：
- 必须用
ORDER BY check_time（不是id或插入顺序） -
PARTITION BY emp_id, CAST(check_time AS DATE)是底线，SQL Server 可用CONVERT(DATE, check_time)，MySQL 用DATE(check_time) - 别直接
LEAD(check_time)就完事，要配合时间差判断：比如LEAD(check_time) - check_time < INTERVAL '30' MINUTE才可能是一对打卡
如何用LEAD识别“异常打卡对”：迟到、早退、缺卡
迟到不是看单次打卡时间，而是看“上一次打卡是不是前一天的下班卡”。这时候 LEAD 和 LAG 要搭配用：用 LAG 拿前一条，LEAD 拿后一条，再结合工作时间段（比如 9:00–18:00）做逻辑分支。
典型场景：某员工当天只有 1 条打卡记录（LEAD 和 LAG 都为 NULL），那就是缺卡；有两条但间隔超 10 小时，可能是漏打中间卡；有三条以上，就得看每对相邻卡之间是否符合“上班→下班→上班…”的节奏。
实操建议：
- 定义标准班次后，用
CASE WHEN把每条记录标记为'in'/'out'/'unknown'，而不是依赖打卡顺序绝对化 - 避免硬写
WHERE LEAD(check_time) IS NOT NULL来筛“有配对的记录”，这会漏掉单卡异常，应先全量标记再聚合 - MySQL 8.0+、PostgreSQL、SQL Server 2012+ 支持
LEAD，但 SQLite 不支持，别在本地测试用 SQLite 然后上线报错
为什么不能只靠LEAD算工时？必须补上“有效打卡对”过滤逻辑
LEAD 给你的是“下一条时间”，不是“下一次有效打卡”。现实中员工可能上午打两次卡（手抖）、中午刷门禁、下班又打一次——这些都会进原始表，但只有最接近班次起止点的那两个才算数。
性能影响很明显：如果不对原始打卡数据先做清洗（比如去重、剔除测试卡、排除非考勤设备记录），LEAD 会在一堆无效数据上反复计算，不仅结果错，还拖慢查询。线上库跑一次全量工时统计，从 2 秒变成 47 秒，往往就因为少了一步 WHERE device_type = 'attendance'。
实操建议：
- 在
LEAD外层套一层子查询或 CTE，先用ROW_NUMBER() OVER (PARTITION BY emp_id, DATE(check_time) ORDER BY check_time)给每条卡编号，再取rn IN (1, 2)做初筛 - 别在
LEAD的ORDER BY里加多个字段（如ORDER BY check_time, id），除非你确认id能解决时间重复问题；否则可能让本该相邻的两条卡被拆开 - 工时 =
LEAD(check_time) - check_time之前，务必CAST或EXTRACT成分钟/秒单位，不同数据库对时间相减返回类型不一致（PostgreSQL 返回 interval，MySQL 返回秒数）
LEAD结果为空（NULL）时怎么安全参与计算
LEAD 在最后一条记录上必然返回 NULL，这是设计使然，不是 bug。但很多人写 LEAD(check_time) - check_time 时没判空，整列工时全变 NULL，排查半天才发现是最后一条卡没配对。
最容易被忽略的地方：不是所有 NULL 都该补默认值。比如下班卡缺失，补个“18:00”看似合理，但如果员工当天加班到 22:00，这个补值反而掩盖真实异常。更稳妥的做法是保留 NULL，并在后续用 COUNT(*) FILTER (WHERE work_hours IS NULL)（PostgreSQL）或 SUM(CASE WHEN work_hours IS NULL THEN 1 ELSE 0 END) 单独统计缺卡人数。
实操建议：
- 用
COALESCE(LEAD(check_time), check_time + INTERVAL '8' HOUR)这类兜底逻辑前，先确认业务是否允许估算 - Oracle 用户注意：
LEAD第三个参数可设默认值（LEAD(col, 1, '9999-12-31')...），但 PostgreSQL 和 SQL Server 不支持，得用COALESCE - 如果下游是报表工具（如 Tableau、Superset），NULL 工时可能触发错误聚合，建议在 SQL 层就用
CASE WHEN LEAD(check_time) IS NULL THEN 'MISSING_OUT' ELSE 'VALID'标记状态，别留空
