lag函数需按employee_id分区、check_in_time排序，否则结果错乱；时间字段须为timestamp类型；工时计算应为当前时间减lag值；需过滤null及无效打卡间隔。
LAG函数怎么取上一条打卡记录的时间
直接用 LAG() 拿上一行的打卡时间，但必须确保数据按员工 ID 和打卡时间严格排序，否则结果完全错乱。常见错误是没写 ORDER BY 或只按时间排、漏了员工分组，导致张三的下班时间被李四的上班时间“借用”。
实操建议：
- 必须在窗口函数中显式指定分区和排序：
LAG(check_in_time) OVER (PARTITION BY employee_id ORDER BY check_in_time) - 如果原始表里只有单字段
check_time，且无法区分上下班（比如没有 type 字段），先用业务规则补全——例如按时间奇偶顺序临时标记为“进/出”，否则LAG()算出来的差值毫无业务意义 - 注意 NULL：首条记录的
LAG()必然返回 NULL，做减法前要加WHERE prev_time IS NOT NULL过滤
计算工时差值时为什么总得到负数或 0
本质是时间相减方向反了：用当前打卡时间减上一次打卡时间，才是本次持续时长；反过来就变负数。更隐蔽的问题是字段类型——若 check_in_time 是 STRING（如 '2024-05-20 09:02'），直接相减会报错或转成 0。
实操建议：
- 确认时间字段是
TIMESTAMP或DATETIME类型；不是的话，先用CAST(check_in_time AS TIMESTAMP)转换 - 差值计算写成：
check_in_time - LAG(check_in_time) OVER (...)，不是反过来 - 数据库对时间差返回单位不一：PostgreSQL 返回 interval，MySQL 返回秒数，BigQuery 返回微秒——后续做小时换算时得对应除以 3600、1、3600000000
如何排除无效打卡对工时的影响
真实场景中，员工可能一天打 5 次卡：早到、迟到、午休前、午休后、加班。直接用相邻两条算工时，会把“早到→迟到”这种无效段也计入，导致工时虚高。
实操建议：
- 先按业务逻辑定义有效打卡对：通常是“进→出→进→出”交替，可用
ROW_NUMBER() % 2 = 1标记奇数行为“进”，偶数行为“出” - 或者依赖已有状态字段：如果有
check_type（值为 'IN'/'OUT'），则用LAG()只取上一个'IN'时间，配合当前'OUT'行过滤 - 加时间间隔阈值过滤：比如两打卡间隔超过 12 小时，大概率不是同一工作日，用
WHERE time_diff （PostgreSQL）或等效表达式剔除
MySQL 8.0 以下版本没法用 LAG 怎么办
LAG 是窗口函数，MySQL 5.7 及更早版本不支持，强行升级成本高。替代方案不是写存储过程，而是用自连接模拟——但性能差、易出错，尤其数据量大时。
实操建议：
- 用变量法（仅限 MySQL）：
@prev_time := IF(@emp = employee_id, @prev_time, NULL)配合@emp := employee_id实现伪 LAG，但必须确保 ORDER BY 在变量赋值前生效，且不能用于子查询 - 更稳的方式是导出数据到支持窗口函数的环境（如临时用 SQLite 3.25+、DuckDB 或 Python pandas）处理，再回写——比硬啃变量逻辑省调试时间
- 如果只是临时查，且数据量小，用关联子查询：
(SELECT MAX(check_in_time) FROM t t2 WHERE t2.employee_id = t1.employee_id AND t2.check_in_time ，但 O(n²) 复杂度，万级数据就明显卡顿
实际跑通的关键不在函数本身，而在你是否清楚每条打卡记录在业务流中的确切角色——LAG() 只是工具，它不会帮你分辨哪次是真正开始工作。
