如何实现SQL日期加减查询 使用DATE_ADD/SUB函数
MySQL里DATE_ADD和DATE_SUB怎么写才不报错
直接上手写DATE_ADD或DATE_SUB，最容易栽跟头的地方就那几个：参数顺序搞反、日期格式不合法，或者干脆把字符串当日期用。
这两个函数的语法规则其实很明确：第一个参数必须是原始日期（可以是DATE、DATETIME类型，或者一个格式正确的字符串），第二个参数才是INTERVAL表达式。举个例子，DATE_ADD('2024-01-01', INTERVAL 7 DAY)是标准写法；但如果写成DATE_ADD(7, INTERVAL '2024-01-01' DAY)，数据库会毫不客气地抛出一个Incorrect datetime value错误。
- 如果原始日期字段是
CHAR或VARCHAR类型，务必先用STR_TO_DATE()函数把它转成标准的日期类型，否则加减运算的结果很可能出乎意料。 INTERVAL后面的时间单位必须使用小写字母（比如day、month）。在严格模式下，使用大写（DAY）或驼峰写法（Day）都可能导致执行失败。- 千万别对
NULL值调用这两个函数——结果永远是NULL，而且不会报错，排查起来相当麻烦。
PostgreSQL和SQL Server用户别硬套DATE_ADD
这里有个关键区别：MySQL的DATE_ADD在其他主流数据库里压根不存在。如果直接把MySQL的脚本复制到PostgreSQL或SQL Server里运行，等待你的多半是syntax error。
在PostgreSQL里，日期加减用的是+和-操作符配合INTERVAL字面量，比如created_at + INTERVAL '30 days'。而SQL Server用的是DATEADD()函数，不仅函数名不同，参数顺序也正好相反：先指定单位，再是数值，最后才是日期，而且单位要用缩写（如dd代表天，mm代表月）。
- PostgreSQL的
INTERVAL '1 month'在处理月末日期时更“聪明”。比如1月31日加上一个月，它会自动得到2月28日（或29日）。相比之下，MySQL的DATE_ADD('2024-01-31', INTERVAL 1 MONTH)会先算出2024-02-31这个无效日期，然后内部处理成2024-03-03。 - SQL Server的
DATEADD(mm, 1, '2024-01-31')结果则是2024-02-29，它会自动取目标月份的最后一天，这个逻辑往往更符合业务直觉。 - 想写跨数据库通用的日期加减语句？标准SQL的写法
CURRENT_DATE + INTERVAL '7' DAY或许是个选择，但请注意，它只在PostgreSQL或支持标准SQL的数据库中有效，MySQL并不支持这种语法。
WHERE条件里加减日期，索引还有效吗
答案是：只要别把日期字段本身包裹在函数里，索引就能正常发挥作用。举个例子，WHERE order_date > DATE_SUB(NOW(), INTERVAL 30 DAY)这个写法是安全的，因为order_date字段是“裸露”在比较运算符左边的。但如果是WHERE DATE_SUB(order_date, INTERVAL 7 DAY) > '2024-01-01'，那么order_date上的索引就完全失效了。
- 最佳实践是，尽量把计算放在常量那一侧，让需要查询的字段单独出现在比较运算符的左边。
- 如果业务逻辑复杂，确实必须用函数处理字段（例如查询“过去7天内下单且发货延迟超过3天的订单”），可以考虑在表中增加一个计算列并为其建立索引，而不是在每次查询时进行实时计算。
- 像
NOW()、CURDATE()这类函数本身不会导致索引失效，但由于它们的返回值每次查询都可能变化，优化器对结果集的预估可能不准，有时会导致执行计划不稳定。
用字符串拼日期再加减？危险操作
有些开发者为了灵活性，喜欢动态构造日期字符串，比如用CONCAT(YEAR(NOW()), '-01-01')拼出一个年初日期，再传给DATE_ADD。这种做法看似巧妙，实则隐患重重。
一旦拼接出的字符串格式非法（例如不小心多了一个短横变成'2024--01-01'），整个表达式会静默地返回NULL。更棘手的是，如果数据库开启了STRICT_TRANS_TABLES严格模式，这种查询会直接报错并中断执行。
- 生成日期时，应优先使用语义明确的函数，如
MAKEDATE(year, dayofyear)或STR_TO_DATE(str, format)。 - 如果非要用字符串拼接不可，务必在传入
DATE_ADD前进行格式校验。在MySQL 8.0.29及以上版本，可以使用IS_VALID_DATE()函数，或者借助正则表达式来验证，不要指望DATE_ADD函数能自动纠错。 - 还有一个容易忽略的细节：时区。
NOW()函数返回的是当前会话时区的时间，而数据库表中存储的可能是UTC时间。在日期加减前，必须确认参与运算的字段和函数所处的时区是否一致，否则很容易导致凌晨时段的数据错位一整天。
说到底，日期加减操作看似基础，真正让开发者头疼的，往往是那些隐式的类型转换、不易察觉的时区差异，以及跨数据库时语法上那些微妙的区别。把这些细节理顺了，问题也就迎刃而解了。
