使用TIMEDIFF()计算迟到和加班时，必须先用TIME()提取纯时间并确保时区一致，跨天场景需改用DATETIME运算，且应为TIME()结果创建STORED生成列索引以提升查询性能。
MySQL里用TIMEDIFF()计算迟到和加班必须注意时区与类型匹配
直接用TIMEDIFF()算打卡时间差看似简单，但实际常返回NULL或错误结果。根本原因是：它的两个参数必须都是TIME类型，而很多系统把打卡时间存成DATETIME或TIMESTAMP。如果硬传DATETIME进去，MySQL会尝试隐式转换，但一旦日期部分不一致（比如打卡跨天），结果就不可靠。
正确做法是先用TIME()提取纯时间部分，再比对：
SELECT TIMEDIFF(TIME('09:05:00'), TIME('09:00:00')) AS late_time; -- 返回 '00:05:00'- 考勤规则中“迟到”只看当日上班时间点，所以必须剥离日期，只比对
TIME - 若原始字段是
check_in DATETIME，务必写成TIME(check_in)，不能直接TIMEDIFF(check_in, '09:00:00') - 注意MySQL服务器时区设置——如果应用层用UTC写入，但数据库设为
SYSTEM（即本地时区），TIME()提取出的时间可能偏移
区分正常下班与加班：用CASE WHEN结合HOUR()和MINUTE()判断阈值更稳妥
单纯用TIMEDIFF()算出“18:30 - 18:00 = 00:30”不能直接认定为加班，因为公司可能规定18:30之后才算。这时候不能依赖字符串比较（如check_out > '18:30:00'），因为TIME类型支持直接大小比较，但逻辑要分层写清楚。
推荐结构化判断：
SELECT
check_in,
check_out,
CASE
WHEN TIME(check_in) > TIME('09:05:00') THEN TIMEDIFF(TIME(check_in), TIME('09:05:00'))
ELSE '00:00:00'
END AS late_duration,
CASE
WHEN TIME(check_out) > TIME('18:30:00') THEN TIMEDIFF(TIME(check_out), TIME('18:30:00'))
ELSE '00:00:00'
END AS overtime_duration
FROM attendance;-
HOUR()和MINUTE()可用于精细控制规则，比如“18:30后每满15分钟计0.25小时”，这时比直接TIMEDIFF再换算更可控 - 避免用
SEC_TO_TIME(TIME_TO_SEC(...))做中间转换——性能低且易在边界值（如23:59:59）出错 - 如果需要按“自然日”统计加班（如23:00打卡，实际加班从当日18:30起算6.5小时），就不能只取
TIME()，得用完整DATETIME并配合日期逻辑
跨天打卡（夜班/出差）必须用DATETIME运算，TIMEDIFF()会失效
夜班员工23:00打卡上班、次日07:00下班，若仍用TIME(check_out) - TIME(check_in)，得到的是TIMEDIFF('07:00:00', '23:00:00') = '-16:00:00'，完全错误。这是TIMEDIFF()最典型的误用场景。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
解决方法是回归DATETIME本体，用整数小时差再映射到时间格式：
SELECT
check_in,
check_out,
SEC_TO_TIME(
IF(check_out < check_in,
TIME_TO_SEC(TIMEDIFF(DATE_ADD(check_out, INTERVAL 1 DAY), check_in)),
TIME_TO_SEC(TIMEDIFF(check_out, check_in))
)
) AS actual_work_duration
FROM attendance
WHERE shift_type = 'night';- 核心逻辑：先判断
check_out ，成立则说明跨天，给<code>check_out加一天再减 - 不要用
ADDTIME()处理跨天，它不接受日期进位，DATE_ADD()才是正解 - 如果表中只有时间字段没日期，必须补业务规则字段（如
work_date DATE），否则无法可靠还原跨天事实
索引与性能：对TIME()字段直接建索引无效，得用生成列
当数据量上百万，还要按“是否迟到”（即TIME(check_in) > '09:05:00'）高频查询时，发现哪怕给check_in建了索引，执行计划仍显示全表扫描——因为TIME(check_in)是函数表达式，普通索引无法命中。
MySQL 5.7+ 正确解法是建函数索引（虚拟生成列）：
ALTER TABLE attendance ADD COLUMN check_in_time TIME GENERATED ALWAYS AS (TIME(check_in)) STORED, ADD INDEX idx_check_in_time (check_in_time);
- 必须用
STORED（非VIRTUAL），否则无法建索引 - 后续查询可直接写
WHERE check_in_time > '09:05:00'，走索引无压力 - 注意：生成列的值在INSERT/UPDATE时自动计算，不占用额外应用逻辑，但会略微增加写入开销
真正难的不是写出计算逻辑，而是想清楚“这个时间差到底属于哪一天、受不受排班周期影响、是否要排除休息日”。函数只是工具，业务规则才是边界。
