必须先按月聚合再自关联，用YYYYMM整数格式错位连接（t1.ym = t2.ym + 1）并过滤t2.amount > t1.amount，避免跨年错误、笛卡尔积和NULL中断；窗口函数LAG可简化但需校验月份连续性。
用自关联查相邻月份订单金额变化
直接查“连续增长”不能靠单表聚合，必须把当前月和上个月数据拉到同一行对比。核心思路是让 orders 表和自己按月份错位连接：当前记录的月份 = 上一条记录的月份 + 1。
常见错误是用 DATE_SUB 或 ADD_MONTHS 时没对齐年份边界（比如 2023-12 和 2024-01），导致连接失败；另一个坑是忽略同月多条订单的情况，没先按月聚合就自关联，产生笛卡尔爆炸。
- 先用
GROUP BY YEAR(order_date), MONTH(order_date)汇总每月总金额，生成临时结果集 - 再把这个结果集自关联：
t1.year_month = t2.year_month + 1（推荐转成YYYYMM整数格式，避免日期函数跨年计算异常） - 连接条件里补上
t2.amount > t1.amount，确保上月
构造 YYYYMM 整数月份字段避免跨年陷阱
别依赖 DATE_ADD(order_date, INTERVAL -1 MONTH) 做连接，MySQL/PostgreSQL 对跨年减月的处理不一致，且索引失效。更稳的方式是预计算一个整数型月份键：
SELECT YEAR(order_date) * 100 + MONTH(order_date) AS ym, SUM(amount) AS amount FROM orders GROUP BY YEAR(order_date), MONTH(order_date)
这样 ym 是 202301、202302…202401，自关联时直接写 t2.ym = t1.ym + 1，语义清晰、可索引、无时区/闰年干扰。
- 如果原始表没有索引，记得在
(YEAR(order_date), MONTH(order_date))或计算列ym上建索引 - SQL Server 用户可用
FORMAT(order_date, 'yyyyMM')转字符串，但比较时需转回 int，不如直接算整数高效
识别“连续”需要至少两轮增长，不是单次上涨
查出所有“t1 月
简单场景（只查长度 ≥3 的连续段）可嵌套一次自关联：
SELECT t1.ym AS start_ym, t2.ym, t3.ym AS end_ym FROM monthly_sum t1 JOIN monthly_sum t2 ON t2.ym = t1.ym + 1 AND t2.amount > t1.amount JOIN monthly_sum t3 ON t3.ym = t2.ym + 1 AND t3.amount > t2.amount
- 每多一月连续，就要多一层
JOIN，三层对应三连涨（含起点共三个月） - 想动态支持 N 连续？得用递归 CTE（PostgreSQL/SQL Server）或变量模拟（MySQL 8.0+），但可读性和维护成本陡增
- 注意 NULL 处理：某月无数据会导致链路中断，
LEFT JOIN会引入空值，必须用IS NOT NULL过滤
性能差？大概率卡在没聚合就自关联
最常被忽略的性能杀手：跳过月度聚合，直接在原始订单表上 JOIN orders o1 ON ... o1.order_date 的上月 = o2.order_date。哪怕只有 10 万行订单，自关联后可能膨胀到千万级中间结果。
- 务必确认执行计划中
EXPLAIN显示的是对聚合后的小结果集（几百行）做连接，而不是对原始大表 - 如果业务允许近似，可加
WHERE order_date >= '2023-01-01'限定范围，避免扫描全表 - 某些场景下，用窗口函数
LAG(amount) OVER (ORDER BY ym)替代自关联更简洁，但要注意 LAG 不会自动跳过缺失月份——202305 和 202307 相邻时，LAG 返回的是 202305 的值，而非空，需额外判断ym = LAG(ym)+1
连续性校验永远绕不开月份完整性检查。如果某月订单为 0，它是否该参与“连续”判定？业务定义不清时，代码里硬编码的 +1 就会悄悄漏掉断点。
