自然月环比=（本月数据-上月数据）/上月数据×100%，须按日历月（1号至月末）对齐，用year/month提取年月分组后，mysql 8.0+推荐lag()窗口函数计算，低版本需自连接并用date_format+date_sub构造上月年月，关键要确保业务时间口径、时区统一及空值处理。
自然月环比的定义和计算逻辑
自然月环比 =（本月数据 - 上月数据）/ 上月数据 × 100%，关键在于“自然月”——即按日历月（1号到月末）对齐，不是固定30天或滚动30天。这意味着必须把日期截断到年月粒度，且不能用 DATE_SUB(NOW(), INTERVAL 1 MONTH) 这类动态偏移，否则遇到跨年、大小月时会错位（比如1月31日减1个月变成12月31日，但12月实际只有31天，而1月的“自然月”应是1月1日–1月31日，对应12月1日–12月31日）。
正确做法是：先用日期函数提取年月标识（如 YEAR(date_col) 和 MONTH(date_col)），再拼成 CONCAT(YEAR(date_col), '-', LPAD(MONTH(date_col), 2, '0')) 或直接用 DATE_FORMAT(date_col, '%Y-%m')；然后按该字段分组聚合，再自连接或窗口函数拉上月值。
MySQL中用窗口函数实现月度环比（推荐）
MySQL 8.0+ 支持 LAG()，这是最直观、不易出错的方式。注意必须确保原始数据已按年月升序排列，否则 LAG() 会取错行。
常见错误现象：没加 ORDER BY year_month 就用 LAG()，导致上月值乱序；或者没去重汇总就直接套用，造成重复计数。
- 先按自然月聚合（例如统计每月订单总额）：
SELECT DATE_FORMAT(order_time, '%Y-%m') AS year_month, SUM(amount) AS monthly_amount FROM orders WHERE order_time >= '2023-01-01' GROUP BY DATE_FORMAT(order_time, '%Y-%m')
- 再用
LAG()拉上月值：SELECT year_month, monthly_amount, LAG(monthly_amount) OVER (ORDER BY year_month) AS last_month_amount, ROUND((monthly_amount - LAG(monthly_amount) OVER (ORDER BY year_month)) / LAG(monthly_amount) OVER (ORDER BY year_month) * 100, 2) AS mom_rate FROM (/* 上面的聚合子查询 */ ) t
-
LAG()第一月结果为NULL，除零错误会被自动跳过，但建议显式过滤：WHERE last_month_amount IS NOT NULL
兼容低版本MySQL（5.7及以下）的自连接写法
没有窗口函数时，得靠自连接 + 年月计算对齐。核心难点是构造“上月年月字符串”，不能简单 DATE_SUB()，而要用 STR_TO_DATE(CONCAT(YEAR(date_col)-IF(MONTH(date_col)=1,1,0), '-', LPAD(MONTH(date_col)-1+IF(MONTH(date_col)=1,12,0), 2, '0'), '-01'), '%Y-%m-%d') —— 太绕，推荐用 DATE_FORMAT(DATE_SUB(STR_TO_DATE(CONCAT(year_month, '-01'), '%Y-%m-%d'), INTERVAL 1 MONTH), '%Y-%m')。
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
使用场景：老系统无法升级、报表需兼容多版本数据库。
- 聚合结果表记为
t_curr，字段为year_month和amount - 左连接自身，关联条件：
t_curr.year_month = DATE_FORMAT(DATE_SUB(STR_TO_DATE(CONCAT(t_prev.year_month, '-01'), '%Y-%m-%d'), INTERVAL 1 MONTH), '%Y-%m') - 务必加
AND t_prev.year_month IS NOT NULL避免首月参与计算 - 性能影响：大数据量时自连接比窗口函数慢，建议在
year_month字段建索引
容易被忽略的边界问题
自然月环比真正难的不是写SQL，而是数据口径一致性。比如订单表里 order_time 是创建时间，但财务结算可能按发货时间或支付时间；又或者某天凌晨入库的数据，因时区或ETL延迟，被归入下一日甚至下一月。
这些都会让 DATE_FORMAT(order_time, '%Y-%m') 分组失真。所以实操前必须确认：date_col 的业务含义、是否已做时区归一（如全转为UTC+8）、是否存在空值或非法日期（如 '0000-00-00' 会导致 DATE_FORMAT 返回 NULL，进而让整组丢失）。
另外，ROUND(..., 2) 在除零或 NULL 时返回 NULL，前端展示需处理，不能直接当 0 显示——那会把“无上月数据”伪装成“0% 增长”。
