lag()识别状态变化点需按业务主键partition by、用is distinct from安全比较null、结合sum() over累计构造连续段id，才能准确分组聚合。
用 LAG() 识别状态变化点
连续状态变更的核心是“和上一行比较”，LAG() 是最直接的工具。它能取出按业务时间（比如 event_time）排序后的前一行状态，再用 CASE WHEN 判断是否变化。
注意：必须明确指定 ORDER BY，否则结果不可靠；如果存在同一时间多条记录，还需加入唯一排序字段（如 id）避免窗口内顺序不确定。
-
LAG(status) OVER (PARTITION BY user_id ORDER BY event_time, id)—— 按用户分组、时间+主键排序，安全取前值 - 别直接用
LAG(status)不带PARTITION BY，跨用户混序会导致标记错乱 - 如果
status是 NULL，status != LAG(status)会返回 NULL 而非 TRUE，要用IS DISTINCT FROM（PostgreSQL）或COALESCE(status, '') != COALESCE(LAG(status), '')（兼容 MySQL/SQL Server）
用 SUM() 累计生成连续段 ID
状态变化点本身只是布尔标记，要“分组连续段”，得把每次变化当作新段起点，用累计和构造段 ID。这是关键一步，跳过就只能标出变化行，无法聚合连续区间。
SUM() 在窗口中不加 ROWS BETWEEN 时默认是 ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，正好满足递增累加需求。
- 先用
CASE WHEN status != LAG(status) THEN 1 ELSE 0 END生成变化标志列is_new_segment - 再用
SUM(is_new_segment) OVER (PARTITION BY user_id ORDER BY event_time, id)得到每个记录所属的连续段编号 - MySQL 8.0+、PostgreSQL、SQL Server 都支持；但旧版 MySQL（
用 MIN()/MAX() 提取每段的起止时间
有了段 ID，就可以按 user_id 和段 ID 二次分组，提取每段的最早/最晚时间，完成“连续状态区间”的结构化输出。
注意：这里不是窗口函数，而是普通聚合，所以必须 GROUP BY user_id, segment_id，且不能漏掉 status 字段——它在段内恒定，可直接 MAX(status) 或 MIN(status) 取值。
- 写法示例：
SELECT user_id, MIN(event_time) AS start_time, MAX(event_time) AS end_time, MAX(status) AS status FROM (...) GROUP BY user_id, segment_id - 如果原始数据有重复时间戳但不同状态，说明业务逻辑本身冲突，窗口函数会照常分段，但结果可能不符合业务预期——得先清洗数据
- 想保留原始明细行并附带段信息？那就别
GROUP BY，改用MIN(event_time) OVER (PARTITION BY user_id, segment_id)等分析函数
常见错误：时间断点没对齐导致“伪连续”
业务上“连续状态”通常要求时间无缝衔接（比如 A 状态结束时间 = B 状态开始时间），但原始数据往往只存开始时间，或存在采集延迟、补录等 gap。直接按状态分组会把中间空档也当成连续段。
解决办法不是硬调窗口函数，而是前置时间对齐逻辑：先用 LEAD(event_time) OVER (...) 计算下一条的开始时间，再和当前行的 end_time（或隐含的“有效期至”）比对，过滤掉间隔 > 允许阈值（如 5 分钟）的断点。
- 没有显式
end_time字段？可约定“当前行生效至下一行开始前 1 秒”，用LEAD(event_time) OVER (...) - INTERVAL '1 SECOND'构造 - 用
LAG()和LEAD()同时判断前后间隙，比单靠状态值更贴近真实业务连续性 - 这个步骤容易被跳过，结果看似分段成功，实际把两个孤立事件误连成一段——查问题时得倒推回时间对齐环节
