窗口函数默认不识别业务时间断点，需用LAG()计算时间差并生成分组标识（如segment_id）来切分逻辑连续段，再通过PARTITION BY实现断点隔离；RANGE BETWEEN仅控制物理时间范围，无法解决逻辑连续性问题。
窗口函数默认不识别业务时间断点
SQL 窗口函数（如 ROW_NUMBER()、SUM() OVER ()）按 ORDER BY 子句线性排序，把时间戳当普通数值排。它不会主动感知“节假日”“系统停机”“数据缺失超过 24 小时”这类业务断点——哪怕你用 created_at 排序，中间缺了三天数据，窗口照样把第 4 天的行当作第 1 天的“紧邻后续”。结果就是累计值跳变、排名错位、移动平均失真。
用 LAG() + 时间差判断断点并生成分组标识
真正可行的做法是：先识别断点，再用断点切分窗口。核心是构造一个稳定的分组列（比如 session_id 或 period_seq），让同一连续时段内的行共享相同值。
常见操作步骤：
- 用
LAG(created_at) OVER (ORDER BY created_at)取上一行时间 - 用
EXTRACT(EPOCH FROM (created_at - lag_time)) / 3600（PostgreSQL）或TIMESTAMPDIFF(HOUR, lag_time, created_at)（MySQL）算小时级间隔 - 当间隔 > 阈值（如 2 小时），标记为新断点：
CASE WHEN hours_gap > 2 THEN 1 ELSE 0 END - 对断点标记做累计求和：
SUM(is_break) OVER (ORDER BY created_at)→ 得到每个连续段的唯一 ID
之后所有窗口计算都加 PARTITION BY segment_id，就自然隔离了断点。
RANGE BETWEEN 不能替代断点处理
有人尝试用 RANGE BETWEEN INTERVAL '24 hours' PRECEDING AND CURRENT ROW 做滑动时间窗，但这只控制“物理时间范围”，不解决“逻辑连续性”问题。例如某天无数据，第二天突然涌入 100 条，这个 RANGE 窗会包含前一天空档，但无法跳过它去连接更早的有效数据段；更关键的是，RANGE 对非时间类型或精度不一致的时间列（如 TIMESTAMP WITHOUT TIME ZONE 在跨时区场景）行为不稳定，PostgreSQL 甚至要求 ORDER BY 列必须是单调的，否则报错 WINDOW RANGE NOT SUPPORTED WITH NON-MONOTONIC ORDER BY。
真实场景中阈值和时区必须显式声明
断点判断不是纯技术活，依赖业务定义。比如“用户一次会话中断多久算新会话”在不同系统里可能是 30 分钟（Web）、5 分钟（IoT 心跳）、72 小时（离线填报）。忽略这点直接套用 1 小时阈值，结果必然偏差。
另一个高频坑是时区：若 created_at 是 TIMESTAMP WITH TIME ZONE，但 LAG() 计算未统一时区（如部分数据存为 UTC、部分为本地时间），时间差会错乱。务必在计算前强制转换：created_at AT TIME ZONE 'UTC' 或 CONVERT_TZ(created_at, '+08:00', '+00:00')。
断点逻辑一旦写进视图或物化表，后续所有基于它的聚合都要复用同一套 segment_id，否则各层口径不一致，排查成本远高于初期多写两行转换逻辑。
