DATE_ADD + INTERVAL 必须数值与单位分离且单位为关键字，不可引号或变量；动态单位需用CASE分支处理；注意时区、精度及NULL安全。
DATE_ADD + INTERVAL 的基本用法和常见错误
DATE_ADD 函数本身不支持直接拼接字符串来构造 INTERVAL 单位，比如 DATE_ADD(NOW(), INTERVAL '3' 'DAY') 是错的——MySQL 会报 Incorrect arguments to DATE_ADD。必须把数值和单位分开传，且单位是关键字，不能是变量或字符串。
常见错误现象包括：Unknown column 'DAY' in 'field list'（误把单位当列名）、Truncated incorrect DOUBLE value（数值类型不匹配）、或者结果始终为 NULL（因参数类型隐式转换失败）。
- 数值部分必须是整数或可转为整数的表达式，不能是带引号的字符串
- 单位（如
DAY、MONTH、YEAR）是 SQL 关键字，不能加引号，也不能用变量代替 - 第一个参数（日期）必须是合法的日期/时间类型；传入
NULL或非法格式（如'2024-13-01'）会导致整个结果为NULL
如何动态计算「N 天后过期」这类场景
所谓“动态”，通常指 N 来自字段值（如表里的 valid_days 列）或用户输入参数。这时不能写死数字，但也不能把单位变量化——得靠条件逻辑或预定义组合来绕过限制。
最稳妥的做法是：对固定单位（如只支持天/月/年），直接用字段值参与计算；若单位也要动态，则拆成多个分支处理。
- 仅数值动态（推荐）：
DATE_ADD(start_time, INTERVAL valid_days DAY)—— 要求valid_days是 INT 类型 - 单位固定为月：
DATE_ADD(start_time, INTERVAL valid_months MONTH)，注意MONTH不按日历天数算，而是“同日推移”，比如2024-01-31 + INTERVAL 1 MONTH得到2024-02-29（非2024-03-03） - 混合单位？别硬凑。MySQL 不支持
INTERVAL 3 DAY 2 HOUR这种写法（5.7+ 支持，但需严格语法），更别试图用 CONCAT 拼出整个表达式——SQL 解析器在编译阶段就拒绝
用 CASE 配合多个 DATE_ADD 实现单位动态选择
如果业务上真要支持「3天」「1个月」「半年」这种不同粒度的过期策略，只能靠 CASE 显式分路径。这是唯一安全、可读、可维护的方式。
例如字段 duration_unit 存单位标识（'day' / 'month' / 'year'），配合 duration_value 存数值：
DATE_ADD(
start_time,
CASE duration_unit
WHEN 'day' THEN INTERVAL duration_value DAY
WHEN 'month' THEN INTERVAL duration_value MONTH
WHEN 'year' THEN INTERVAL duration_value YEAR
ELSE INTERVAL 0 DAY
END
)
注意：CASE 每个分支的 INTERVAL 表达式必须语法合法，不能写成 INTERVAL duration_value duration_unit —— 后者会报错。
- 所有分支返回的类型必须兼容（都是日期偏移量），所以不能混用
HOUR和MONTH在同一 CASE 中（除非你确定 MySQL 版本支持混合精度，但不建议） - 如果
duration_value可能为 NULL，整个DATE_ADD结果也会是 NULL；建议加COALESCE(duration_value, 0)防御 - 性能影响很小，MySQL 会在执行时做分支裁剪，不会真的计算所有分支
容易被忽略的时区与精度陷阱
DATE_ADD 完全依赖输入值的类型精度。传入 DATE 类型（无时间部分），结果也是 DATE；传入 DATETIME 或 TIMESTAMP，结果保留秒级甚至微秒精度。但如果你在过期判断中混用 DATE 和 DATETIME，可能漏掉当天早些时候已过期的记录。
- 比如
start_date是DATE类型，DATE_ADD(start_date, INTERVAL 1 DAY)得到的是'2024-05-20'，比较时若用NOW() >= ...，实际从2024-05-20 00:00:00开始就算过期，而非自然日结束 - 跨时区部署时，
TIMESTAMP自动转 UTC 存储，但DATE_ADD计算仍在会话时区上下文中进行；确保time_zone设置一致，或统一用 UTC 时间做运算 - 不要依赖
DATE_ADD做长期跨度计算（如 100 年后），闰秒、历法规则变更、MySQL 自身对远期日期的支持边界（如 Y2038）都可能带来偏差
