MySQL中替代随机选取未查看行的高效策略（类Tinder场景）

原方案SELECT * FROM data WHERE (seen = 0) ORDER BY RAND() LIMIT 1慢的核心原因是：ORDER BY RAND()会让数据库扫描所有seen=0的记录，给每条生成随机值后再排序，17万条数据的排序开销极大，直接拖慢查询速度。以下是几种高效替代方案和业界通用做法：

一、用Redis维护未查看用户ID池（首选方案） #

这是交友类APP最常用的方式，把数据库的随机查询逻辑转移到内存缓存中：

• 初始化：把所有seen=0的用户ID导入Redis的Set结构（Set天然去重，适合做池子）。
• 用户请求时：用SPOP命令随机取出一个ID（取出后自动从Set移除，不会重复返回）。
• 查询详情：用拿到的ID执行SELECT * FROM data WHERE id = ?，这是主键查询，速度极快。
• 异步更新：标记seen=1的操作可以放到异步队列里执行，不用阻塞用户请求。
• 优势：Redis的随机操作是O(1)复杂度，全程避开数据库的排序开销，响应速度能提升一个数量级。

二、基于主键范围的随机抽样（无缓存时的备选） #

如果暂时不想引入缓存，可以利用自增主键的特性优化：

1. 先获取未查看用户的主键范围：

   SELECT MIN(id), MAX(id) FROM data WHERE seen = 0;
   

2. 在应用层生成一个介于min和max之间的随机数random_id，然后查询：

   SELECT * FROM data WHERE id >= ? AND seen = 0 LIMIT 1;
   

3. 如果一次查不到（比如这个ID已经被标记为已查看），就多试2-3次，或者改成查询小于等于random_id的第一条记录。
4. 必须给seen和id建联合索引idx_seen_id，让范围查询更快：

   CREATE INDEX idx_seen_id ON data(seen, id);
   

• 注意：如果主键不是连续的，也可以先统计未查看用户的总数count，生成1到count的随机数，再用LIMIT ?,1：

  SELECT * FROM data WHERE seen = 0 LIMIT ?, 1;
  

  但这种方式在count很大时，LIMIT offset,1会因为需要扫描到offset位置而变慢，适合数据量不大的场景。

三、异步预加载缓存（高并发场景优化） #

针对高并发场景，可以提前预生成一批随机用户数据缓存起来：

• 后台定时任务（比如每分钟）用主键抽样的方式，查询100条未查看用户数据，存入Redis的List。
• 用户请求时直接从List头部弹出一条数据，响应速度几乎为0。
• 当List里的剩余数据低于阈值（比如20条），立刻触发异步任务补充数据。
• 标记seen=1的操作同样异步执行，不影响用户体验。

业界标准做法 #

绝大多数类似Tinder的交友应用，都会采用**「缓存层+异步处理」**的组合方案：

• 用Redis维护未查看用户的ID池或预加载数据，彻底避开数据库的随机排序操作。
• 数据库的写操作（标记已查看）全部异步执行，优先保证读请求的响应速度。
• 当用户量达到百万级以上，还会按地域、性别、年龄等维度拆分数据池，进一步缩小随机抽样的范围，提升效率。

内容的提问来源于stack exchange，提问作者Max J.