DATEDIFF返回date1-date2的天数差，正负号具业务含义；用于到期提醒时需注意条件顺序、生效期判断、NULL覆盖及服务器时区一致性。
DATEDIFF 函数返回的是天数差，正负号有明确业务含义
DATEDIFF 计算两个日期之间的**天数差**，结果是 date1 - date2（MySQL 8.0+ 和 5.7 行为一致）。比如 DATEDIFF('2024-12-01', '2024-11-25') 返回 6，而反过来则返回 -6。业务中常把到期日作为 date1，当前日期作为 date2，这样结果 > 0 表示“还剩几天”，= 0 表示“今天到期”，
常见错误是搞反参数顺序，导致提醒逻辑全乱：比如本该查“3 天内到期”的记录，却写成 DATEDIFF(NOW(), expire_date) ，实际查出来的是“已过期 ≤3 天”的数据。
- 推荐固定写法：
DATEDIFF(expire_date, CURDATE())—— 结果直观对应“剩余天数” -
CURDATE()比NOW()更安全，避免时间部分干扰（NOW()含时分秒，但DATEDIFF会自动截断，可读性差） - 注意字段类型：
expire_date必须是DATE或DATETIME；若存的是字符串（如'20241201'），得先用STR_TO_DATE(expire_date, '%Y%m%d')转换，否则返回NULL
在 WHERE 中直接过滤“7 天内到期”要小心 NULL 和历史数据
业务系统里常需要定时查出“即将到期”的记录发通知。典型 SQL 是：
SELECT id, user_id, expire_date FROM subscriptions WHERE DATEDIFF(expire_date, CURDATE()) BETWEEN 0 AND 7;
但这会漏掉两类关键数据：
- 已过期但需补提醒（比如
DATEDIFF(expire_date, CURDATE()) = -1的用户，可能刚错过续费） -
expire_date IS NULL的记录——DATEDIFF(NULL, ...)永远返回NULL，被BETWEEN过滤掉，但这类记录往往代表“永久有效”或“异常状态”，需单独处理 - 如果表数据量大，
DATEDIFF(expire_date, CURDATE())无法走索引（函数作用于字段），建议改写为范围查询：WHERE expire_date >= CURDATE() AND expire_date ，这样能命中 <code>expire_date上的索引
结合 CASE WHEN 做多级状态分类，比应用层判断更高效
前端或运营常需要区分“未开始”“进行中”“7 天预警”“已到期”“已过期”等状态。与其在代码里反复 if-else，不如在 SQL 层用 CASE WHEN 一次性产出状态码：
SELECT id,
CASE
WHEN start_date > CURDATE() THEN 'not_started'
WHEN DATEDIFF(expire_date, CURDATE()) > 7 THEN 'active'
WHEN DATEDIFF(expire_date, CURDATE()) >= 0 THEN 'warning'
ELSE 'expired'
END AS status
FROM contracts;注意点：
- 必须按逻辑先后排序条件，因为
CASE是顺序匹配；比如把> 7放在>= 0后面就永远不生效 - 别忘了
start_date判断——很多业务不是“只要没过期就算有效”，而是有明确生效期 - 所有分支都要覆盖，否则
ELSE漏掉的记录状态为NULL，容易引发下游空指针
跨月/闰年场景下 DATEDIFF 依然可靠，但别和 TIMESTAMPDIFF 混用
DATEDIFF 只算“日历天数差”，不考虑时区、夏令时或月份长度，所以 DATEDIFF('2024-03-01', '2024-02-01') 就是 29（2024 是闰年），DATEDIFF('2024-03-01', '2024-01-31') 是 31。这种“傻瓜式相减”反而是业务提醒需要的——用户只关心“还有几天”，不关心“过了几个自然月”。
容易踩的坑是误用 TIMESTAMPDIFF：
-
TIMESTAMPDIFF(DAY, d1, d2)看似一样，但它计算的是“完整天数”，且受时分秒影响（比如d1='2024-01-01 23:59:59',d2='2024-01-02 00:00:01'，DATEDIFF返回1，TIMESTAMPDIFF(DAY, ...)返回0） -
TIMESTAMPDIFF(MONTH, ...)会按月对齐计算（如从 1 月 31 日到 2 月 28 日算 1 个月），但业务提醒几乎不需要这种语义 - 结论：只要需求是“X 天内提醒”，无条件选
DATEDIFF，别为了“看起来更高级”换函数
真正复杂的是时区。如果服务器时区和业务所在地不一致（比如数据库在 UTC，业务在中国），CURDATE() 返回的是服务器本地日期，会导致提醒提前或延后整整一天。这时必须统一用 CONVERT_TZ(CURDATE(), '+00:00', '+08:00') 或直接在应用层生成日期传入，不能依赖数据库当前时间。
