DATEDIFF()直接计算日期天数差但参数顺序为结束日期在前、开始日期在后，易因反序得负数；TIMESTAMPDIFF()单位灵活且顺序更直观，推荐用于跨月或需防NULL场景。
DATEDIFF() 是最直接的函数，但要注意参数顺序
MySQL 提供了 DATEDIFF() 函数专门用于计算两个 DATE 或 DATETIME 值之间的天数差，结果是整数。关键点在于：第一个参数是「结束日期」，第二个是「开始日期」，即 DATEDIFF(end_date, start_date)。如果顺序反了，结果会是负数——这在统计“已逾期天数”时可能正是你需要的，但做“间隔天数”时容易出错。
常见错误现象：DATEDIFF('2023-01-01', '2023-01-10') 返回 -9，而不是 9。
- 只接受 DATE / DATETIME 类型；传入字符串会隐式转换，但若格式非法（如
'2023/01/01'在 strict 模式下）可能报错Incorrect date value - 忽略时间部分：即使字段是
DATETIME，DATEDIFF()也只比对日期部分，'2023-01-01 23:59:59'和'2023-01-02 00:00:01'的差仍是1 - 如果需要包含小时级精度，得用
TIMESTAMPDIFF(DAY, ...)或手动转为秒再除
用 TIMESTAMPDIFF() 可以更灵活控制精度和方向
TIMESTAMPDIFF() 不仅支持天数，还能按 YEAR、MONTH、HOUR 等单位计算，且参数顺序与 DATEDIFF() 相反：TIMESTAMPDIFF(unit, start_date, end_date)。这个顺序更符合直觉（“从 A 到 B 经过多少 unit”），也避免负值误判。
示例：TIMESTAMPDIFF(DAY, '2023-01-01', '2023-01-10') 明确返回 9。
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
- 单位必须大写：用
day会报错Unknown or incorrect time value - 支持
DATE、DATETIME、TIMESTAMP，也接受合法字符串（如'2023-01-01'） - 对跨月/跨年计算更稳健，比如
TIMESTAMPDIFF(MONTH, '2023-01-31', '2023-02-28')返回1，而简单减法会出错
别直接用减法（date1 - date2），它不可靠
有人试过 date_col1 - date_col2，看起来能出数字，但这不是标准做法，且极易翻车：
- 实际执行的是字符串拼接式隐式转换：MySQL 把日期转成
YYYYMMDD格式整数再相减，'2023-01-10' - '2023-01-01'得到9是巧合，'2023-01-01' - '2022-12-25'却得76（因为20230101 - 20221225 = 8776？不，是20230101 - 20221225 = 8876，但 MySQL 实际按 yyyymmdd 解析后算的是数值差，完全不是天数） - 一旦涉及跨年（如
'2023-01-01' - '2022-12-31'）或月份位数变化（'2023-01-01' - '2023-10-01'），结果毫无意义 - 在严格 SQL 模式下可能直接报错，或在不同 MySQL 版本中行为不一致
处理 NULL 或非法日期时要加防护
生产环境中，DATE 字段常含 NULL，或因数据清洗不彻底存在非法值（如 '0000-00-00'）。直接套用 DATEDIFF() 会导致整行结果变 NULL，或触发 warning。
- 用
COALESCE()填充默认值：DATEDIFF(COALESCE(end_date, CURDATE()), COALESCE(start_date, CURDATE())) - 过滤非法日期：
WHERE start_date != '0000-00-00' AND end_date != '0000-00-00'（注意：MySQL 8.0+ 默认禁用零日期，需确认 sql_mode） - 若需区分「无数据」和「0 天」，建议显式判断：
CASE WHEN start_date IS NULL OR end_date IS NULL THEN NULL ELSE DATEDIFF(end_date, start_date) END
实际业务里，DATEDIFF() 足够快又够稳，但只要涉及跨月逻辑、需要正向语义、或字段可能为空，TIMESTAMPDIFF() + COALESCE() 的组合更少踩坑。零日期和时区问题不在本次范围，但它们真出现时，错误往往藏得更深。
