直接用avg()窗口函数做滑动平均易出错，因其会将毛刺异常值直接纳入计算、依赖默认行序导致时间对齐错误、未清洗伪无效值（如0或-999）、mysql不支持range帧造成时间跨度不稳定。
为什么直接用 AVG() 窗口函数做滑动平均容易出错？
传感器数据常含突发毛刺，用 AVG() 配合 ROWS BETWEEN 2 PRECEDING AND 2 FOLLOWING 做 5 点滑动平均看似合理，但实际会把异常值直接拉进均值计算——比如某点温度突跳到 120°C（真实应为 22°C），它会污染前后共 5 个窗口，导致平滑后曲线仍带明显畸变。
- 窗口范围必须严格对齐时间戳，不能依赖默认行序；传感器数据常有采样间隔不均、乱序或缺失，
ORDER BY timestamp是必需的，但若 timestamp 有重复，需加二级排序（如ORDER BY timestamp, sensor_id）避免非确定性结果 -
AVG()对NULL自动忽略，但若原始数据用 0 或 -999 表示无效值，得先用CASE WHEN value 清洗，否则 0 会被计入均值 - PostgreSQL 和 ClickHouse 支持
FRAME CLUSTER，但 MySQL 8.0 不支持RANGE帧按时间间隔定义（如RANGE BETWEEN INTERVAL '2 seconds' PRECEDING AND CURRENT ROW），只能退化为ROWS，此时需先用LAG()补齐缺失时间点，否则窗口覆盖实际时间跨度不稳定
用 MEDIAN() 替代 AVG() 能解决毛刺问题吗？
不能直接用——标准 SQL 没有内置 MEDIAN() 窗口函数。PostgreSQL 可通过 PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY value) 模拟，但这是聚合函数，不能直接用于窗口帧；必须嵌套在 ROWS 窗口内配合子查询或 CTE，性能开销显著增大。
- 更可行的是用
ARRAY_AGG(value) OVER (...)收集窗口内值，再用UNNEST+ORDER BY+LIMIT 1 OFFSET n手动取中位数，但仅适用于小窗口（如 ≤ 11 点），否则内存和 CPU 消耗陡增 - SQLite 和 MySQL 完全不支持数组聚合，此时应改用三步法：先用
ROW_NUMBER()标记窗口内排序位置，再用条件聚合拼出中位数逻辑，例如对 5 点窗口，取MAX(CASE WHEN rn = 3 THEN value END) - 注意：中位数对偶数长度窗口需手动处理上下中位数平均，而传感器数据通常采样率固定，建议统一用奇数窗口长度（如 5、7）规避该分支
如何让窗口滤波响应真实物理变化，而非滞后失真？
滑动窗口天然带来延迟——5 点窗口中位数会使输出比输入滞后 2 个采样周期。对实时监控场景，这可能导致告警延迟。解决方法不是缩小窗口（降噪能力下降），而是调整帧定义：
- 用
ROWS BETWEEN CURRENT ROW AND 4 FOLLOWING实现“向前看”滤波，牺牲部分实时性换取相位对齐（输出对应当前时刻，但依赖未来 4 点数据） - 若无法获取未来数据，改用指数加权移动平均（EWMA）近似：用递归 CTE 或应用层计算
smoothed = alpha <em> raw + (1-alpha) </em> smoothed_prev，SQL 本身不支持状态保持，需在应用侧维护上一周期smoothed值并传入下一次查询 - 时间敏感场景（如电机振动分析）应优先用
RANGE BETWEEN INTERVAL '100 milliseconds' PRECEDING AND CURRENT ROW，但需确认数据库支持：ClickHouse 支持，PostgreSQL 14+ 支持，MySQL 仍不支持
降噪后如何验证滤波是否过度平滑？
不能只看曲线变“顺”，要量化评估：用原始数据与滤波后数据计算 STDDEV() 差值，若下降超过 60%，大概率已抹掉有效瞬态特征（如设备启停冲击）。
- 在关键事件段（如已知开关机时刻）截取前后 1 秒数据，对比滤波前后峰值幅度衰减比例；若 > 30%，说明窗口过大或中位数阶数过高
- 加入残差分析：计算
raw - smoothed，对其做直方图，理想情况应近似正态分布且均值接近 0；若出现长尾偏移，说明滤波器存在系统性偏差（如传感器零点漂移未校准） - 最容易被忽略的是时间对齐误差：滤波后数据的时间戳应取窗口中心点，而非默认的
CURRENT ROW时间戳，否则相位偏移会导致频谱分析失真
窗口滤波不是开箱即用的黑盒，每个参数都绑定具体传感器特性、采样率和业务容忍度。调参前务必用已知工况的标定数据跑对比，而不是靠肉眼判断“看起来更平滑”。
