timestampdiff 更通用，datediff 仅计算日期部分的天数差且会截断时间；timestampdiff 支持秒、分、时、日、月、年等单位并按日历逻辑计算，但需注意 month/year 的边界规则；两者遇 NULL 均返回 null，非法时间在宽松模式下转为零日期；where 中对时间字段用函数会导致索引失效。
mysql 里算两个时间差，该用 TIMESTAMPDIFF 还是 datediff
直接说结论：TIMESTAMPDIFF 更通用，DATEDIFF 只算“天数差”，且只认日期部分。如果你要算小时、分钟、月、年，或者输入带时分秒的 DATETIME 值，DATEDIFF 会默默截断时间部分，结果可能和你预期差很远。
比如：DATEDIFF('2024-01-01 23:59:59', '2024-01-01 00:00:01') 返回 0 —— 它只比对 2024-01-01 和 2024-01-01，完全忽略后面的时间。
-
TIMESTAMPDIFF第一个参数指定单位（SECOND、MINUTE、HOUR、DAY、MONTH、YEAR），支持完整时间精度 -
DATEDIFF固定按“日”算，且自动DATE()化两个参数，等价于DATEDIFF(DATE(a), DATE(b)) - 如果字段是
TIMESTAMP或DATETIME类型，又想精确到小时，别用DATEDIFF，它没这能力
TIMESTAMPDIFF 单位选错导致结果反直觉
单位不是随便写的，TIMESTAMPDIFF(MONTH, a, b) 不是简单拿两个时间戳除以 30 天，而是按“日历月”推算：看中间跨了多少个完整月份边界。比如从 1 月 31 日到 2 月 28 日（非闰年），TIMESTAMPDIFF(MONTH, '2024-01-31', '2024-02-28') 返回 0，因为没跨过 2 月 31 日这个不存在的边界；但 '2024-01-31' 到 '2024-03-01' 就返回 1。
- 算“实际经过多少天”用
TIMESTAMPDIFF(DAY, a, b)，和DATEDIFF行为一致（但更透明） - 算“距离下个月还有几天”这类业务逻辑，别依赖
MONTH单位，它不等于(b - a) / (24*60*60*30) -
YEAR单位同理：只看年份是否变化，不考虑具体日期，“2023-12-31 到 2024-01-01”返回1，但“2023-01-01 到 2024-12-31”也只返回1
NULL 输入或非法时间格式让两个函数都静默失败
这两个函数遇到 NULL 参数，统一返回 NULL，不会报错；遇到非法时间字符串（如 '2024-02-30'），MySQL 默认开启宽松模式时会转成 '0000-00-00'，然后继续算——结果毫无意义，还难排查。
- 查前先用
IS_VALID_DATE()（MySQL 8.0.29+）或STR_TO_DATE(col, '%Y-%m-%d')配合IS NOT NULL过滤脏数据 - 在严格 SQL 模式下（
STRICT_TRANS_TABLES），非法时间会报错，但NULL仍返回NULL，得单独判断 - 如果字段允许为空，写法建议包一层
IFNULL(TIMESTAMPDIFF(...), 0)或明确处理逻辑，别留空值穿透到上层
性能差异几乎可以忽略，但索引失效风险要注意
单纯调用 TIMESTAMPDIFF 或 DATEDIFF 对查询性能影响极小，它们都是内置函数，执行很快。真正掉坑里的是在 WHERE 条件里对时间字段做函数运算，比如 WHERE TIMESTAMPDIFF(DAY, create_time, NOW()) > 30 —— 这会让 create_time 上的索引完全失效。
- 正确写法是把函数移到右边：
WHERE create_time -
DATEDIFF(a, b) > 30同样有这问题，本质是“对索引列应用函数” - 如果必须用
TIMESTAMPDIFF做范围判断，优先考虑改写为DATE_ADD/DATE_SUB形式，保持左边是纯列引用
时间计算本身不重，但怎么嵌进查询里，才是容易被忽略的复杂点。