核心是用LAG()获取前值，CASE标记增长，SUM(1-is_up)构造连续分组ID，再按ID聚合判断连续期数；需处理空值、时间重复、排序稳定性及数据库兼容性问题。
怎么用 LAG() 和 CASE 判断连续增长
核心是把“当前值 > 前一个值”这个逻辑，逐行打上标记，再看标记是否连续出现。不能直接对原始值做 ORDER BY 后求差——那样看不出“连续性”，只看出“单次变化”。
实操建议：
- 先用
LAG(value) OVER (ORDER BY time)拿到前一行的值，别漏ORDER BY，否则窗口无序，结果不可靠 - 用
CASE WHEN value > LAG(value) THEN 1 ELSE 0 END生成增长标记（is_up） - 关键一步：对
is_up做“连续分组”——用SUM(1 - is_up) OVER (ORDER BY time)构造分组 ID，这是识别连续段最稳的方式 - 最后按分组 ID 聚合，
COUNT(*) >= 3就是你要的“连续增长 3 期”
ROW_NUMBER() 和 RANK() 在连续判断里为什么不能乱用
它们只反映排序位置，不反映值的变化关系。比如数据有重复值或跳变时，ROW_NUMBER() 仍会递增，但实际趋势可能中断。
常见错误现象：
- 用
ROW_NUMBER() OVER (ORDER BY value)当趋势依据 → 实际是按大小排序，不是按时间顺序，完全偏离业务含义 - 拿
RANK()差值判断“增长步长” →RANK()对相同值给同名次，差值为 0，但业务上可能允许相等（即非严格增长），此时逻辑崩坏 - 没意识到
ROW_NUMBER()依赖ORDER BY字段唯一性 → 时间字段若有毫秒级重复，排序不稳定，导致LAG()取错行
遇到重复时间戳或空值怎么办
真实日志、埋点、IoT 数据常有时间重复或 NULL 值，直接套标准窗口逻辑会出错：空值让 LAG() 返回 NULL，比较表达式整体为 UNKNOWN，CASE 默认进 ELSE 分支，误判为“未增长”。
使用场景和应对：
- 时间重复：加二级排序，如
ORDER BY time, id，确保窗口内行序确定 -
value为空：在CASE前加WHERE value IS NOT NULL过滤，或用COALESCE(value, -999999)填充（注意填充值不能干扰增长判断） - 首行
LAG()必为NULL→ 显式写WHEN value > LAG(value) OVER (...) THEN 1 ELSE 0 END，不要依赖隐式布尔转换
性能和兼容性要注意的点
大表跑连续趋势识别容易慢，瓶颈通常不在 CASE，而在窗口函数的排序和帧计算。不同数据库优化程度差异大。
参数差异与影响：
-
PostgreSQL支持ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW显式指定帧，但对“连续段分组”无帮助；反而用SUM()累计方式更高效 -
MySQL 8.0+窗口函数可用，但子查询嵌套过深易触发临时表，建议把LAG()结果先存为 CTE，再二次加工 -
Spark SQL对ORDER BY字段要求强分区有序，若源数据未按时间排序，需先DISTRIBUTE BY+SORT BY，否则LAG()跨分区失效 - 别在
WHERE里直接写LAG() > value—— 大多数引擎不支持窗口函数出现在WHERE，得用外层过滤
连续趋势的本质不是数学序列，而是带状态的流式判断。一旦中间断一环（比如某天数据缺失、值异常归零），整个连续段就重置。这点容易被忽略，但恰恰决定结果是否可信。
