mysql用last_day()、sql server用eomonth()可获取当月最后一天；跨库兼容需用“下月1日减1天”逻辑，并注意时区、类型隐式转换及null处理。

MySQL用LAST_DAY()获取当月最后一天

MySQL 5.7+ 原生支持 LAST_DAY()，它直接接受一个日期值，返回该月最后一天的日期（含时间部分为 00:00:00）。注意：它不接受字符串字面量如 '2024-03'，必须是合法日期类型。

常见错误是传入不完整日期或非法格式，比如 LAST_DAY('2024-03') 会静默转成 '2024-03-01' 再计算，结果仍是 3 月 31 日——看似对，但逻辑已偏移；若传 '2024-02-30'，MySQL 会自动纠正为 '2024-03-02'，再算出 3 月 31 日，完全失真。

• 正确用法：SELECT LAST_DAY(CURDATE())、SELECT LAST_DAY('2024-03-15')
• 想固定取“本月最后一天”，优先用 CURDATE() 或 NOW()，避免依赖用户传参格式
• 该函数返回 DATE 类型，时区以 session time_zone 为准，跨时区部署时需确认时区设置

SQL Server用EOMONTH()获取当月最后一天

EOMONTH() 是 SQL Server 2012+ 引入的函数，比 DATEADD() + DAY() 组合更直观。它接受两个参数：起始日期和可选的月偏移量（默认 0），返回该月月末日期，时间部分恒为 00:00:00。

容易踩的坑是忽略第二个参数的默认行为——比如写 EOMONTH(GETDATE(), 1) 得到的是下月最后一天，而非本月；还有人误以为它能处理 NULL，实际会直接返回 NULL，不报错也不警告。

• 取本月最后一天：SELECT EOMONTH(GETDATE())
• 取上月最后一天：SELECT EOMONTH(GETDATE(), -1)
• 输入列可能为 NULL 时，建议先用 ISNULL() 或 COALESCE() 包裹，避免整行丢失

跨数据库兼容写法：不用内置函数也能搞定

当需要同时支持 MySQL、PostgreSQL、SQL Server（旧版本）甚至 SQLite 时，LAST_DAY() 和 EOMONTH() 都不可用。此时通用思路是：先取下月第一天，再减一天。

关键差异在日期运算语法：DATE_ADD()（MySQL）、DATEADD()（SQL Server）、(col + INTERVAL '1 month')（PostgreSQL）。但最稳妥的是用标准 SQL 的 EXTRACT + 字符串拼接，虽稍重但确定可控。

• MySQL/PostgreSQL 兼容写法：SELECT DATE_SUB(DATE_ADD(LAST_DAY(CURDATE()), INTERVAL 1 DAY), INTERVAL 1 DAY) —— 看似绕，实为兜底
• 纯表达式（无函数依赖）：SELECT CAST(EXTRACT(YEAR FROM CURRENT_DATE) || '-' || EXTRACT(MONTH FROM CURRENT_DATE) || '-01' AS DATE) + INTERVAL '1 month' - INTERVAL '1 day'（PostgreSQL 风格，MySQL 需改用 DATE_ADD）
• SQLite 用户注意：date() 函数支持 'start of month' 和 '+1 month'，组合可用：SELECT date(date('now', 'start of month'), '+1 month', '-1 day')

别忽略时区和字段类型带来的隐式转换

即使函数本身正确，结果也可能因字段类型或连接时区出错。例如，把 LAST_DAY(NOW()) 插入到 DATETIME 字段没问题，但插入 TIMESTAMP 字段时，MySQL 会按系统时区转成 UTC 存储，查询时再转回 session 时区——若应用层没对齐，显示的“最后一天”可能变成前一天的 23:00。

• 存储前显式转时区：CONVERT_TZ(LAST_DAY(NOW()), @@session.time_zone, '+00:00')（MySQL）
• SQL Server 中，GETDATE() 返回本地时区，SYSDATETIMEOFFSET() 才带偏移，跨时区比较务必统一基准
• 如果目标字段是 DATE 类型，函数返回值会被自动截断时间部分，无需额外 CAST；但若字段是 VARCHAR，则可能触发隐式转换，导致索引失效或比较异常

真正麻烦的不是函数怎么写，而是你不知道它在哪一层被悄悄改了时区、截了精度、或者丢了时分秒。上线前至少用 SELECT @@time_zone 和 SELECT SQL_VARIANT_PROPERTY(…) 确认过上下文。