结论：datediff与timestampdiff(day)结果可能不同，因前者仅比较日期部分且参数顺序为expr1−expr2，后者按24小时截断且计算datetime_expr2−datetime_expr1。
直接说结论：两个函数算出来的“天数”可能不一样，不是精度问题，是设计逻辑根本不同——DATEDIFF只看日期部分，TIMESTAMPDIFF(DAY, ...)按24小时整数倍截断。
参数顺序相反，一不小心就得到负数
这是最容易踩的坑。两个函数表面都接受两个时间参数，但减法方向相反：
-
DATEDIFF(expr1, expr2)计算的是expr1 - expr2（天数） -
TIMESTAMPDIFF(unit, datetime_expr1, datetime_expr2)计算的是datetime_expr2 - datetime_expr1（按 unit 单位的整数）
比如：SELECT DATEDIFF('2026-07-01', '2026-07-02') 返回 -1；而 SELECT TIMESTAMPDIFF(DAY, '2026-07-01', '2026-07-02') 返回 1。传参时如果习惯性把“开始时间”放前面，用 TIMESTAMPDIFF 就得小心——它要的是 start, end，但结果是 end - start。
含时间字段时，结果可能差整整一天
当输入带具体时间（如 '2026-07-01 23:59:59'）时，两者行为完全不同：
-
DATEDIFF直接丢弃时间部分，只比日期：'2026-07-01' 和 '2026-07-02' 永远是 1 天 -
TIMESTAMPDIFF(DAY, ...)算的是真实时间跨度除以 24 小时后向下取整：'2026-07-01 23:59:59' 到 '2026-07-02 00:00:00' 仅差 1 秒 → 结果为0
典型反例：SELECT DATEDIFF('2026-07-02 00:00:00', '2026-07-01 12:00:00') 返回 1；SELECT TIMESTAMPDIFF(DAY, '2026-07-01 12:00:00', '2026-07-02 00:00:00') 返回 0（因为不到 24 小时）。
单位支持和适用场景完全错开
DATEDIFF 只能返回天数，且不支持指定单位；TIMESTAMPDIFF 支持从 MICROSECOND 到 YEAR 共 10+ 种单位，但必须显式声明：
- 想查订单处理耗时几小时？只能用
TIMESTAMPDIFF(HOUR, create_time, finish_time) - 统计用户注册满 30 天没登录？
DATEDIFF(CURDATE(), reg_date) >= 30更直观安全 - 跨月计算会员有效期？
TIMESTAMPDIFF(MONTH, start_date, end_date)比手动拆年月靠谱
注意：TIMESTAMPDIFF(MONTH, ...) 是按日历月计算（如 1 月 31 日到 2 月 28 日算 1 个月），不是简单除以 30。
性能和 NULL 处理没区别，但别在 WHERE 里乱套函数
两个函数本身性能差异可忽略，真正影响查询速度的是：它们都会让索引失效。比如 WHERE DATEDIFF(create_time, '2026-01-01') > 180 无法走 create_time 索引。更稳妥写法是改写为范围查询：WHERE create_time > DATE_SUB('2026-01-01', INTERVAL 180 DAY)。
另外，任一参数为 NULL，两个函数都返回 NULL，记得用 IFNULL 或 COALESCE 包一层，否则可能漏数据。
最常被忽略的一点：业务上到底要“自然日间隔”还是“满 24 小时才算一天”，这个语义判断比函数选型更重要。选错不是语法错误，而是逻辑偏差。
