<p>DATE_ADD 和 DATE_SUB 是 MySQL 中最可靠、最易读的日期加减函数，比用 + 或 - 运算符更安全，尤其在跨月、跨年或处理时区/闰秒场景下不会出错。</p>
直接说结论：DATE_ADD 和 DATE_SUB 是 MySQL 中最可靠、最易读的日期加减函数，比用 + 或 - 运算符更安全，尤其在跨月、跨年或处理时区/闰秒场景下不会出错。
什么时候必须用 DATE_ADD 而不是直接加数字
MySQL 允许对日期字段做类似 date_col + INTERVAL 1 DAY 的写法，但这种语法本质是隐式调用 DATE_ADD；显式写 DATE_ADD(date_col, INTERVAL 1 DAY) 更清晰、更可控，且能避免某些边缘错误：
-
DATE_ADD('2023-01-31', INTERVAL 1 MONTH)→'2023-02-28'（自动处理 2 月天数，不会变成无效日期） - 而
'2023-01-31' + INTERVAL 1 MONTH在部分旧版本中可能报错或行为不一致 - 对
DATETIME类型做秒级操作时，DATE_ADD(dt, INTERVAL 30 SECOND)比dt + 30更明确——后者依赖 MySQL 的隐式类型转换规则，容易误判为“加 30 天”
DATE_SUB 的典型误用：别把负数 INTERVAL 当成减法替代
有人写 DATE_ADD(date_col, INTERVAL -7 DAY) 来代替 DATE_SUB(date_col, INTERVAL 7 DAY)，语法上可行，但可读性差、维护成本高：
-
DATE_SUB语义明确，一眼看出是“往前推” - 当需要组合多个偏移（如先加 2 小时再减 30 分钟），用
DATE_ADD(DATE_SUB(...))比嵌套负数INTERVAL更易调试 - 某些 ORM（如 Laravel Query Builder）生成 SQL 时会优先用
DATE_SUB，保持一致性可减少迁移风险
支持的 INTERVAL 单位和常见陷阱
INTERVAL 后面跟的单位决定计算粒度，不是所有单位都等价，尤其注意以下几点：
- 用
MONTH或YEAR时，MySQL 不按“30 天”或“365 天”硬算，而是按日历逻辑进位——DATE_ADD('2024-01-31', INTERVAL 1 MONTH)得到'2024-02-29'（因为 2024 是闰年） -
WEEK等价于7 DAY，但QUARTER是按日历季度算（即 3 个月），不是固定 90 天 - 避免混用单位：比如
INTERVAL 1 YEAR 2 MONTH合法，但INTERVAL 1 YEAR 30 DAY会报错——MySQL 不支持跨层级复合（年+日），必须拆成两次调用 - 时区敏感：如果列是
TIMESTAMP，DATE_ADD操作在存储值层面进行，不受当前 session 时区影响；但如果是DATETIME，则完全按字面值计算，不自动转换
性能与索引注意事项
在 WHERE 子句里用 DATE_ADD 或 DATE_SUB 可能导致索引失效，关键看写法：
- ✅ 安全（可用索引）：
WHERE date_col > DATE_SUB(NOW(), INTERVAL 7 DAY)—— 函数作用于常量，MySQL 能提前算出边界值 - ❌ 危险（索引失效）：
WHERE DATE_SUB(date_col, INTERVAL 7 DAY) > '2023-01-01'—— 函数作用于字段，必须逐行计算 - 如果必须做字段变换后再比较，考虑用生成列（generated column）+ 索引预计算，而不是运行时调用函数
真正容易被忽略的是：DATE_ADD 和 DATE_SUB 对 NULL 输入返回 NULL，且不会报错。如果你的业务逻辑依赖非空结果，得额外加 IS NOT NULL 判断，而不是默认它总会返回一个日期。
