DATEADD是SQL Server中用于日期加减的核心函数，语法为DATEADD(datepart,number,date)，其中datepart须为预定义关键字（如year、month、day等），number为整数（正加负减），date须为日期类型；它不被MySQL/PostgreSQL原生支持，跨库迁移需重写；使用时需注意索引失效风险及month与day语义差异。
DATEADD 在 SQL Server 中的正确用法
DATEADD 只在 SQL Server、Azure SQL 和某些兼容 T-SQL 的数据库中原生支持，MySQL、PostgreSQL 或 SQLite 都不认这个函数。如果你执行 DATEADD 却报错 Invalid column name 'DATEADD' 或 Unknown function 'DATEADD'，大概率是数据库类型不对。
在 SQL Server 中，它的语法是 DATEADD(datepart, number, date)，三个参数缺一不可，顺序不能调换：
-
datepart必须是预定义关键字，比如day、month、year、week，不能写成字符串（如'day'）或变量名 -
number是整数，可正可负；正数表示“向后加”，负数表示“向前减” -
date必须是日期类型（DATE、DATETIME、DATETIME2等），传入字符串会触发隐式转换，可能出错或结果意外
计算合同到期日：DAY vs MONTH 的关键区别
用 DATEADD(day, 30, start_date) 和 DATEADD(month, 1, start_date) 看似都“加一个月”，实际逻辑完全不同。前者是机械加 30 天，后者是按日历月份推进——遇到 1 月 31 日加 1 个月会变成 2 月 28 日（或 29 日），但加 30 天会落到 3 月 2 日。
合同类业务通常要求“自然月对齐”，应优先用 month。但要注意边界情况：
- 起始日是 1 月 31 日 → 加 1 个月得 2 月 28 日（非 3 月 3 日）
- 起始日是 3 月 31 日 → 加 1 个月得 4 月 30 日（4 月无 31 日）
- 若需严格“30 天后”，必须用
day，不能依赖month
示例：从今天起 6 个月后到期
SELECT DATEADD(month, 6, GETDATE()) AS expiry_date;
WHERE 条件里直接用 DATEADD 容易踩的坑
把 DATEADD 放在 WHERE 子句右侧（如 WHERE due_date > DATEADD(day, -7, GETDATE())）通常是安全的；但若写成 WHERE DATEADD(day, 30, create_date) = '2025-06-01'，会导致索引失效——因为字段被函数包裹，SQL Server 无法走 create_date 上的索引。
更高效的做法是移项，把函数挪到常量侧：
- ❌ 错误：
WHERE DATEADD(day, 30, create_date) >= '2025-06-01' - ✅ 正确：
WHERE create_date >= DATEADD(day, -30, '2025-06-01')
这样优化器能利用 create_date 索引快速定位。
跨数据库迁移时 DATEADD 没法直接替换
如果项目要从 SQL Server 迁到 MySQL，DATEADD(day, 15, order_date) 得改成 DATE_ADD(order_date, INTERVAL 15 DAY)；迁到 PostgreSQL 则是 order_date + INTERVAL '15 days'。三者语法结构不同，不能靠查找替换解决。
更麻烦的是 month 行为：SQL Server 的 DATEADD(month, 1, '2024-01-31') 返回 2024-02-29，而 MySQL 的 DATE_ADD('2024-01-31', INTERVAL 1 MONTH) 返回 2024-02-29，但 PostgreSQL 的 '2024-01-31'::date + '1 month'::interval 也返回 2024-02-29——表面一致，实际底层处理逻辑不同，极端日期（如闰年+月末）仍可能产生差异。
真正保险的做法是：核心日期逻辑抽离到应用层计算，数据库只存原始值和结果值，避免在 SQL 里做复杂推导。
