DATEADD函数参数顺序为时间单位、数值、日期，支持自动进位但需警惕月末边界问题，应避免隐式转换和WHERE子句中列被函数包裹以保障索引性能。
DATEADD 函数的基本用法和参数顺序
DATEADD 是 SQL Server 中最直接的日期加减工具，但它的参数顺序容易记反：必须是 DATEADD(时间单位, 数值, 日期)，不是“日期 + 数值”。传错顺序会直接报错 Argument data type varchar is invalid for argument 2 of dateadd function 或隐式转换失败。
常见时间单位必须用系统识别的标识符，比如：year、month、day、hour、minute、second、millisecond（注意没有 week，要用 week 也行，但实际对应的是 ww 或 wk，推荐统一用 week）。
数值可以是正数（加）或负数（减），支持变量和表达式：
SELECT DATEADD(day, -7, GETDATE()) AS '一周前';
处理边界日期时的自动进位行为
DATEADD 不会报错，但会自动进位——这既是便利也是陷阱。比如对 2023-01-31 加一个月，结果是 2023-02-28（非 2023-02-31），因为 2 月没有 31 号；同样，对 2024-01-31 加一个月得 2024-02-29（闰年）。这种“智能截断”不报错，但业务上可能不符合预期（例如按日历月首/末计算时）。
如果你需要“保持日份不变，不足则取当月最后一天”，DATEADD 本身做不到，得配合 EOMONTH 或逻辑判断：
SELECT DATEADD(month, 1, DATEFROMPARTS(YEAR(GETDATE()), MONTH(GETDATE()), 1)) AS '下月1号';
- 别依赖
DATEADD(month, n, @date)推算“自然月”起止，尤其涉及账期、订阅周期时 - 对月末日期做加减，先用
EOMONTH(@date)显式归一化再操作更可控 -
DATEADD对datetime2和date类型行为一致，但要注意smalldatetime会丢失秒级精度
与 DATEADD 配合使用的常见错误场景
最常踩的坑不是函数不会用，而是类型隐式转换导致结果意外。例如把字符串直接传给第三个参数：
SELECT DATEADD(day, 1, '2023-01-01'); -- 表面可行，但依赖默认语言设置
一旦服务器语言设为 British 或 German，'2023-01-01' 可能被解析成 2023-01-01 或报错。安全做法是显式转换：
- 用
CONVERT(date, '2023-01-01', 120)或CAST('2023-01-01' AS date) - 避免在生产 SQL 中混用
datetime和date类型参与计算，精度差异会导致比较失效 - 在 WHERE 条件中写
DATEADD(day, 1, OrderDate) = '2023-05-01'会阻止索引使用——应改写为OrderDate = DATEADD(day, -1, '2023-05-01')
性能和索引友好写法的关键细节
DATEADD 本身开销极小，但放在 WHERE 子句左侧（如 DATEADD(day, 1, Col) > @dt）会让 SQL Server 无法有效利用 Col 上的索引。优化核心原则是：让列名单独出现在比较操作符一侧。
举例：要查“昨天之后下的单”，不要写：
WHERE DATEADD(day, 1, OrderDate) > '2023-05-01'
而应写成：
WHERE OrderDate > DATEADD(day, -1, '2023-05-01')
这样 SQL Server 才能走 OrderDate 的索引查找。另外，如果经常按“最近 N 天”过滤，考虑在查询前先算好边界值并存入变量，避免重复调用函数：
DECLARE @cutoff DATE = DATEADD(day, -30, GETDATE());<br>SELECT * FROM Orders WHERE OrderDate >= @cutoff;
跨时区运算不是 DATEADD 的职责，它只做本地时间偏移，真有时区需求得用 AT TIME ZONE 配合。
