直接说结论：
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判断，而不是默认它总会返回一个日期。
