ORDER BY RAND()在题库超10万行时急剧变慢，因其强制全表扫描、逐行计算随机数并全量排序，触发Using temporary和Using filesort，IO与CPU双爆；小表（≤1万行）可用，大表必须改用主键范围查询等替代方案。
MySQL中用ORDER BY RAND()抽题为什么越来越慢
当题库超过10万行，ORDER BY RAND()会触发全表扫描+内存排序，查询耗时从毫秒级飙升到秒级，且并发一高就容易锁表。这不是语法错，是MySQL执行引擎的固有缺陷——它得先把所有满足条件的题目都捞出来，再逐行打乱。
实操建议：
- 永远不要在大表上直接用
ORDER BY RAND() LIMIT N抽题，尤其在线考试这种强实时场景 - 若题量小（WHERE difficulty = 'hard' 先过滤再乱序
- 给
difficulty字段建普通索引（不是唯一索引），避免全表扫描
用主键范围随机法替代ORDER BY RAND()
核心思路：不依赖MySQL排序，而是先查出当前难度题目的最小和最大id，再用应用层生成随机id去“碰”题，多次重试直到凑够数量。它快，因为只走索引B+树查找，不排序、不临时表。
示例步骤（以抽取5道difficulty = 'medium'题为例）：
- 第一步：
SELECT MIN(id), MAX(id) FROM questions WHERE difficulty = 'medium' - 第二步：应用层生成 5 个
id随机数，范围在 [min_id, max_id] 内 - 第三步：对每个随机
id执行SELECT * FROM questions WHERE id = ? AND difficulty = 'medium' LIMIT 1 - 第四步：若某次没查到（ID被删过或难度不匹配），重新生成一个新ID，最多重试20次防死循环
注意：id 必须是自增主键且无大量删除碎片，否则命中率会下降；若题库删改频繁，需配合逻辑删除标记（如 is_deleted = 0）一起查。
用预生成随机偏移量避免重复抽题
考试系统常要求“同一场考试内题目不重复”，而纯随机可能撞车。更稳的做法是：先统计总数，再用 FLOOR(RAND() * COUNT) 算偏移量，配合 LIMIT 1 OFFSET ? 取题。虽然仍要COUNT，但比ORDER BY RAND()轻量得多。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
关键写法：
SELECT @cnt := COUNT(*) FROM questions WHERE difficulty = 'hard'; SELECT * FROM questions WHERE difficulty = 'hard' LIMIT 1 OFFSET FLOOR(RAND() * @cnt);
要抽N道题，就重复执行N次（每次OFFSET不同），或用变量循环（MySQL 8.0+支持CTE递归）；但注意：OFFSET越大，性能越差，所以仅适用于N ≤ 20、题库总数≤50万的场景。
真正稳定的方案：题目标签预分组+缓存
线上考试系统最终都会走向“预处理”。比如每天凌晨跑一次脚本，把所有difficulty = 'easy'的题目id写入Redis的set:easy，再用SRANDMEMBER set:easy 10秒级取10道不重复题——这比任何SQL随机都可靠。
落地要点：
- 新增/修改题目时，同步更新对应Redis集合（用pipeline批量操作）
- 用
EXPIRE设7天过期，防冷数据堆积 - MySQL里保留原始题库做兜底，Redis抽不到时再 fallback 到主键范围法
- 别忘了在事务中维护一致性：比如一道题难度从
medium改成hard，必须原子性地从set:medium移除、加入set:hard
最难的不是怎么随机，是怎么让随机结果在分布式多实例下不冲突、不重复、不延迟。一旦考试开始，数据库只是备份，缓存才是命脉。
