窗口函数ORDER BY必须用非空时间字段+二级排序（如time, id），字符串时间需先转原生类型；LAG/LEAD无法按时间距离找邻居，需自连接或ARRAY_AGG；RANGE BETWEEN支持时间范围滑动但要求索引覆盖；PARTITION后仍需外层ORDER BY保证结果顺序。

窗口函数怎么填 ORDER BY 才不崩？ 不规则时间序列最常踩的坑，就是直接拿 ORDER BY time 但没处理重复时间戳或空值。MySQL 8.0+、PostgreSQL、ClickHouse 都会报错或返回非预期结果——比如 LAG() 拿到上一行，但那行根本不是“上一个有效时间点”。

• 时间字段必须 NOT NULL，否则 ORDER BY time 会让 ROW_NUMBER() 或 LEAD() 把 NULL 排在最前/最后，逻辑全乱
• 有重复时间戳时，必须加二级排序，例如 ORDER BY time, id 或 ORDER BY time, created_at，否则窗口行为不可复现
• 如果原始时间是字符串（如 '2024-03-15 10:22'），先用 TO_TIMESTAMP()（PostgreSQL）或 STR_TO_DATE()（MySQL）转成原生时间类型，别在窗口里硬比字符串

SELECT 
  time,
  value,
  LAG(value) OVER (ORDER BY time, id) AS prev_value
FROM sensor_data 
WHERE time IS NOT NULL;

LAG() 和 LEAD() 怎么对齐“最近的有效时间点”？ 原始数据缺秒级精度、设备上报延迟、批量补录都会导致时间间隔不均。这时 LAG(value) OVER (ORDER BY time) 只能取“物理上相邻的行”，不是“时间上最近的前一个点”。

• 真正要的是“上一条发生在当前时间之前、且时间差最小的记录”，这得靠自连接 + 子查询，或者用 ARRAY_AGG() + FILTER（PostgreSQL）；窗口函数本身做不到“按时间距离找邻居”
• 如果只是想跳过缺失时段做线性插值，可以先用 GENERATE_SERIES()（PostgreSQL）或递归 CTE 补全时间轴，再左连接原始数据，最后用 COALESCE(LEAD(), LAG()) 填空
• 注意：MySQL 不支持 ARRAY_AGG 或 GENERATE_SERIES，得用变量模拟或应用层补点

用 ROWS BETWEEN 还是 RANGE BETWEEN？ 这是决定“滑动窗口是否认时间值”的关键开关。

• ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING：数行号，不管时间差多大。适合固定步长平滑，但对不规则序列毫无意义
• RANGE BETWEEN INTERVAL '5 minutes' PRECEDING AND CURRENT ROW：按时间值算范围（PostgreSQL / Snowflake 支持；MySQL 8.0 仅支持 UNBOUNDED 或数字偏移）。这才是处理不规则序列的正确姿势
• 但注意：RANGE 要求 ORDER BY 字段是单调可比较的数值或时间类型，且索引必须覆盖该字段，否则性能断崖式下跌
• SQL Server 和旧版 MySQL 不支持 INTERVAL 形式的 RANGE，只能退化为 ROWS + 预排序 + 应用层校验

为什么 OVER (PARTITION BY device_id ORDER BY time) 后还是乱序？ 常见现象：分组后 ROW_NUMBER() 显示 1,2,3…，但查出来的时间列却是 2024-03-15 10:00, 2024-03-15 09:58, 2024-03-15 10:02 ——说明排序只作用于窗口计算，不影响最终结果集顺序。

• 窗口函数不改变输出顺序，SELECT 最终顺序仍由外层 ORDER BY 决定
• 必须显式写 ORDER BY device_id, time 在语句末尾，否则看执行计划或数据库版本不同，结果可能每次都不一样
• 更隐蔽的坑：如果 time 是 TIMESTAMP WITH TIME ZONE，而客户端时区设置不一致，ORDER BY 表面有序，实际跨时区比较失效

时间精度、空值、分区与排序的耦合关系，比看起来紧得多。少一个 NOT NULL 约束，或漏掉外层 ORDER BY，清洗结果就可能在线上静默出错。