MySQL无FIRST_DAY()函数，需用DATE_FORMAT(date, '%Y-%m-01')安全获取当月第一天；LAST_DAY()返回当月最后一天；跨数据库应按方言选用原生函数而非强行统一。
MySQL用 LAST_DAY() 获取当月最后一天，但第一天得自己算
很多人以为 LAST_DAY() 有配套的 FIRST_DAY()，其实没有。它只负责“收尾”——给定任意日期，返回该月最后一天的日期值（如 '2024-03-15' → '2024-03-31'）。要拿第一天，得靠日期截断：用 DATE_SUB() 或 STR_TO_DATE() 把日部分归零。
常见错误是写成 DATE_SUB(date, INTERVAL DAY(date) - 1 DAY)，看似合理，但遇到 date 是 NULL 或非法格式时直接返回 NULL，且不报错，容易漏查。
- 安全写法：先用
DATE()确保输入是合法日期，再用DATE_FORMAT(date, '%Y-%m-01')直接构造第一天 - 性能注意：
DATE_FORMAT()在 WHERE 条件中会阻止索引使用，如果字段上有索引且数据量大，优先用date >= DATE_FORMAT(date, '%Y-%m-01')这类可下推的表达式 - 兼容性提醒：MySQL 5.7+ 支持；MariaDB 同样可用；但 SQLite、PostgreSQL 不认这个函数，别混用
PostgreSQL 没有 LAST_DAY()，得组合 date_trunc() 和区间运算
PostgreSQL 原生不提供 LAST_DAY()，但有更灵活的日期截断机制。核心思路是：先用 date_trunc('month', date) 拿到当月第一天，再加一个月减一天，就得到最后一天。
典型翻车点是写成 date_trunc('month', date) + '1 month' - '1 day' —— 看似对，但字符串间隔在某些版本里解析不稳定；更稳妥的是用 INTERVAL 字面量。
- 第一天：直接
date_trunc('month', date)，返回TIMESTAMP类型，时分秒为 0 - 最后一天：用
(date_trunc('month', date) + INTERVAL '1 month') - INTERVAL '1 day' - 注意类型：如果
date是DATE类型，结果也是DATE；但若原字段是TIMESTAMP WITH TIME ZONE，结果会带及时区，做范围查询时可能跨天
SQL Server 的 EOMONTH() 很省心，但 DATEFROMPARTS() 构造第一天要注意年月有效性
EOMONTH() 是 SQL Server 2012+ 提供的专用函数，支持偏移参数（比如 EOMONTH(date, 1) 返回下个月最后一天），比手算可靠得多。第一天反而容易出问题：有人用 DATEFROMPARTS(YEAR(date), MONTH(date), 1)，但如果 date 是 NULL，整个表达式就崩了，且不提示具体哪一列空。
- 防
NULL：必须包裹ISNULL()或COALESCE()，例如DATEFROMPARTS(ISNULL(YEAR(date), 1970), ISNULL(MONTH(date), 1), 1) - 边界场景：
date是'9999-12-31'时，EOMONTH(date)仍返回'9999-12-31'，没问题；但用DATEADD()手算最后一天时，加一个月可能溢出到10000年，触发错误 - 时区陷阱：SQL Server 默认不存时区，但如果应用层传入带时区的
DATETIMEOFFSET，先用SWITCHOFFSET()转成本地时区再截取，否则EOMONTH()按服务器时区算
跨数据库统一写法？别硬统一，按目标库选最稳的路径
试图用标准 SQL 写一个“所有库都认”的获取首尾日逻辑，基本等于给自己埋雷。比如 EXTRACT(YEAR FROM date) 在各库行为一致，但拼装日期字符串的方式五花八门；GENERATE_SERIES() 在 PostgreSQL 可用，在 MySQL 8.0 就得用 CTE 模拟。
真正该统一的不是 SQL 本身，而是应用层的抽象：比如在 ORM 或 DAO 层封装 getFirstDayOfMonth(date) 和 getLastDayOfMonth(date)，内部按方言路由到对应实现。
- 如果必须写纯 SQL（如报表视图），优先用目标库原生函数：MySQL 用
DATE_FORMAT()+LAST_DAY()，PG 用date_trunc()+INTERVAL，SQL Server 用DATEFROMPARTS()+EOMONTH() - 别依赖函数别名或自定义函数，生产环境部署时容易漏建
- 最容易被忽略的一点：所有这些计算都默认基于服务器当前时区。如果业务要求按用户时区算（比如财务报表按东京时间），必须显式转换，不能只靠
CURRENT_DATE
