row_number() 不适用于电商大屏实时排名，因其强制唯一序号导致并列时排名断裂（如1,2,4）；应选用rank()（并列跳位：1,1,3）或dense_rank()（并列不跳位：1,1,2），并配合时间窗口、索引优化及推模式传输保障实时性与性能。
为什么 ROW_NUMBER() 不能直接用于电商大屏实时排名
因为 ROW_NUMBER() 在相同排序值下强制分配唯一序号，而大屏常需「并列排名」——比如两个商品同时销量第一，都该显示「第1名」。用它会导致排名断裂（如 1, 2, 4），用户一眼看出异常。
真正该用的是 RANK() 或 DENSE_RANK()：
-
RANK()：并列后跳位（1,1,3）——适合强调「名次层级」，比如销售额TOP榜 -
DENSE_RANK()：并列后不跳位（1,1,2）——适合「进前N名」类口径，比如「进入销量前10的商品」
注意：所有窗口函数必须配合 ORDER BY 子句，且排序字段不能为 NULL，否则结果不稳定；建议提前用 COALESCE(sales, 0) 填充。
如何让排名随最新订单实时更新（不是刷全表）
窗口函数本身不感知「实时」，关键在数据源是否流式或准实时。常见做法是把实时订单写入 orders_realtime 表（含 order_time），再用以下方式驱动排名：
- 用
WHERE order_time > NOW() - INTERVAL '5 minutes'限定时间窗口，避免全表扫描 - 在物化视图或实时数仓（如 Doris、StarRocks）中建带
WINDOW的聚合模型，比 PostgreSQL 普通视图快一个数量级 - 避免在
SELECT中对大表直接套OVER (PARTITION BY category ORDER BY sales DESC)—— 若未建联合索引(category, sales)，会触发文件排序，延迟飙升
示例（PostgreSQL）：
SELECT product_id, category, SUM(amount) AS hourly_sales, RANK() OVER (PARTITION BY category ORDER BY SUM(amount) DESC) AS rank_in_cat FROM orders_realtime WHERE order_time >= NOW() - INTERVAL '1 hour' GROUP BY product_id, category;
排名字段怎么传给前端大屏才不卡顿
前端每秒轮询一次 SQL 结果？绝对不行。数据库连接和计算压力会随并发直线上升。
- 改用「推模式」：用 CDC（如 Debezium）监听订单库变更，触发预计算 → 写入 Redis Hash（
rank:category:electronics），大屏直连 Redis 查 - 若必须查 DB，加
LIMIT 50并确保ORDER BY字段有索引——没索引时LIMIT不减少排序开销 - 别在 SQL 里拼
'第' || rank_in_cat || '名'：字符串拼接无法利用索引，且增加网络传输体积；格式化交给前端
多维度排名（如「本省销量+小时榜」）的坑
想同时看「全国排名」和「广东省内排名」？别写两个 OVER，容易漏 PARTITION BY 条件：
- 错误写法：
RANK() OVER (ORDER BY sales DESC)（没分区，全国统排，省内排名失效） - 正确写法：
RANK() OVER (PARTITION BY province ORDER BY sales DESC) AS rank_in_province，再加一个RANK() OVER (ORDER BY sales DESC) AS rank_nationwide - 如果
province来自关联表，务必用LEFT JOIN ... ON ... USING (product_id)，避免因 NULL 导致分区崩坏（PARTITION BY NULL会把所有行归为一组）
真实场景中，province 往往来自用户收货地址解析，字段可能为空或格式不一——先清洗再参与分区，比硬扛强。
