MySQL实现排行榜首选ORDER BY+LIMIT，需加索引防filesort；高并发场景用Redis ZSET；MySQL 8.0+支持RANK()等窗口函数处理并列排名，5.7以下不推荐变量模拟。
用 ORDER BY + LIMIT 实现基础排行榜
排行榜本质是按某字段排序后取前 N 名，MySQL 最直接的方式就是 ORDER BY 配合 LIMIT。比如按积分倒序取前 10 名用户：
SELECT user_id, score FROM users ORDER BY score DESC LIMIT 10;
注意：必须加 ORDER BY，否则 LIMIT 返回结果无序；若 score 有大量重复值，相同分数的用户可能因引擎内部顺序不同而每次结果不一致。
- 如果需要稳定排序，建议补上二级排序字段（如
user_id）：ORDER BY score DESC, user_id ASC - 避免在大表上直接
ORDER BY无索引字段，会触发 filesort，性能急剧下降 -
LIMIT 10000, 20这类深分页要警惕——MySQL 仍需扫描前 10020 行，推荐改用游标分页（如记录上一页最大score值）
处理并列排名：RANK() vs DENSE_RANK() vs ROW_NUMBER()
真实排行榜常要求“同分同名次”，比如两个用户都得 95 分，都排第 2 名，下一名是第 4 名（跳过第 3）。MySQL 8.0+ 支持窗口函数，三者区别很关键：
-
RANK()：并列跳名次（95, 95, 87 → 1, 1, 3） -
DENSE_RANK()：并列不跳名次（95, 95, 87 → 1, 1, 2） -
ROW_NUMBER()：严格按行编号（95, 95, 87 → 1, 2, 3）
实战示例（显示前 10 名及对应名次）：
SELECT user_id, score, RANK() OVER (ORDER BY score DESC) AS rank_num FROM users LIMIT 10;
⚠️ MySQL 5.7 及更早版本不支持窗口函数，只能用变量模拟，但并发下容易出错，不推荐用于生产排行榜。
实时性与性能瓶颈：什么时候不能直接查表？
当用户量达百万级、排行榜访问频繁（如每秒数百请求），每次执行 ORDER BY ... LIMIT 会持续争抢索引 B+ 树的临界区，CPU 和 I/O 压力明显上升。
- 高频读场景优先考虑缓存：用 Redis 的
ZSET存储score和user_id，ZREVRANGE毫秒级返回 Top N - 若必须走 MySQL，确保
score字段有单独索引或联合索引的最左前缀（如INDEX(score, user_id)） - 避免在排行榜查询中 JOIN 多张大表或调用函数（如
FROM_UNIXTIME(created_at)），这些都会让索引失效
更新频繁时的排名一致性问题
用户积分实时变动，但 SELECT ... ORDER BY 是快照读，无法反映事务中未提交的变更。更麻烦的是：两个事务同时更新同一用户分数，再查榜，可能看到“中间态”排名。
- 单纯查榜不需要强一致性，用默认
REPEATABLE READ隔离级别即可 - 若业务要求“更新后立刻上榜”，需在更新积分后主动刷新缓存（如更新 Redis
ZADD），而非依赖数据库实时查 - 不要在应用层靠多次查询 + 逻辑计算排名（如“比当前用户分高的有几人”），
SELECT COUNT(*)全表扫描代价太高
真正难的不是怎么写 SQL，而是想清楚：这个榜是给谁看的、多久更新一次、允许多大延迟、并列规则是否影响奖励发放——这些决定了该用 MySQL 直查、Redis 缓存，还是混合方案。
