period_diff计算月份差总少1个月，因其仅对yyyymm整数相减，忽略日部分；如period_diff(202403,202401)=2，但实际可能不足2整月。
PERIOD_DIFF 计算月份差时为什么总是少1个月
PERIOD_DIFF 实际计算的是“两个年月值之间的整数差”，不是日历意义上的自然月数。它把日期先转成 YYYYMM 格式（如 202403），再做减法。所以 PERIOD_DIFF(202403, 202401) = 2，但 '2024-03-01' 和 '2024-01-31' 之间其实不到2整月——它不看日部分，只看年月数字。
- 用
PERIOD_DIFF前必须先用DATE_FORMAT(dt, '%Y%m')转换，否则传入DATE类型会隐式截断为YYYYMM00，导致结果不可靠 - 如果想算「从某日到某日经历了几个完整自然月」，比如判断用户是否满3个月会员，
PERIOD_DIFF不适用，得用TIMESTAMPDIFF(MONTH, start_dt, end_dt) -
PERIOD_DIFF(yymm2, yymm1)要求yymm2 >= yymm1，否则返回负数——它不校验日期有效性，PERIOD_DIFF(202402, 202413)也能算出 -11
TIMESTAMPDIFF(MONTH, ...) 和实际业务月份的偏差在哪
TIMESTAMPDIFF(MONTH, start_dt, end_dt) 看似更合理，但它按“日期组件相减”实现：提取两个时间的年、月、日数值，然后 (end_year - start_year) * 12 + (end_month - start_month)，再根据日部分微调——仅当 end_day 时减1。
- 例如：
TIMESTAMPDIFF(MONTH, '2024-01-31', '2024-02-28')返回 0（因为 28 - 再如：
TIMESTAMPDIFF(MONTH, '2024-01-31', '2024-03-01')返回 1，而直觉上可能期望是2 - 它不处理月末特殊逻辑，比如从1月31日到2月29日（闰年）也只算0个月
- 真正需要“按日历滚动推月”的场景（如账单周期），得用
DATE_ADD(start_dt, INTERVAL n MONTH)反向验证，不能只依赖差值
如何安全地格式化日期用于 PERIOD_DIFF
直接对 DATE 或 DATETIME 列用 PERIOD_DIFF 会触发隐式转换，MySQL 把 '2024-03-15' 当作 20240315，再截前6位变成 202403——看似没问题，但遇到 '2024-03-00' 这类非法日期时行为不稳定。
- 务必显式格式化：
PERIOD_DIFF(DATE_FORMAT(end_dt, '%Y%m'), DATE_FORMAT(start_dt, '%Y%m')) - 注意时区：如果字段是
TIMESTAMP类型，DATE_FORMAT按当前会话时区解释，跨时区服务要统一设time_zone - 避免在 WHERE 中对列用函数：
DATE_FORMAT(create_time, '%Y%m') = '202403'无法走索引，应改用范围查询：create_time >= '2024-03-01' AND create_time
替代方案：用 DATEDIFF 配合除法是否靠谱
有人用 FLOOR(DATEDIFF(end_dt, start_dt) / 30.4375) 估算月数，这在统计口径宽松时可用，但极易出错。
- 30.4375 是年均日数除以12，但2月只有28/29天，7、8月连续31天——误差可累积到±3天
-
DATEDIFF('2024-01-01', '2023-12-31')= 1，除以30.4375后向下取整得0，而实际跨了2个自然月 - 无法表达“是否进入第N个月”的业务语义，比如续费提醒：你不能告诉用户“还差29天就满3个月”，得明确说“第3个月从X月X日开始”
- 真要近似，至少用
ROUND(DATEDIFF(...) / 30.4375)，但依然不推荐用于计费、合规等关键路径
月份计算没有银弹。PERIOD_DIFF 适合报表中按年月分组后的差值统计；TIMESTAMPDIFF 适合快速估算；真要匹配人类对“月”的理解，得结合业务规则做 DATE_ADD 推演或引入外部日历库。
