EOMONTH是SQL Server 2012+原生函数，用于返回指定日期所在月最后一天，支持月偏移参数，自动处理大小月、闰年及跨年，传NULL返回NULL，不兼容MySQL/PostgreSQL。
SQL Server 里 EOMONTH 的基本用法
EOMONTH 是 SQL Server 2012+ 原生支持的函数，直接返回指定日期所在月份的最后一天。它比手动拼 DATEADD + DAY 计算更简洁、不易出错。
最常用形式是：EOMONTH(@date)，例如 EOMONTH('2024-03-15') 返回 2024-03-31；EOMONTH('2024-02-10') 返回 2024-02-29（自动适配闰年）。
- 参数必须是
date、datetime、datetime2等有效日期类型，传入字符串会隐式转换，但建议显式CAST或CONVERT避免区域设置干扰 - 第二个可选参数是月偏移量，如
EOMONTH('2024-03-15', 1)返回2024-04-30，-1则往前推一月 - 传入
NULL会直接返回NULL，不是报错 —— 这点在 JOIN 或 WHERE 中要留意空值逻辑
为什么不能在 MySQL 或 PostgreSQL 里直接用 EOMONTH
因为 EOMONTH 是 SQL Server 专属函数，MySQL 和 PostgreSQL 没有同名内置函数。强行执行会报错：Invalid column name 'EOMONTH' 或类似语法错误。
替代方案要按数据库区分：
- MySQL：用
LAST_DAY(@date)，行为一致，也支持字符串输入（如LAST_DAY('2024-03-15')） - PostgreSQL：用
(DATE_TRUNC('month', @date) + INTERVAL '1 month - 1 day')::date，或封装成自定义函数 - 如果写跨库 SQL（比如 ORM 动态生成），得通过方言判断或抽象层屏蔽，不能硬写
EOMONTH
EOMONTH 在 WHERE 条件里容易踩的性能坑
直接在过滤条件中对字段套 EOMONTH，比如 WHERE EOMONTH(OrderDate) = '2024-03-31'，会导致索引失效 —— 因为 SQL Server 无法对计算列高效使用普通日期索引。
更高效的做法是把条件改写成范围查询：
WHERE OrderDate >= '2024-03-01' AND OrderDate < '2024-04-01'
这样能走 OrderDate 上的索引。如果业务确实依赖月末逻辑（比如统计当月最后一天的订单），建议提前在表里加一个计算列 OrderMonthEnd AS EOMONTH(OrderDate) 并建索引。
- 计算列需标记为
PERSISTED才能建索引 - 注意时区：如果
OrderDate是datetimeoffset，EOMONTH会按本地时区截断，可能和预期不符
和 DATEADD + DAY 手动算相比，EOMONTH 真的优势在哪
手动实现通常是：DATEADD(DAY, -1, DATEADD(MONTH, 1, DATEFROMPARTS(YEAR(@d), MONTH(@d), 1)))。虽然结果一样，但可读性差、易写错（比如漏掉 -1 或搞反顺序），且不处理边界情况（如 2024-12-15 跨年）。
EOMONTH 内部已优化所有边界逻辑，包括：
- 二月天数（平年 28，闰年 29）
- 十二月到下一年一月的进位
- 对
datetime2(7)等高精度类型的秒/纳秒部分自动归零，只保留日期部分
除非你用的是 SQL Server 2008 或更早版本（不支持该函数），否则没理由手写那一长串 DATEADD。
