用LAG()识别连续增长需先按完整年月排序并聚合，再用双ROW_NUMBER()差值分组；季度统计须独立聚合，不可复用月度逻辑；注意NULL处理和索引优化。
用 LAG() 和窗口函数识别连续增长的月份
连续增长不是简单求和，而是判断「当月销售额 > 上月销售额」是否在时间上形成不间断的序列。核心是用 LAG() 取出上一行（按日期排序）的销售额，再用布尔标记增长状态。
常见错误是直接对原始表 GROUP BY YEAR(订单日期), MONTH(订单日期) 后再比较——这会丢失行序，LAG() 必须作用于已按时间排序的明细行（不是聚合后结果）。
实操建议：
- 先按
订单日期（或销售日期）升序排列所有销售记录，确保LAG()拿到的是逻辑上的“上个月”而非随机前一行 - 用
LAG(销售额) OVER (ORDER BY 订单日期)得到上期值，再用CASE WHEN 销售额 > LAG(...) THEN 1 ELSE 0 END标记是否增长 - 注意：若某月有多笔订单，必须先按月聚合（
SUM(销售额)），再对月度汇总结果做LAG()，否则单笔订单的波动会干扰趋势判断
用 ROW_NUMBER() 构建连续段分组
仅标记“是否增长”还不够，要统计“连续多少个月”，就得把相邻的 1 归为同一段。典型做法是用两个 ROW_NUMBER() 相减构造分组 ID：一个按全局顺序编号，一个按“增长标记=1”的子序列编号，差值相同的即为同一连续段。
容易踩的坑是忽略“断点重置”——一旦出现不增长（标记为 0），后续的增长必须从新段开始计数，不能延续之前编号。
示例关键逻辑（以 PostgreSQL/MySQL 8.0+ 为例）：
SELECT
年月,
销售额,
连续月数
FROM (
SELECT
年月,
销售额,
ROW_NUMBER() OVER (ORDER BY 年月)
- ROW_NUMBER() OVER (PARTITION BY grp ORDER BY 年月) + 1 AS 连续月数
FROM (
SELECT
DATE_FORMAT(订单日期, '%Y-%m') AS 年月,
SUM(销售额) AS 销售额,
SUM(销售额) > LAG(SUM(销售额)) OVER (ORDER BY DATE_FORMAT(订单日期, '%Y-%m')) AS is_up,
SUM(CASE WHEN is_up THEN 0 ELSE 1 END)
OVER (ORDER BY DATE_FORMAT(订单日期, '%Y-%m')) AS grp
FROM 销售表
GROUP BY DATE_FORMAT(订单日期, '%Y-%m')
) t1
) t2注意：grp 是用累计“非增长月”次数构造的分组键，比直接嵌套更稳定；DATE_FORMAT 在 SQL Server 中需换为 FORMAT(订单日期, 'yyyy-MM')，SQLite 用 strftime('%Y-%m', 订单日期)。
季度统计时别直接套用月度逻辑
季度连续增长 ≠ 把三个月份拼成一个单位再跑一遍月度逻辑。因为“Q1→Q2 增长”要求 Q2 总额 > Q1 总额，但中间若出现某月下滑，只要季度总和仍上涨，它仍是连续季度增长的一部分。
所以季度处理必须独立聚合：先用 YEAR(订单日期) * 10 + QUARTER(订单日期) 或 CONCAT(YEAR(订单日期), '-Q', QUARTER(订单日期)) 生成季度标识，再对季度做 LAG() 和分组，不能复用月度计算出的“连续月数”字段。
性能提示：
- 月度和季度统计建议分别走两个查询，或用 CTE 预先聚合，避免在同一个窗口函数里反复解析日期
- 如果数据量大，务必在
订单日期字段建索引，否则ORDER BY窗口排序代价极高 -
QUARTER()函数在不同数据库行为一致，但 SQLite 不原生支持，需用(strftime('%m', 订单日期) + 2) / 3手动算
空值与边界情况必须显式处理
LAG() 对首行返回 NULL，直接参与比较会导致整行被过滤或结果为 UNKNOWN。常见错误是写成 WHERE 销售额 > LAG(...)，漏掉首月且让 NULL 传播进后续计算。
正确做法是始终用 COALESCE(LAG(...), 0) 或 LAG(...) IS NOT NULL AND 销售额 > LAG(...) 显式兜底。
另一个易忽略点：跨年连续（如 2023-12 → 2024-01）在字符串排序下天然成立，但若用 MONTH(订单日期) 单独排序就会断裂。必须用完整年月（如 2023-12）作为排序键，不能只依赖月份数字。
