检测时间序列断点需分三类：①用lag()获取前后行计算跳变；②用滑动窗口聚合识别局部偏离；③用时间桶+left join+having识别空缺。
用LAG() + 聚合函数检测相邻时间点的突变
时间序列断点往往表现为相邻采样点之间的值跳变（如传感器掉线后恢复、设备重启、人为误操作）。单纯靠 AVG() 或 MAX() 无法定位断点位置，必须结合行间比较。最直接的方式是用 LAG() 获取上一行时间戳和数值，再在外部用聚合函数统计跳变频次或标记异常区间。
常见错误是把 LAG() 放在聚合之后——它必须作用于原始时序行，不能放在 GROUP BY 后的 SELECT 中直接参与聚合计算。
- 先用 CTE 或子查询生成带偏移字段的中间结果：
LAG(timestamp) OVER (ORDER BY timestamp)和LAG(value) OVER (ORDER BY timestamp) - 再计算时间差和值差：
EXTRACT(EPOCH FROM (timestamp - prev_ts))和ABS(value - prev_value) - 最后用
COUNT(*) FILTER (WHERE time_gap > 60 OR value_gap > 100)快速统计断点数量（PostgreSQL）或用SUM(CASE WHEN ... THEN 1 ELSE 0 END)（通用写法）
用窗口聚合识别局部偏离而非全局异常
固定阈值（如 value > 100）在长周期数据中极易失效：白天温度高、夜间低，统一阈值会漏判或误报。真正有效的断点识别依赖“上下文”，也就是以当前行为中心的局部窗口统计。
例如，用 AVG(value) OVER (ORDER BY timestamp ROWS BETWEEN 5 PRECEDING AND 5 FOLLOWING) 计算每个点前后共11个点的滑动均值，再比对当前值是否超出 ±2 * STDDEV()。这比单用 AVG() 全局聚合更敏感，也比孤立调用 STDDEV() 更稳定。
- 注意帧定义：
ROWS BETWEEN比RANGE BETWEEN更可控，避免因时间戳重复导致窗口扩大 - MySQL 8.0+ 和 PostgreSQL 支持该语法；SQLite 需手动模拟窗口（不推荐）
- 若时间间隔不均匀，优先用
INTERVAL '5 minutes' PRECEDING（PostgreSQL）或timestamp >= LAG(timestamp) + INTERVAL 5 MINUTE辅助过滤
GROUP BY 时间桶 + HAVING 筛选空桶或稀疏桶
断点另一种表现是“数据缺失”——某段时间内完全无上报。这时聚合函数不是用来算数值，而是暴露空缺本身。
核心思路：按固定粒度（如5分钟）分桶，用 COUNT(*) 统计每桶记录数，再用 HAVING COUNT(*) = 0 找空桶。但要注意，GROUP BY 本身不会生成空桶，必须用时间维度表 LEFT JOIN 补全，否则空桶直接消失。
- 生成连续时间桶可用递归 CTE（PostgreSQL/SQL Server）或日历表；MySQL 可用
seq_0_to_1000类辅助表 HAVING COUNT(*) 比 <code>= 0更实用——允许少量丢包，但低于阈值即告警- 避免在
WHERE中过滤时间范围过早，否则补全后的空桶会被剪掉
为什么不能只靠标准差或IQR做断点判断
标准差（STDDEV()）和四分位距（PERCENTILE_CONT(0.75) - PERCENTILE_CONT(0.25)）适合识别整体分布中的离群点，但对时间序列断点几乎无效——断点是局部结构变化，不是全局统计异常。
比如某设备凌晨3点整集体掉线2小时，所有值都为0，此时 STDDEV() 反而变小；又或者某传感器持续漂移，缓慢超限，IQR 完全无法捕捉。
- 断点本质是“一阶导数突变”或“二阶导数符号翻转”，需结合时间差、值差、窗口斜率等指标
- 聚合函数在这里只是工具，关键在如何组织计算顺序：先偏移 → 再差分 → 最后窗口聚合，三步缺一不可
- 真正容易被忽略的是时间精度对齐：数据库里
TIMESTAMP可能带毫秒，但业务断点只关心分钟级，务必先date_trunc('minute', ts)再处理
