MySQL中DATE_ADD和TIMESTAMPDIFF易出错：单位须用全大写标准格式；月末加减需LAST_DAY补正；TIMESTAMPDIFF向下取整且参数顺序不可颠倒；跨时区需统一处理；隐式类型转换和索引失效需警惕；边界日期必须覆盖测试。
DATE_ADD 用错单位会直接翻车
mysql 的 date_add 不认模糊单位，比如写 '1 month' 看似没问题，但遇到 1 月 31 日加一个月，结果是 2 月 28 日（或 29 日），不是 3 月 1 日；同理，'1 day' 和 '24 hour' 在夏令时切换日可能差 1 小时。
- 始终用标准单位：
'DAY'、'MONTH'、'YEAR'、'HOUR'—— 全大写更安全，避免大小写敏感环境报错 - 别用
'WEEK'做业务逻辑基准，它按 7 天硬算，不考虑周一/周日起始，容易和业务周对不上 - 如果要“加整月”，且必须对齐月末（如账单日），用
LAST_DAY(DATE_ADD(...))补一手，而不是依赖DATE_ADD('2024-01-31', INTERVAL 1 MONTH)的默认行为
TIMESTAMPDIFF 计算结果永远向下取整
TIMESTAMPDIFF 返回的是完整单位数，不四舍五入。比如两个时间只差 23 小时 59 分，TIMESTAMPDIFF(HOUR, ...) 结果是 23，不是 24；差 29 天 23 小时，TIMESTAMPDIFF(DAY, ...) 仍是 29。
- 单位选错等于白算：想看“过了几个自然日”，用
DAY；想看“小时粒度的跨度”，用HOUR；但别用DAY去估算小时差，它丢精度 -
TIMESTAMPDIFF参数顺序不能反：TIMESTAMPDIFF(unit, start, end)，反了会出负数，而很多人没意识到负数也合法 —— 它不报错，只是逻辑翻转 - 跨时区计算前务必统一时区：如果
start和end是TIMESTAMP类型，MySQL 按系统时区转为 UTC 再算；如果是DATETIME，则完全不转时区 —— 混用类型会导致结果漂移
DATE_ADD 和 TIMESTAMPDIFF 混用时的隐式类型转换陷阱
把 DATE_ADD 的结果直接喂给 TIMESTAMPDIFF 看似顺滑，但 MySQL 在某些版本里会对 DATE 和 DATETIME 做隐式截断：比如 DATE_ADD('2024-01-01', INTERVAL 1 DAY) 返回 DATE，再跟一个带时分秒的 DATETIME 做 TIMESTAMPDIFF，会把后者自动截成 00:00:00。
- 显式转类型最稳：
TIMESTAMPDIFF(SECOND, CAST(date1 AS DATETIME), CAST(date2 AS DATETIME)) - 避免在 WHERE 条件里嵌套两层函数比对，比如
TIMESTAMPDIFF(DAY, DATE_ADD(t1, INTERVAL 1 MONTH), t2) > 0—— 索引基本失效，执行计划里常出现Using filesort - 如果字段是
TIMESTAMP，且已设默认时区，加减后参与比较前最好显式CONVERT_TZ一次，否则跨服务器部署时容易因时区配置不同产出不一致结果
测试时别只盯着正确日期，要卡边界日
多数人测试只用 “2024-01-15” 这类中间值，但真实问题全出在边界：2 月最后一天、闰年 2 月 29 日、12 月 31 日跨年、夏令时切换日（如 3 月第二个周日）、时区偏移带半点的地区（如印度 +05:30）。
- 写测试用例至少覆盖：
'2023-01-31'、'2024-02-29'、'2023-12-31 23:59:59'、'2023-10-29 02:00:00'（欧洲夏令时回拨日） - 用
SELECT @@time_zone, @@system_time_zone开头确认当前会话时区，别假设它和你的本地开发环境一致 - 如果 SQL 要导出给其他系统用（比如 Python pandas 读取），注意
DATE_ADD返回的类型可能被驱动误判为字符串，建议在 SELECT 中显式CAST(... AS DATETIME)
