不能直接用 DATEDIFF 判断逾期，因其计算自然日差而非工作日；业务逾期需剔除周末和节假日，须通过自定义函数 workday_diff 封装逻辑，基于可配置的 holiday_calendar 表统计 is_workday=1 的天数，并注意索引优化、时区统一与回归测试。
为什么不能直接用 DATEDIFF 判断逾期？
因为 DATEDIFF 算的是自然日差，而业务逾期通常按「工作日」算——比如合同约定“5个工作日内付款”，遇到国庆7天假，实际宽限期就得顺延。MySQL原生不提供工作日计算函数，硬套 DATE_ADD 或循环加1天极易出错：漏掉节假日、把周末当工作日、跨年时节日表没覆盖……最常见现象是测试环境看着对，上线后财务对账发现逾期天数少算2天。
怎么用自定义函数封装工作日差逻辑？
核心是把「日期偏移」拆成两步：先算总日历天数，再减去其中的非工作日（周末 + 节假日）。关键点在于节假日必须可配置、可扩展，不能写死在函数里。
- 建一张
holiday_calendar表，字段至少含date（DATE类型）、is_workday（TINYINT，0=非工作日，1=工作日），支持标记调休日（比如周日上班） - 创建函数
workday_diff，接收start_date和end_date，返回整数（正数表示 end 在 start 之后的工作日数，负数反之） - 函数内用
SELECT COUNT(*)统计两个日期间is_workday = 1的记录数，注意边界：是否包含起止日需和业务对齐（多数场景是「截止日当天不算」，即开区间） - 避免在函数里做复杂 JOIN 或子查询——MySQL 存储过程调用自定义函数时，若函数含不确定行数的查询，可能触发
ER_SP_DOES_NOT_EXIST错误或性能骤降
存储过程中怎么调用并判断逾期状态？
别在过程里重复查节假日表。把工作日差作为中间变量算出来，再跟阈值比。重点防错点是 NULL 和边界日期。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 先用
IFNULL(workday_diff(@due_date, CURDATE()), 0)避免因日期无效导致整个表达式为 NULL - 逾期判断逻辑建议统一写成：
IF workday_diff(@due_date, CURDATE()) > 0 THEN 'overdue' ELSE 'normal' END IF—— 这样语义清晰，且能兼容“到期日当天不算逾期”的常见规则 - 如果业务需要区分「逾期1-3天」「逾期3天以上」，直接复用同一个
workday_diff结果做分支，不要反复调用函数（MySQL 函数调用开销不小） - 注意时区：确保
@due_date和CURDATE()在同一时区下计算，否则跨时区部署时可能某天凌晨出现状态跳变
节假日表维护和性能怎么平衡？
查一次节假日表就扫全量数据？不行。得靠索引和范围剪枝。
-
holiday_calendar.date必须建 B-tree 索引，且函数中 WHERE 条件必须能走索引（例如date BETWEEN start_date AND end_date，不能写成DATE_SUB(date, INTERVAL ...) = ...） - 每年初预生成未来3年的节假日记录（含调休），用脚本自动补全，避免手动维护遗漏
- 如果单次计算涉及跨度超2年，考虑在函数里加
IF DATEDIFF(end_date, start_date) > 730 THEN RETURN -1; END IF做快速失败，防止误操作拖垮数据库 - 别忘了给
is_workday字段加索引——某些特殊场景（如只查周末）会用到
真正难的不是写几行 SQL，而是让「工作日」这个业务概念在数据库里有唯一、可验证、可审计的落地形态。一旦节假日表数据错了一条，所有依赖它的逾期计算都会系统性偏移，而且很难回溯。所以每次上线前，务必用已知节假日组合跑一遍回归测试用例。
