MySQL ORDER BY RAND() 为什么会拖垮接口：一次随机推荐慢查询复盘

一次首页随机推荐改版后，接口最先暴露的不是报错，而是响应变慢：P95耗时从几十毫秒涨到两三秒，数据库CPU长时间维持在高负载区间，慢查询日志里反复命中同一类SQL。排查下来，根因不是索引突然失效，也不是连接数打满，而是一句看起来很省事的 ORDER BY RAND() 直接把大表全量随机排序逻辑放到了线上高频请求链路里。

影响面：推荐接口变慢，数据库CPU被持续打高

这类问题的故障现场通常很混乱。应用层日志只会显示推荐接口耗时升高，网关偶尔触发超时阈值，数据库监控页上CPU使用率和临时表生成量同步上涨。因为这类SQL最后还是能返回少量结果，不少人第一反应会误以为只是访问量突增的正常业务高峰。

真正需要警惕的是三个信号同时出现：接口只需要返回十几条推荐内容；慢查询统计的扫描行数远高于实际返回的行数；数据库CPU在请求高峰区间持续爬升居高不下。这个组合基本可以判定，数据库正在为了返回少部分随机结果，付出了远超预期的排序资源成本。

时间线：一次看似无风险的随机排序逻辑上线

复盘的时候把完整时间线梳理清楚，比单纯纠结某一行SQL的写法更有参考价值。问题大多不是单个开发者写错了代码，而是小流量测试阶段没有暴露真实资源消耗，灰度发布的流量也没覆盖到真实业务峰值场景。

触发SQL：少部分返回结果背后是全量大范围排序

线上最容易踩坑的危险写法大多长这样：

SELECT id, title, cover_url
FROM articles
WHERE status = 'published'
ORDER BY RAND()
LIMIT 10;

这条SQL看起来只会返回10条结果，但数据库为了拿到符合要求的随机顺序，需要先给所有符合筛选条件的候选行生成随机值，再全量排序。候选行只有几千条的时候性能损耗还不明显；等数据量涨到几十万、上百万行，再叠加首页的高频访问，数据库就会被反复执行的随机排序逻辑拖垮。

更不容易提前发现的点是，开发环境的测试数据量通常很小，压测环节也可能只校验了接口是否正常返回，没有同步接入慢查询日志、临时表生成量和CPU负载的监控，等线上真实数据量跑起来，问题才会彻底暴露。

根因：随机排序操作没有提前缩小候选集范围

这次故障的根因不是完全不能做随机推荐，而是直接把随机排序的动作放在了量级过大的候选数据集上。MySQL本身擅长按索引定位资源、范围扫描和返回预先排序好的结果，让它在大集合上反复生成随机值再做全量排序，资源消耗会跟着候选集的量级指数级上涨。

• 候选筛选条件太宽松：只按 status = 'published' 做过滤，命中的行数远超预期。
• 排序结果无法复用：每次执行 RAND() 得到的随机序列都不一样，常规缓存和索引都没法直接优化这个排序过程。
• 返回字段数量偏多：推荐卡片需要拉取标题、封面、摘要等多个字段，排序完成后还要读取大量额外数据，进一步拉高资源开销。
• 接口请求频率高：首页、频道页、内容页相关推荐多个入口同时调用，直接把单条SQL的资源消耗放大数倍。

修复动作：从全表随机改成预维护候选ID池

最稳妥的改造方案是把随机操作和数据库查询拆成两个独立步骤。先通过离线任务或者定时脚本提前维护一份候选ID池，池子里只存放符合推荐规则的内容主键；用户请求进来的时候先在业务侧生成随机偏移量，再通过主键或者预先生成的随机排序键走索引直接读取少量结果。这样数据库的操作就从之前的大范围全量随机排序，变成了轻量的索引定位返回。

-- 候选池表只保留可推荐主键和随机键
CREATE TABLE article_recommend_pool (
  id BIGINT PRIMARY KEY,
  article_id BIGINT NOT NULL,
  rand_key INT NOT NULL,
  status TINYINT NOT NULL,
  KEY idx_rand_status (status, rand_key)
);

-- 请求侧先生成一个随机起点，再用索引定位
SELECT article_id
FROM article_recommend_pool
WHERE status = 1 AND rand_key >= 742531
ORDER BY rand_key ASC
LIMIT 10;

如果最终查询得到的结果不足10条，可以从最小的随机键开始再补查一次。虽然这里多了一点业务侧的补全逻辑，但数据库不会每次请求都对大表做随机排序。候选池的更新操作也可以放到后台定时任务里执行，完全不占用户主请求链路的资源。

防复发：随机推荐功能要明确查询资源配额

故障修复完成后不能只看接口恢复正常就结束。随机推荐这类功能后续迭代需求很容易再次放开筛选条件放大候选集，所以要把明确的查询资源配额写进开发约束里：候选集最大上限、单次接口返回数量、慢查询告警阈值、临时表生成指标、兜底返回规则和紧急回滚开关都要提前定好。

• 功能上线前用线上同量级的真实数据生成查询执行计划，提前记录扫描行数和排序的执行方式。
• 推荐接口配置限流和降级策略，数据库负载异常的时候直接返回预先缓存的候选结果。
• 慢查询日志里出现 ORDER BY RAND() 相关语句要直接进入强制排查清单。
• 候选池更新的定时任务要记录更新行数、执行耗时，配置失败告警规则。
• 压测环节不能只统计接口平均耗时，必须观测P95、P99耗时、数据库CPU和临时表生成量这些核心指标。

常见问题

小表场景下可以直接用 ORDER BY RAND() 吗？

可以谨慎使用。候选集只有几百行、调用频率很低的场景下，性能问题不会明显暴露。但一旦进入首页、推荐流、广告位这类高流量入口，就要提前换成资源消耗更可控的方案。

预先生成候选ID池会不会降低随机效果？

会牺牲一部分完全随机的纯度，但换来的是稳定可预期的查询资源消耗。常规的内容推荐场景更看重服务稳定、可回滚、异常可感知，不需要每次请求都对全量数据做严格的完全随机排序。

随机键方案需要每天重建一次吗？

可以跟着业务内容的更新频率调整。内容更新迭代很快的场景可以按小时刷新候选池；内容池相对稳定的场景每天刷新一次也完全够用。核心要求是候选池的刷新动作绝对不能阻塞用户的主请求链路。

直接用缓存存储随机结果可行吗？

可行。缓存适合高流量入口的兜底和削峰，但缓存没有命中的场景下，依然要有资源消耗稳定的数据库查询兜底方案，不然缓存集中失效的时候，全量请求直接打回数据库，故障会再次复现。

只加索引能不能直接优化 ORDER BY RAND() 的性能？

通常没法彻底解决问题。索引可以帮助快速过滤、定位目标数据，但随机排序这个操作本身很难直接复用常规索引的有序性。优化的核心还是要提前缩小候选集范围，或者把预先生成的随机排序键设计成可以直接走索引的字段。

把随机排序操作从大表主链路里剥离出来

这次慢查询复盘留下的经验很实在：随机推荐功能本身完全可以正常使用，问题在于不要让MySQL每次请求都对大量级的候选集重新做全量排序。先把可推荐的内容收敛到独立维护的候选池，再通过随机键、缓存和降级策略控制整个请求链路，数据库负载会稳定很多，出现异常的时候也能快速回滚止血。