直接用 row_number() 按 device_id 分组、fault_time 升序编号，是计算故障间隔的基础；必须写 partition by device_id，且 fault_time 需为 timestamp 类型，重复时间需加唯一字段保序；lag() 提取上一次故障时间，窗口定义须与 row_number() 一致；首次故障 prev_fault 为 null，应 where prev_fault is not null 过滤；索引 (device_id, fault_time) 可显著提升性能。
窗口函数怎么给故障时间排序并编号
直接用 ROW_NUMBER() 按设备 ID 分组、按故障时间升序编号，是后续计算间隔的基础。别用 RANK() 或 DENSE_RANK()——它们对相同时间会分配相同序号，导致错位；而故障时间极少完全重复，ROW_NUMBER() 更稳妥。
常见错误：漏写 PARTITION BY device_id，结果把所有设备混在一起排序，算出来的“上一次故障”可能来自别的设备。
SELECT device_id, fault_time, ROW_NUMBER() OVER (PARTITION BY device_id ORDER BY fault_time) AS rn- 确保
fault_time是TIMESTAMP或可比较的日期类型；字符串格式如'2024-03-15 08:22:10'可能因排序规则出错 - 如果原始数据含重复时间且必须保留，先用
ORDER BY fault_time, id（加主键或唯一字段）保证排序稳定
用 LAG() 提取上一次故障时间
LAG() 是计算间隔最直接的窗口函数，它从当前行向上偏移指定行数取值。关键在于偏移量设为 1，并严格匹配 PARTITION BY 和 ORDER BY 条件，否则会跨设备取值。
典型现象：某设备第一次故障时，LAG(fault_time) 返回 NULL——这是正常行为，不是 bug，表示无前序故障。
-
LAG(fault_time) OVER (PARTITION BY device_id ORDER BY fault_time)必须和ROW_NUMBER()的窗口定义完全一致 - 若需单位统一（如分钟），直接用
EXTRACT(EPOCH FROM (fault_time - prev_fault)) / 60（PostgreSQL）或TIMESTAMPDIFF(MINUTE, prev_fault, fault_time)（MySQL） - SQL Server 用户注意：
LAG()在 2012+ 版本才支持，旧版得用自关联或 CTE 模拟
间隔计算后如何过滤和处理 NULL
第一次故障必然没有“上一次”，对应间隔为 NULL。实际分析中通常跳过这些行，但得明确是主动过滤而非数据缺失。
容易踩的坑：用 WHERE interval_minutes > 0 会意外剔除间隔恰好为 0 的情况（比如同秒内两次故障），应优先用 WHERE prev_fault IS NOT NULL。
- 建议在子查询或 CTE 中先算出
prev_fault，再在外层WHERE prev_fault IS NOT NULL - 若业务允许“首次故障也参与统计”，可用
COALESCE(LAG(...), fault_time)做默认值，但语义已变，需团队对齐 - 间隔为负数？说明
fault_time有乱序或脏数据，必须前置校验，不能靠窗口函数兜底
性能与索引怎么配合窗口函数
窗口函数本身不走索引，但 ORDER BY 字段如果有索引，排序阶段能显著加速。尤其当设备量大、单设备故障频次高时，没索引会导致全表扫描+临时排序。
一个常被忽略的事实：复合索引 (device_id, fault_time) 能同时支撑 PARTITION BY 和 ORDER BY，比单列索引更有效。
- 建索引命令示例：
CREATE INDEX idx_device_fault ON faults (device_id, fault_time); - MySQL 8.0+ 和 PostgreSQL 支持索引覆盖窗口排序，但 SQLite 不支持，大数据量下慎用
- 如果表有千万级记录，先
ANALYZE TABLE faults;（MySQL）或VACUUM ANALYZE;（PG），让优化器知道数据分布
实际跑起来才发现，fault_time 字段的精度和时区一致性，比窗口函数语法本身更容易引发间隔计算偏差。
