last_day函数仅mysql原生支持，返回当月最后一天日期；postgresql用date_trunc+interval，sql server用eomonth，sqlite需手动拼接；where中使用会导致索引失效，应改用日期范围查询。
LAST_DAY 函数在 MySQL 中才原生支持
PostgreSQL、SQL Server、SQLite 都没有 LAST_DAY 这个函数，直接写会报错：ERROR 1305 (42000): FUNCTION db.LAST_DAY does not exist。只有 MySQL（8.0+ 和 5.7）原生提供该函数，且只接受 DATE 或能自动转为日期的表达式（如字符串 '2024-03-15'）。
用法很简单：LAST_DAY(date) 返回当月最后一天的日期值，类型仍是 DATE。比如 LAST_DAY('2024-03-10') 返回 '2024-03-31'；LAST_DAY('2024-02-01') 返回 '2024-02-29'（闰年正确处理）。
- 参数不能是时间戳（如
1712000000），也不能是纯年份或年月字符串（如'2024'或'2024-03'），否则返回NULL - 如果传入非法日期（如
'2024-02-30'），MySQL 会先尝试矫正（变成'2024-03-01'），再算最后一天，结果可能不符合预期 - 配合
DATE_SUB或INTERVAL可轻松获取上个月最后一天：LAST_DAY(DATE_SUB(CURDATE(), INTERVAL 1 MONTH))
其他数据库怎么等效实现？
PostgreSQL 没有 LAST_DAY，但可以用 (date_trunc('month', d) + INTERVAL '1 month - 1 day')::date；SQL Server 要靠 EOMONTH(d) —— 注意不是 DATEADD 堆砌；SQLite 则必须手动拼字符串加 strftime。
例如 PostgreSQL 中：
SELECT (date_trunc('month', '2024-03-15'::date) + INTERVAL '1 month - 1 day')::date;
SQL Server 更简洁：
SELECT EOMONTH('2024-03-15');
关键点：别硬套 MySQL 写法，各数据库日期函数语义和边界行为差异很大，尤其涉及月末跨月、闰年、时区时，EOMONTH 和 LAST_DAY 行为一致，但 date_trunc + INTERVAL 在 PostgreSQL 中对 TIMESTAMP WITH TIME ZONE 会受本地时区影响。
WHERE 条件里用 LAST_DAY 容易慢，别这么干
在查询条件中对字段套 LAST_DAY(created_at)（比如 WHERE LAST_DAY(created_at) = '2024-03-31'）会导致索引失效，因为函数作用于列，优化器无法下推索引范围扫描。
- 正确做法是反向推导日期范围：
WHERE created_at >= '2024-03-01' AND created_at - 如果真要查“某天是否为当月最后一天”，可改用：
created_at = LAST_DAY(created_at)，这个在 MySQL 中能走索引（前提是created_at有索引且类型为DATE或DATETIME） - 注意：如果
created_at是TIMESTAMP类型且带时分秒，LAST_DAY(created_at)返回的是日期（00:00:00），比较时隐式转换可能出偏差，建议显式转日期：DATE(created_at) = LAST_DAY(created_at)
LAST_DAY 对 NULL 输入返回 NULL，不是报错
这点常被忽略：如果传入 NULL，LAST_DAY(NULL) 直接返回 NULL，不会中断查询。但后续逻辑若没做空值判断（比如 WHERE last_day_col > '2024-01-01'），就会漏掉整行——因为 NULL > anything 结果是 UNKNOWN，不满足 WHERE 条件。
安全写法是显式处理：
WHERE LAST_DAY(date_col) IS NOT NULL AND LAST_DAY(date_col) >= '2024-01-01'
或者更推荐提前过滤掉空值：WHERE date_col IS NOT NULL，避免重复计算。
真正麻烦的是嵌套使用，比如 LAST_DAY(LAST_DAY(date_col)) —— 第二层输入已是月末日，再算一次还是同一天，但语义混乱且无意义，容易误导后续维护者。
