TRUNC(SYSDATE, 'MM') 是获取月初最稳的方式，它不依赖NLS设置和字符转换，按日历逻辑截断到月份起始日；'MM'比'month'更兼容老版本Oracle。
TRUNC('MM') 是获取月初最稳的方式
很多人用 to_date(to_char(sysdate, 'yyyy-mm') || '-01', 'yyyy-mm-dd') 拼字符串取当月第一天，但这种写法依赖 nls 设置，还容易在时区或会话参数不一致时出错。直接用 trunc(sysdate, 'mm') 更可靠——它不关心格式、不依赖字符转换，底层按日历逻辑截断到月份起始日。
注意：'MM' 和 'month' 效果相同，但建议统一用 'MM'，避免某些老版本 Oracle 对 'month' 解析异常；TRUNC(SYSDATE)（无 fmt）默认只截到日，等价于 TRUNC(SYSDATE, 'DD')，不是月初。
- 想取本季度第一天？用
TRUNC(SYSDATE, 'Q') - 想取今年第一天？用
TRUNC(SYSDATE, 'YYYY') - 如果传入的日期带时区（如
TIMESTAMP WITH TIME ZONE），TRUNC仍按本地会话时区处理，不是 UTC
ADD_MONTHS 处理跨月时要防“2月30日”陷阱
ADD_MONTHS 看似简单，但遇到月末日期会自动“靠尾”：比如 ADD_MONTHS(DATE '2026-01-31', 1) 不是报错，而是返回 2026-02-28（非闰年）。这是 Oracle 的设计行为，不是 bug，但容易导致业务逻辑偏差——比如你本意是“固定加一个月”，结果发现上月最后一天 +1 个月 ≠ 下月最后一天。
典型踩坑场景：查“上月完整数据”时写成 WHERE dt BETWEEN ADD_MONTHS(SYSDATE, -1) AND LAST_DAY(ADD_MONTHS(SYSDATE, -1))，看似合理，但如果 SYSDATE 是 5 月 31 日，ADD_MONTHS(SYSDATE, -1) 就是 4 月 30 日，而非 4 月 1 日，导致范围偏移。
- 正确做法：先用
TRUNC(ADD_MONTHS(SYSDATE, -1), 'MM')得上月第一天，再配LAST_DAY(ADD_MONTHS(SYSDATE, -1))得上月最后一天 -
ADD_MONTHS的第二个参数只取整数部分，ADD_MONTHS(SYSDATE, 2.9)等价于ADD_MONTHS(SYSDATE, 2) - 负数偏移同样生效：
ADD_MONTHS(SYSDATE, -1)安全，但ADD_MONTHS(SYSDATE, -0.5)会被截成 0，等于没动
组合 LAST_DAY + TRUNC + ADD_MONTHS 构建标准月区间
财务、报表、对账类需求最常要“某月第一天到该月最后一天”的闭区间。单独用任何一个函数都搞不定，必须组合：
比如取上月完整区间，这句是稳定可靠的：SELECT TRUNC(ADD_MONTHS(SYSDATE, -1), 'MM') AS start_date, LAST_DAY(ADD_MONTHS(SYSDATE, -1)) AS end_date FROM dual;
其中：TRUNC(ADD_MONTHS(SYSDATE, -1), 'MM') 先退到上月，再截到该月第一天；LAST_DAY(ADD_MONTHS(SYSDATE, -1)) 直接取上月最后一天——两个函数各自作用于同一个逻辑月份，不会错位。
- 别写成
TRUNC(SYSDATE, 'MM') - 1当上月最后一天：它只减 1 天，遇到 5 月 1 日就变成 4 月 30 日，看似对，但若SYSDATE是 5 月 1 日 00:00:01，TRUNC后仍是 5 月 1 日，减 1 就是 4 月 30 日 00:00:00，时间精度丢失 -
LAST_DAY返回值带具体时间（如2026-04-30 03:49:00），如需严格到 23:59:59，得手动加+ 0.99999或用TRUNC(LAST_DAY(...)) + 0.99999 - 这个组合在分区表查询中尤其重要：用
BETWEEN ... AND ...能命中分区裁剪，而用函数包裹列（如WHERE TRUNC(dt, 'MM') = ...）会失效
用 CONNECT BY LEVEL 生成连续月份时 TRUNC 和 ADD_MONTHS 必须对齐
做趋势分析或补全空缺月份时，常用 CONNECT BY LEVEL 生成序列。这时候如果混用不同基准，月份会漂移：
错误写法：SELECT ADD_MONTHS(TRUNC(SYSDATE, 'MM'), LEVEL - 1) AS month_start FROM dual CONNECT BY LEVEL
它生成的是“当前月第一天、下月第一天、下下月第一天”，看着没问题，但如果你后续想用 LAST_DAY 配对，就得确保每个 ADD_MONTHS 的输入都是月初——否则 LAST_DAY(ADD_MONTHS(SYSDATE, 1)) 可能返回 6 月 30 日，但 ADD_MONTHS(SYSDATE, 1) 本身是 6 月 1 日 03:49，和月初不对齐。
- 安全写法：所有计算统一以
TRUNC(SYSDATE, 'MM')为起点，例如SELECT TRUNC(ADD_MONTHS(TRUNC(SYSDATE, 'MM'), LEVEL - 1), 'MM') AS month_start, LAST_DAY(ADD_MONTHS(TRUNC(SYSDATE, 'MM'), LEVEL - 1)) AS month_end FROM dual CONNECT BY LEVEL - LEVEL 从 0 开始更直观？可以，但记得调整偏移量：
LEVEL - 1改成LEVEL，同时把起始TRUNC(SYSDATE, 'MM')换成ADD_MONTHS(TRUNC(SYSDATE, 'MM'), -1) - 别依赖
SYSDATE的秒级精度做循环控制，LEVEL生成的是整数序列，和时间无关
实际用的时候，最易被忽略的是：所有涉及“某月”的计算，必须明确是以「该月任意一天」为基准，还是以「该月第一天」为基准。混用会导致跨月边界模糊，尤其在月末最后几小时跑定时任务时，SYSDATE 的毫秒级变化可能让 ADD_MONTHS 和 TRUNC 的组合产出不同结果。
