DATEADD正确用法是DATEADD(datepart, number, date)，number可正可负；“30天前”应写为DATEADD(day, -30, GETDATE())；datepart不区分大小写但推荐小写；注意时区、索引友好性及跨月边界问题。
DATEADD 在 SQL Server 中的正确用法
SQL Server 的 DATEADD 函数是计算相对日期最直接的方式，但它不接受负数单位（比如 DAY, -30），而是靠「负的数值参数」实现倒推。很多人卡在语法上，以为要写成 DATEADD(-30, DAY, GETDATE())——这是错的，会报错 Incorrect syntax near ','。
-
DATEADD参数顺序固定为：DATEADD(datepart, number, date)，其中number可正可负 - 想算“30天前”，就写
DATEADD(day, -30, GETDATE())，不是-30放前面 -
datepart不区分大小写，但推荐用小写day、month等，避免和保留字冲突（比如DAY在某些上下文中可能被误解析） - 注意时区：如果数据库服务器和业务时区不一致，
GETDATE()返回的是服务器本地时间，建议确认是否该用SYSDATETIMEOFFSET()或转换后比较
构造过去30天的起止范围（含边界）
实际查询中，“过去30天”通常指从今天往前推30天（含今天），即 [30天前 00:00:00, 今天 23:59:59]。直接用 DATEADD 拼时间容易漏掉秒级精度或跨日问题。
- 起点推荐用
CAST(DATEADD(day, -29, GETDATE()) AS DATE)—— 先减29天再转DATE，得到当天 00:00:00；因为“过去30天”包含今天，所以往前推29天才是第1天的开始 - 终点别用
GETDATE()直接比较，而应写成CAST(GETDATE() AS DATE)或DATEADD(day, 1, CAST(GETDATE() AS DATE))，然后用而非 <code>，避免午夜数据丢失 - 更稳妥的写法（兼容性高、无时区歧义）：
WHERE order_date >= DATEADD(day, -29, CAST(GETDATE() AS DATE))<br> AND order_date < DATEADD(day, 1, CAST(GETDATE() AS DATE))
MySQL / PostgreSQL 用户别硬套 DATEADD
MySQL 没有 DATEADD，PostgreSQL 也没有——它们用完全不同的函数。强行复制 SQL Server 写法只会报错 FUNCTION DATEADD does not exist 或类似提示。
- MySQL 用
DATE_SUB(NOW(), INTERVAL 30 DAY)计算起点，NOW()是终点参考；注意INTERVAL后单位必须是复数（DAY❌，DAYS❌，正确是DAY✅——等等，其实是DAY，但语法是INTERVAL 30 DAY，不是DAYS） - PostgreSQL 用
CURRENT_DATE - INTERVAL '30 days'，注意单引号和空格，'30 days'是字符串字面量，不能写成30 days - 跨数据库写法不可行；如果项目要兼容多引擎，建议把日期逻辑提到应用层，或用视图/CTE 封装差异
为什么 WHERE 子句里用 DATEADD 可能拖慢查询
在 WHERE 条件中对字段使用 DATEADD（如 WHERE DATEADD(day, 1, order_date) > ...）会让索引失效——因为数据库无法用索引快速定位经函数变换后的值。
- 优先把函数作用于常量侧，例如
WHERE order_date > DATEADD(day, -29, GETDATE())，这样order_date保持原始列形式，能走索引 - 如果必须对字段加工（比如查“下单后第7天付款”的记录），考虑增加计算列并建索引，而不是每次查都算
- 用
EXPLAIN或执行计划确认是否走了索引；SQL Server 中看Index Seek是否出现，而不是Index Scan
日期范围看似简单，但 DATEADD 的参数顺序、时区隐含行为、索引友好度这三点，最容易在上线后暴露问题。尤其是当业务要求“精确到秒”或“跨月计算”（比如 DATEADD(month, -1, '2024-03-31') 会变成 2024-02-29），得提前验证边界 case。
