DATEDIFF(end_date, start_date)计算日历天数差，结果正数表示end_date在start_date之后；需用'YYYY-MM-DD'格式，字段为NULL时返回NULL；WHERE中应避免对日期字段用DATEDIFF以防索引失效。
DATEDIFF 函数怎么用？直接看参数顺序
DATEDIFF 只接受两个 DATE 或 DATETIME 类型参数，顺序是 DATEDIFF(end_date, start_date) —— 注意，不是“大减小”，而是“后减前”。结果正数表示 end_date 在 start_date 之后的天数，负数反之。
常见错误现象：DATEDIFF('2023-01-01', '2023-01-10') 返回 -9，有人误以为是“差了9天”，其实它明确告诉你：前者比后者早9天。
- 如果只传字符串，MySQL 会尝试隐式转换，但遇到
'2023/01/01'或'01-01-2023'可能失败或误判，务必用标准'YYYY-MM-DD'格式 - 时间部分（时分秒）会被自动截断，
DATEDIFF('2023-01-01 23:59:59', '2023-01-01 00:00:01')仍返回0 - 字段类型必须能转成日期，对
NULL返回NULL，不是 0，做条件判断时要单独处理
和 TIMESTAMPDIFF 混用会出什么问题？
DATEDIFF 只算“日”粒度，且固定按日历天相减；TIMESTAMPDIFF 支持 DAY、MONTH、YEAR 等单位，逻辑更复杂（比如跨月时按实际天数还是整月算）。
使用场景：想算“入职满30天是否该发试用期工资”，用 DATEDIFF(NOW(), hire_date) >= 30 安全；但想查“入职满3个月”，别用 DATEDIFF 除以 30 —— 2月只有28天，结果不准，该用 TIMESTAMPDIFF(MONTH, hire_date, NOW()) >= 3。
-
DATEDIFF性能略高，纯日期比较无函数开销；TIMESTAMPDIFF在MONTH/YEAR模式下需解析日期结构，大数据量时有微小差异 - 两者对时区不敏感（都基于服务器当前时区解析），但若字段存的是 UTC 时间而你本地查，得先用
CONVERT_TZ对齐，否则结果偏移
WHERE 条件里用 DATEDIFF 容易踩的坑
直接写 WHERE DATEDIFF(NOW(), create_time) > 7 看似合理，但会导致 create_time 字段无法走索引 —— 因为加了函数，MySQL 无法做索引下推。
正确做法是把函数移到右边，让左边保持字段原样：
WHERE create_time < DATE_SUB(NOW(), INTERVAL 7 DAY)
这样 create_time 上的索引才能生效。实测在百万级表上，前者可能 2s+，后者 0.02s。
- 如果业务要求“最近7天”，也优先用
>= DATE_SUB(NOW(), INTERVAL 7 DAY)，而非DATEDIFF <= 7 - 涉及分区表（按日期分区），同样原则：避免对分区键列套函数，否则可能扫全表
- 注意
DATE_SUB和DATE_ADD的 INTERVAL 单位大小写不敏感，但写成INTERVAL 7 day或INTERVAL 7 DAY都行
和 PHP/Python 里的日期差对比有什么隐含差异？
MySQL 的 DATEDIFF 是纯日期运算，不考虑时区、夏令时、闰秒；而 PHP 的 DateTime::diff() 或 Python 的 datetime.date.today() - other_date 默认按本地时区 + 日历规则计算，表面结果常一致，但边界情况会不同。
典型例子：2023-10-29 凌晨1点（欧洲夏令时结束），PHP 计算 2023-10-29 到 2023-10-30 差值可能是 1 天，但若 MySQL 服务器时区设为 CET，DATEDIFF 仍返回 1 —— 看似一样，可一旦涉及带时间的 DATETIME 字段，PHP 会按真实秒数折算天数（比如 23 小时算 0 天），而 DATEDIFF 直接砍掉时间部分再减。
- 跨系统一致性要求高的场景（如审计日志天数校验），统一在 MySQL 层计算并存为冗余字段，避免应用层二次解析
- 不要依赖
DATEDIFF做精确到小时的判断，它天生就不支持；改用TIMESTAMPDIFF(HOUR, ...)或直接算 UNIX_TIMESTAMP 差值
事情说清了就结束。最常被忽略的是索引失效那条 —— 很多人调优时只盯着 SQL 写法，却没意识到 DATEDIFF 放 WHERE 里等于主动放弃索引。
