补签逻辑不能用 group by 解决，因为需逐行比对原始打卡时间与补签申请时间、判断是否在窗口期内并保留明细记录，而 group by 会折叠行导致无法进行时间偏移判断。
补签逻辑为什么不能用 GROUP BY 解决
因为补签要对比「原始打卡时间」和「补签申请时间」，还要判断是否在允许补签窗口期内，同时得保留每个人每次打卡的原始记录——GROUP BY 会折叠行，丢失明细，没法做逐行时间偏移判断。
典型场景：员工在 2024-05-10 打卡失败，5 月 15 日提交补签申请，规则是“仅允许补签 3 天内的缺卡”。这时需要对每条打卡记录（含空打卡）打上标记，说明它是否被某次补签覆盖。
- 必须按
employee_id和日期分区，避免跨人干扰 - 要用
ROW_NUMBER()或RANK()对补签申请按时间排序，确保优先匹配最近的申请 - 不能只依赖
LEAD()/LAG()，它们只能看相邻行，而补签可能跳过中间多天
用 ROW_NUMBER() + 自关联模拟“最近可用补签”
核心思路：把打卡表和补签申请表分别用窗口函数编号，再通过日期范围 + 排序号做左连接，取每个打卡日“时间最接近且未超期”的那条补签。
关键写法：ROW_NUMBER() OVER (PARTITION BY employee_id ORDER BY apply_date) 给每人的补签申请编号；再用 LEFT JOIN 关联时加条件 t1.clock_date BETWEEN t2.apply_date - INTERVAL '2 DAY' AND t2.apply_date（假设允许补签 3 天内）。
- 补签申请表必须提前过滤掉已失效的（比如
status = 'approved'），否则会污染结果 - 如果同一人同一天有多次补签申请，
ROW_NUMBER()的ORDER BY apply_date DESC能优先选最新提交的 - 注意数据库对
INTERVAL的语法差异：PostgreSQL 用INTERVAL '2 DAY'，MySQL 用DATE_SUB(t2.apply_date, INTERVAL 2 DAY)
用 FIRST_VALUE() 标记“该日是否已被补签”
当一条打卡记录匹配到补签后，常需标记整日状态（例如“已补签”“部分补签”“未补签”）。这时别用子查询，直接在窗口里聚合判断更稳。
示例：在按 employee_id 和 clock_date 分组的窗口中，用 FIRST_VALUE(case when matched then 1 else 0 end) OVER (PARTITION BY employee_id, clock_date ORDER BY match_priority) 取最高优先级匹配结果。
-
FIRST_VALUE()比MAX()更可控——它不合并值，只取排序后第一个，避免误判“多个补签都匹配成功” - 务必加
ORDER BY子句，否则结果不确定；推荐按补签申请时间倒序，确保最新申请优先生效 - 如果补签表里没有对应记录，
FIRST_VALUE()返回NULL，记得用COALESCE(..., 0)转成明确标识
性能陷阱：窗口函数 + JOIN 容易爆内存
当补签申请量大（比如每月万人级）、打卡记录多（每天每人多条），JOIN 条件里的日期范围会触发笛卡尔积。一个员工 30 天打卡 × 10 次补签申请 = 300 行组合，百万员工就上亿了。
- 必须给补签表建联合索引：
(employee_id, apply_date, status)，且status列要高区分度（比如只查'approved'） - 打卡表加
(employee_id, clock_date)索引，让窗口分区更快 - PostgreSQL 可用
LATERAL JOIN替代普通JOIN，MySQL 8.0+ 可用ROW_NUMBER()配合WHERE提前截断——先对补签表按人、按时间倒序取 top 3，再关联
补签逻辑真正难的不是写法，而是边界：比如跨月补签、节假日顺延、审批流中途驳回——这些都得在窗口计算前清洗好数据，否则窗口函数只会忠实地放大错误。
