LAG()和窗口函数判断趋势的本质是用当前值与前一行比较生成trend（1涨、-1跌、0平），再通过trend变化分组；需明确相等值处理策略（通常排除0以保单调性），浮点数比较应使用精度容差，且所有业务定义须在LAG前确定。
用LAG()和窗口函数判断相邻行趋势
连续上涨或下跌的本质是：当前值与前一行比较后，趋势（>、LAG() 拿上一行的值，再用 CASE WHEN 标记涨跌状态，是最稳的起点。
常见错误是用自连接或子查询模拟“上一行”，性能差还容易漏边界；或者只比大小不标记方向，后续无法分组连续段。
- 必须配合
ORDER BY显式指定排序逻辑（比如按date或id），否则LAG()结果无意义 - 涨跌判断建议统一用数值编码：1 表示涨（
current > prev），-1 表示跌（current ），0 表示平——避免字符串比较影响后续计算 - 注意 NULL 处理：
LAG()在首行返回 NULL，需用COALESCE()或WHERE prev IS NOT NULL过滤，否则 0 值参与比较会出错
用行号差识别“连续段”
标记完每行涨跌方向后，真正的难点是把相同方向的相邻行聚成一组。不能直接 GROUP BY trend——那会把所有上涨全归一堆。得构造一个“趋势分组ID”，核心技巧是：用全局行号减去按趋势分组的行号。
这个差值在趋势不变时恒定，一旦趋势翻转就跳变，天然形成连续段标识。
- 写法示例：
ROW_NUMBER() OVER (ORDER BY date) - ROW_NUMBER() OVER (PARTITION BY trend ORDER BY date) - 别名它为
grp_id，之后GROUP BY grp_id, trend就能拿到每一段的起止、长度等信息 - 某些数据库（如 MySQL 8.0+、PostgreSQL、SQL Server）支持该写法；旧版 MySQL 需用变量模拟，但并发下不可靠
查出连续3天及以上上涨的记录
这是最常被问的实际需求。重点不是“怎么标涨跌”，而是“怎么筛连续长度 ≥3 的段”。必须先完成前两步（标趋势、造 grp_id），再在外层统计段长。
典型错误是试图用 LEAD() 看后两行——代码冗长且无法泛化到“连续 N 天”。
- 在子查询中算出每段的
COUNT(*) AS len，再HAVING len >= 3 - 若需返回原始明细行，用
IN或JOIN回连原表，条件是grp_id和trend匹配 - 性能敏感场景下，避免在大表上多次扫描：把趋势标记、分组、过滤尽量写在一个 CTE 里，减少中间结果集
处理相等值（平台期）的取舍
真实数据常有连续相等值，是否算作“连续上涨/下跌”的一部分？SQL 本身不定义业务语义，但实现时必须明确策略。
多数业务场景要求严格单调（即不允许等于），所以 trend 字段里 0 应被排除或单独处理。混入 0 会导致 grp_id 错误合并段。
- 推荐做法：在趋势标记阶段就过滤掉
trend = 0的行，或将其设为NULL并在后续PARTITION BY中忽略 - 如果业务允许“上涨包含持平”，则需改写趋势逻辑为
CASE WHEN current >= prev THEN 1 ELSE -1 END，但必须同步调整下游对“连续”的定义 - 特别注意浮点数比较：用
ABS(current - prev) > 0.001替代!=，避免精度误差误判
连续性判断真正麻烦的从来不是语法，而是如何定义“连续”——涨跌方向、相等值、时间空缺、数据缺失，每个都得在 LAG() 之前就想清楚。
