窗口函数不支持真正流式计算，实时排名需Flink SQL等外部系统配合；传统数据库仅支持事务型查询，无法自动刷新、事件驱动或保证并发一致性。

窗口函数本身不支持真正的流式计算，所谓“实时排名看板”必须靠外部系统配合——SQL窗口函数只能在批处理或微批（如Flink SQL、Spark Structured Streaming）中生效，直接在MySQL/PostgreSQL里跑ROW_NUMBER() OVER (ORDER BY sales DESC)无法自动刷新排名。

为什么不能在传统数据库里做“实时”排名看板

MySQL 8.0+ 和 PostgreSQL 13+ 虽支持窗口函数，但它们是面向事务型查询的：每次执行SELECT ROW_NUMBER() OVER (...) FROM orders WHERE event_time > NOW() - INTERVAL '5 minutes'都是一次全表扫描或索引范围扫描，且结果不会自动推送更新。用户刷新页面才重算，不是流式。

• 没有内置事件驱动机制，无法监听新订单插入就触发重排序
• RANK() / DENSE_RANK() 在并发写入时可能因快照隔离产生瞬时不一致（比如两个会话同时看到不同排名）
• 高频查询+大窗口（如“近1小时TOP 100商品”）会迅速拖垮orders表的读性能，尤其当event_time未建好复合索引时

Flink SQL 是目前最可行的落地路径

真正能对接Kafka实时订单流、持续输出排名的，是Flink SQL的OVER WINDOW + PROCTIME或ROWTIME语义。它把窗口函数变成有状态的流处理器。

• 必须显式定义时间属性：WATERMARK FOR rowtime AS rowtime - INTERVAL '5' SECOND，否则乱序数据会导致排名跳变
• 滑动窗口比滚动窗口更实用：OVER (ORDER BY rowtime RANGE BETWEEN INTERVAL '1' HOUR PRECEDING AND CURRENT ROW)才能支撑“近1小时动态榜单”
• 慎用ROW_NUMBER()：它依赖全量排序，Flink会缓存整个窗口数据；改用RANK()并配合LIMIT 100可减少状态大小
• 输出到Redis时，建议用HSET top_goods_20241111 "sku_123" "87"存排名，而非覆盖整个JSON——避免下游拉取时遇到部分写入不一致

PostgreSQL物化视图 + LISTEN/NOTIFY 可做轻量替代

如果架构不允许引入Flink，PostgreSQL可通过物化视图预聚合 + 触发器通知实现“准实时”（秒级延迟）。

• 用REFRESH MATERIALIZED VIEW CONCURRENTLY mv_hourly_rank每30秒跑一次，避免锁表
• 视图定义里必须包含WHERE event_time >= NOW() - INTERVAL '1 hour'，且event_time字段需有B-tree索引
• 创建AFTER INSERT OR UPDATE ON orders触发器，仅当新记录落入当前窗口才发NOTIFY rank_update
• 应用层用LISTEN rank_update监听，收到信号后再查物化视图——避免轮询浪费连接

真正的难点不在写对OVER子句，而在于时间语义对齐：Kafka消息时间、Flink处理时间、前端展示时间，三者差几秒就可能让运营看到“销量已破10万但排名还在第12位”。别只盯着SQL语法，先理清你的时间源是proctime还是rowtime，再决定窗口怎么切。