滑动窗口卡住因窗口未对齐实时节奏、partition by与order by顺序颠倒、range between缺时间索引；实时分析须用rows between，order by event_time asc且event_time需索引；lag()须显式定义窗口帧；mysql中row_number()需联合索引优化；clickhouse中neighbor()仅适用于严格时序写入场景。
滑动窗口函数在实时场景下为什么总卡住
因为窗口定义没对齐实时节奏，PARTITION BY 和 ORDER BY 搞反了顺序，或者用了 RANGE BETWEEN 却没建时间列索引。数据库会为每行重新扫描整个时间范围，QPS 上去就直接拖垮。
- 实时流式分析必须用
ROWS BETWEEN，不是RANGE—— 后者依赖排序后值的连续性，而 Kafka/Flink 落库的时间戳常有微小抖动，导致窗口边界漂移甚至重复计算 -
ORDER BY event_time ASC是硬要求，但很多业务表只在id上建了主键，event_time字段没索引，查 10 分钟窗口就得扫几百万行 - 别在 WHERE 条件里写
event_time > NOW() - INTERVAL '5 minutes'再套窗口函数——优化器没法下推，先算完全量窗口再过滤，内存爆掉是常态
PostgreSQL 中 LAG() 和 WINDOW 子句怎么配才不丢数据
LAG() 看似简单，但在高并发写入+定时刷新的实时看板里，经常返回 NULL 或错位值。根本原因是没显式声明窗口帧，让 PostgreSQL 默认用了 UNBOUNDED PRECEDING AND CURRENT ROW，而你的业务需要的是“前 5 条同用户记录”，不是“从头到当前”。
- 必须显式写
OVER (PARTITION BY user_id ORDER BY event_time ROWS BETWEEN 4 PRECEDING AND 1 PRECEDING)，否则LAG(col, 5)在数据稀疏时会跳过空缺，指向更早的记录 - 如果
event_time有重复（比如批量导入），仅靠ORDER BY event_time不够稳定，得补上id：ORDER BY event_time, id - PostgreSQL 14+ 支持
WINDOW w AS (...)复用定义，但注意：子查询里引用该 WINDOW 名时，外层不能改PARTITION BY字段，否则报ERROR: window definition cannot be changed
MySQL 8.0 的 ROW_NUMBER() 实时排序慢得离谱怎么办
不是函数本身慢，是 MySQL 对 ORDER BY ... LIMIT 和窗口函数共存时的执行计划很僵硬。它倾向于先排序全量再取 Top-N，而不是边流式排序边裁剪。
- 把
ORDER BY created_at DESC改成ORDER BY created_at DESC, id DESC，并确保这两个字段合起来有联合索引——否则ROW_NUMBER()强制触发 filesort - 避免在窗口函数外再套
WHERE row_num ，改成子查询加 <code>LIMIT：先SELECT *, ROW_NUMBER() OVER (...) AS rn FROM t WHERE created_at > ... ORDER BY created_at DESC LIMIT 100，让优化器能走索引覆盖 - 如果只是要最新 N 条，别用
ROW_NUMBER()，直接ORDER BY created_at DESC LIMIT N更快；窗口函数真正必要场景是“每个分组内排 Top-N”，比如每个user_id最近 3 条操作
ClickHouse 里 neighbor() 替代窗口函数真能提速？
能，但只适用于严格按时间顺序写入、且不删不改的场景。它本质是跳过排序和分区维护，靠物理存储顺序直接取相邻行，所以比标准窗口快 3–5 倍。可一旦数据重平衡或异步合并后顺序乱了，neighbor() 就开始返回错误偏移。
- 只在
ReplacingMergeTree或CollapsingMergeTree表上慎用——合并过程可能重排块，neighbor(event_time, -1)可能取到上一批次的数据 - 必须配合
ORDER BY (dt, event_time, id)建表，并确保写入端严格按event_time递增推送，否则物理顺序 ≠ 逻辑时间顺序 - 替代
LAG()可以，但替代AVG() OVER (ROWS BETWEEN 10 PRECEDING AND CURRENT ROW)不行——neighbor()只能取单值，没法聚合
窗口函数不是银弹，实时性越强，越得盯着数据写入模式、索引结构和引擎行为三者是否咬合。漏掉任意一环，性能拐点来得比预想中快得多。
