窗口函数不可被group by替代，因其保留原始行数并支持行级时序计算；group by会压缩数据、丢失时间戳，无法实现滑动窗口、跨行比较或滚动统计等时序分析必需功能。
因为时序数据天然具备“按时间排序+按设备/指标分组”的二维结构，而窗口函数是唯一能在保留原始时间线的前提下，直接在行级完成滚动计算、跨行比较、分组累计的SQL机制。
为什么不能用 GROUP BY 替代 PARTITION BY + ORDER BY
GROUP BY 会压缩行数，丢失每条时序点的时间戳和原始字段；而时序分析必须保留每个采样点——比如查“每个传感器最近3次温度的平均值”，结果必须是一行一时间点，不是一行一传感器。
- 用
GROUP BY sensor_id只能算出每个传感器的全局均值，无法体现时间局部性 - 想实现滑动窗口，就得套子查询或自连接，语句爆炸且执行计划退化为嵌套循环
- 某些场景（如同比环比）需同时引用当前行、前N行、同周期去年行，
GROUP BY完全无法表达
ORDER BY 在窗口定义里不是为了“最终排序”，而是定义计算逻辑
写 ROW_NUMBER() OVER (PARTITION BY device_id ORDER BY ts)，这个 ORDER BY ts 不是让结果按时间排好给你看，而是告诉数据库：“请按时间顺序组织窗口内行，以便正确取第一行、累加、或调用 LAG()”。
- 漏写
ORDER BY：对LAG()、SUM() OVER (ROWS BETWEEN ...)等函数会报错或返回不可控结果 - 只写
ORDER BY ts但ts有重复（如毫秒级精度下多设备同时上报），会导致排序不稳定，ROW_NUMBER()每次执行结果可能不同 - 正确做法是补唯一字段：
ORDER BY ts, metric_id或ORDER BY ts, event_id
ROWS BETWEEN 比 RANGE BETWEEN 更适合时序场景
时序分析绝大多数需求是“最近N个点”或“过去M分钟”，对应物理行偏移；而 RANGE BETWEEN 按值范围匹配，在时间字段存在大量重复或精度不一致时极易失控。
-
ROWS BETWEEN 2 PRECEDING AND CURRENT ROW：稳定取当前行及前两行，性能好、结果可预期 -
RANGE BETWEEN INTERVAL '5 minutes' PRECEDING AND CURRENT ROW：若时间字段被截断为秒级，或存在批量写入导致数百点同秒，窗口可能瞬间膨胀到上千行，OOM 风险陡增 - 国产时序数据库在替换过程中，常因
RANGE行为与旧库不一致（如毫秒处理逻辑差异），导致分钟级统计报表出现 0.3%~1.8% 偏移
窗口函数不能用于 WHERE，但时序过滤恰恰最依赖它
你无法写 WHERE ROW_NUMBER() OVER (...) = 1——窗口函数在 SQL 执行顺序中晚于 WHERE，所以这类过滤必须用 CTE 或子查询封装。
- 典型错误：直接在主查询 WHERE 中引用窗口别名，报错
column "rn" does not exist - 正确姿势：
WITH ranked AS (SELECT ..., ROW_NUMBER() OVER (...) AS rn FROM metrics) SELECT * FROM ranked WHERE rn = 1 - 容易被忽略的是：CTE 中的
WHERE（如过滤掉异常值）必须放在窗口计算之前，否则无效——因为窗口函数作用于过滤后的结果集
