DATEADD 是 SQL Server 最可靠的时间偏移工具，但需注意 datepart 兼容性、number 截断规则、月末边界处理及数据类型精度问题。
DATEADD 不是万能的日期计算器，但它确实是 SQL Server 里最可靠的时间偏移工具——只要用对 datepart、理解 number 的截断规则、避开边界日期陷阱。
DATEADD 的 datepart 参数别混用缩写和全称
SQL Server 允许混用缩写（如 dd、mm）和全称（如 day、month），但不同版本对大小写和拼写敏感度不一。比如 DATEADD(Minute, -30, @dt) 在某些旧版中会报错，而 DATEADD(mi, -30, @dt) 或 DATEADD(minute, -30, @dt) 更稳妥。
- 推荐统一用小写全称：
year、quarter、month、day、hour、minute、second——语义清晰且兼容性好 -
week和weekday完全不同：week是一年中的第几周，weekday是星期几（1=周日，受SET DATEFIRST影响），别在DATEADD里误用weekday -
ms（毫秒）精度有限，DATETIME类型只支持 3 毫秒精度；若需更高精度，必须用DATETIME2并配microsecond或nanosecond
number 参数不是浮点数，小数会被直接截断
很多人写 DATEADD(day, 1.7, '2026-04-21') 期望加 1 天 16 小时 48 分，结果仍是加 1 天——number 被强制转为整数，小数部分丢弃，不四舍五入。
- 要实现非整数时间偏移，必须换算成更小单位：比如加 1.7 天 →
DATEADD(second, 1.7 * 24 * 3600, '2026-04-21')，再 CAST 成INT或用FLOOR() - 负数同样截断：
DATEADD(month, -1.9, '2026-04-30')等价于DATEADD(month, -1, '2026-04-30')→2026-03-30，不是2026-03-01 - 如果目标是“上个月最后一天”，别依赖
-1月加减，而该用DATEADD(day, -1, DATEADD(month, 1, DATEFROMPARTS(YEAR(@d), MONTH(@d), 1)))
月末/季度末/年末计算容易掉进“日期不存在”坑
DATEADD 对无效日期会自动调整：比如 DATEADD(month, 1, '2026-01-31') 返回 2026-02-28（不是错误），这看似友好，实则埋雷——你可能以为它“失败了”，其实它静默修正了。
- 加一个月 ≠ 到下月同日：从 1 月 31 日加 1 月得 2 月 28 日；从 3 月 31 日加 1 月得 4 月 30 日
- 想取“本月最后一天”，别用
DATEADD(day, -1, DATEADD(month, 1, @d))，而该用更健壮的EOMONTH(@d)（SQL Server 2012+） - 跨年季度计算时，
DATEADD(quarter, 1, '2025-10-31')得2026-01-31，但如果你本意是“本季度最后一天”，那结果就错了——应先算本季第一天，再用EOMONTH
动态起止时间生成时，别忽略数据类型隐式转换
用 GETDATE() 做基准时，DATEADD(day, -7, GETDATE()) 返回带时分秒的 DATETIME，而 WHERE 条件常需“过去 7 天（含今天 00:00）”，此时直接比较会漏掉今天凌晨的数据。
- 安全写法是先归零时间：
CAST(GETDATE() AS DATE)或DATEADD(day, DATEDIFF(day, 0, GETDATE()), 0) - 若字段是
DATETIME2(7)，而你用DATEADD加减后仍为DATETIME，比较时可能因精度丢失导致索引失效 - 在 JOIN 或子查询中大量使用
DATEADD表达式，注意它无法利用索引；应优先考虑把计算移到参数端或用计算列+索引
DATEADD 的真正难点不在语法，而在你是否清楚：每次加减背后，SQL Server 都在按日历规则做静默归正——它不会报错，但可能返回你没预期到的合法日期。处理月末、跨月、时区混合场景时，务必用真实业务日期手动验证两轮。
