DATEADD(month, n, date) 跨月时自动回退至目标月最后一天而非报错，如 '2024-01-31' 加1月得 '2024-02-29'；需配合 EOMONTH 实现月末或固定日对齐，且 WHERE 中应避免对列使用 DATEADD 以防索引失效。
DATEADD 在跨月计算时的实际行为
SQL Server 的 DATEADD 函数本身不“理解”月份长度，它只是按日历规则机械地移动指定单位。比如 DATEADD(month, 1, '2024-01-31') 返回 '2024-02-29'（不是错误），因为 2 月没有 31 日，SQL Server 自动回退到当月最后一天。这是跨月计算最常被忽略的隐式逻辑。
常见错误现象：
• 用 DATEADD(month, 1, '2024-01-31') 期望得到 '2024-02-31'（报错或意外截断）
• 按“自然月”预期做周期统计（如每月 15 号生成报表），但 DATEADD 不保证结果落在同一天
- 如果输入日期是某月最后一天，加减月后仍会落在目标月最后一天
- 如果输入日期在月中（如 15 日），加减月后一般保持日数不变，除非目标月天数不足 → 自动取月末
-
DATEADD不支持 “+1 calendar month” 这类语义，它只做算术位移
替代方案：EOMONTH 配合 DATEADD 实现可控跨月
单纯靠 DATEADD(month, n, date) 很难满足业务上“每月固定日”或“月末对齐”的需求。更可靠的做法是组合 EOMONTH 和 DATEADD：
SELECT DATEADD(day, 15, EOMONTH(GETDATE(), -1)) AS '上月15日', EOMONTH(GETDATE()) AS '本月最后一天', DATEADD(day, -1, EOMONTH(GETDATE(), 1)) AS '下月倒数第二天'
使用场景：
• 生成每月 15 日的账单截止时间
• 计算季度末（EOMONTH(GETDATE(), 2) 得到本季度最后一天）
• 补偿 DATEADD 的“日溢出”问题
-
EOMONTH(date, n)返回指定月数后的月末日期，稳定且无歧义 - 需要固定日（如每月 10 日）时，先用
EOMONTH定位到目标月，再用DATEADD(day, 10, ...)调整，但要检查是否超出当月天数 - MySQL / PostgreSQL 用户注意：这些数据库没有
EOMONTH，需用LAST_DAY()（MySQL）或(date + INTERVAL '1 month' - INTERVAL '1 day')（PostgreSQL）等替代
DATEADD(month, n, date) 的性能与兼容性陷阱
在 WHERE 子句中滥用 DATEADD 会导致索引失效——尤其当它包裹在列上时，例如：WHERE DATEADD(month, 1, order_date) > GETDATE()。SQL Server 无法对函数结果使用 order_date 上的索引。
- 正确写法是把计算移到右侧常量侧：
WHERE order_date > DATEADD(month, -1, GETDATE()) - SQL Server 2016+ 支持
AT TIME ZONE，但DATEADD本身不处理时区，跨时区系统需先转换为统一时区再计算 - 某些 ORM（如 Entity Framework）会把
DateTime.AddMonths()翻译成DATEADD，但 .NET 的AddMonths()行为和 SQL Server 的DATEADD(month, ...)一致，这点可放心映射
跨月计算真正复杂的地方不在语法
真正容易被绕进去的是业务定义：“加一个月”到底指什么？是日历月（可能 28–31 天）、财务月（固定 28 天）、还是滚动 30 天？DATEADD 只响应日历月，而 DATEADD(day, 30, date) 是另一套逻辑。选错语义，后面所有统计、对账、预警都会偏移。别急着写函数，先和产品/财务确认清楚“一个月”在当前场景里等于什么。
