LAST_DAY函数仅MySQL原生支持，其他数据库需用等效写法：PostgreSQL用date_trunc+INTERVAL，SQL Server用EOMONTH；注意时间精度与跨月风险。
LAST_DAY函数在MySQL中直接可用，但其他数据库不支持
MySQL原生支持LAST_DAY()，传入任意日期即可返回当月最后一天；PostgreSQL、SQL Server、Oracle、SQLite均无同名函数。误用会导致ERROR 1305 (42000): FUNCTION xxx.LAST_DAY does not exist这类报错。
实操建议：
- 先确认数据库类型：执行
SELECT VERSION()（MySQL）、SELECT current_setting('server_version')（PostgreSQL）或SELECT @@VERSION（SQL Server） - MySQL用户可直接使用：
SELECT LAST_DAY(CURDATE())→ 返回类似2024-06-30 - PostgreSQL用户需改用：
SELECT (date_trunc('month', CURRENT_DATE) + INTERVAL '1 month - 1 day')::date - SQL Server用户对应写法：
SELECT EOMONTH(GETDATE())
LAST_DAY(CURDATE())和LAST_DAY(NOW())效果相同但语义有差异
CURDATE()只返回日期部分（如2024-06-15），NOW()带时分秒（如2024-06-15 14:22:03）。对LAST_DAY()而言，两者结果完全一致——该函数只取输入值的年月部分做计算。
但要注意：
- 若字段是
DATETIME类型且含非零时间，用LAST_DAY(dt_col)仍安全，函数会自动忽略时间部分 - 若后续要拼接时间（比如取“当月最后一天 23:59:59”），推荐先转成日期再处理：
DATE_ADD(LAST_DAY(CURDATE()), INTERVAL 86399 SECOND) - 避免写
LAST_DAY(NOW() + INTERVAL 1 HOUR)这类表达式——加减操作可能跨月，导致结果不是预期当月末尾
用LAST_DAY做范围查询时，别漏掉时间精度陷阱
常见需求是查“本月所有数据”，容易写出WHERE create_time >= '2024-06-01' AND create_time 。这在<code>create_time为DATE类型时没问题，但若为DATETIME或TIMESTAMP，则LAST_DAY()返回的是2024-06-30 00:00:00，会漏掉当天其他时间点的数据。
正确做法：
- 用开区间避开时间截断：
WHERE create_time >= '2024-06-01' AND create_time - 或动态构造下月初：
WHERE create_time >= DATE_FORMAT(NOW(), '%Y-%m-01') AND create_time - 若坚持用
LAST_DAY()，至少补上时间：AND create_time
Oracle和SQLite用户必须绕过LAST_DAY，没有替代函数名
Oracle虽有LAST_DAY()，但参数必须是DATE类型，且不能直接传字符串（如'2024-06-15'），否则报ORA-01858: a non-numeric character was found where a numeric was expected。
SQLite则完全不提供该功能，所有日期计算都得靠strftime()拼凑。
典型写法对比：
- Oracle：
SELECT LAST_DAY(TO_DATE('2024-06-15', 'YYYY-MM-DD')) FROM DUAL - SQLite：
SELECT strftime('%Y-%m-', '2024-06-15') || CASE CAST(strftime('%d', '2024-06-15') AS INTEGER) WHEN 1 THEN '31' WHEN 2 THEN '28' ELSE '30' END（不推荐，闰年逻辑需额外判断） - 更稳妥的SQLite方案：
SELECT date('2024-06-15', 'start of month', '+1 month', '-1 day')
跨数据库写法最难缠的其实是月末边界——2月天数浮动、闰年、时区偏移，这些细节在LAST_DAY()封装下被掩盖了，一旦换库就得重新抠逻辑。
