last_day函数返回给定日期所在月份的最后一天，输入为date类型或可转日期的表达式，输出类型与输入一致；mysql和oracle支持该函数，postgresql和sql server需用等价逻辑替代。
LAST_DAY函数的基本用法和返回值类型
LAST_DAY 是 MySQL 和 Oracle 都支持的日期函数，作用是返回给定日期所在月份的最后一天。它不接受格式化参数，只接收一个 DATE 或能自动转为日期的表达式（比如 '2024-03-15'），返回值类型与输入一致——通常是 DATE 类型，不是字符串。
常见错误是以为它能直接处理字符串而不加转换，比如写 LAST_DAY('2024-03')：MySQL 会尝试隐式转换，但 Oracle 会报 ORA-01858: a non-numeric character was found where a numeric was expected；稳妥做法始终传入标准日期字面量或用 STR_TO_DATE / TO_DATE 显式转换。
- MySQL 示例：
SELECT LAST_DAY('2024-03-10');→ 返回'2024-03-31' - Oracle 示例：
SELECT LAST_DAY(DATE '2024-03-10') FROM DUAL;→ 同样返回31-MAR-24（取决于 NLS_DATE_FORMAT） - 若输入是月末当天（如
'2024-03-31'），LAST_DAY仍返回自身，不会出错也不会溢出
跨数据库兼容性问题：PostgreSQL 和 SQL Server 没有 LAST_DAY
PostgreSQL 和 SQL Server 原生不提供 LAST_DAY 函数，硬搬会直接报错：ERROR: function last_day(unknown) does not exist（PG）或 Invalid column name 'LAST_DAY'（SQL Server）。这时候不能靠“换方言”蒙混过关，得用等价逻辑替代。
- PostgreSQL 推荐写法：
(DATE_TRUNC('month', date_col) + INTERVAL '1 month' - INTERVAL '1 day')::DATE - SQL Server 推荐写法：
DATEADD(DAY, -1, DATEADD(MONTH, 1, DATEFROMPARTS(YEAR(date_col), MONTH(date_col), 1))) - 如果项目需多库兼容，建议封装成视图或应用层统一处理，避免 SQL 中混杂大量条件分支
常见误用场景：和日期范围查询一起用时的边界陷阱
很多人用 LAST_DAY 构造“当月最后一天”，再配合 BETWEEN 查询当月数据，结果漏掉最后几小时甚至整天。根本原因是：如果字段是 DATETIME 或 TIMESTAMP 类型，LAST_DAY 返回的是 00:00:00 时间点，而 BETWEEN '2024-03-01' AND '2024-03-31' 实际只覆盖到 '2024-03-31 00:00:00'，而非全天。
- 正确写法（推荐）：
date_col >= '2024-03-01' AND date_col （开闭区间，无时间精度依赖） - 若坚持用
LAST_DAY，至少补上时间：date_col ——但不推荐，易因时区或微秒精度出错 - 注意
LAST_DAY(NOW())在跨月临界时刻（如 3 月 31 日 23:59 执行）仍返回 3 月 31 日，不会提前算出 4 月结果
性能影响：能否在 WHERE 条件中对字段套 LAST_DAY？
可以写，但极不推荐。例如 WHERE LAST_DAY(create_time) = '2024-03-31' 会导致全表扫描——因为对列施加函数后，索引失效。MySQL 的 create_time 索引、Oracle 的 B-Tree 索引都救不了这种写法。
- 高效替代方案：把条件改写成范围，利用索引：
create_time >= '2024-03-01' AND create_time - 如果业务真要查“最后一天创建的记录”，先算出那天的起止时间（
'2024-03-31 00:00:00'到'2024-04-01 00:00:00'），再查范围 - 物化视图或生成列（MySQL 5.7+ 支持）可预先存
LAST_DAY(create_time)并建索引，但增加维护成本，小表没必要
真正麻烦的不是函数本身，而是它常被当作“日期工具人”塞进各种上下文——一不留神就撞上隐式转换、跨库断层、时间精度丢失或索引失效。用之前，先问一句：这个值接下来要参与什么运算？是否必须是日期类型？有没有更稳的区间表达方式？
