ORDER BY RAND() 性能差是因为需全表扫描、为每行计算随机数并全量排序，索引失效；百万级表单次查询可达数秒，高并发时拖垮CPU和I/O。
ORDER BY RAND() 会导致全表扫描和性能雪崩
MySQL 对 RAND() 没有索引支持，ORDER BY RAND() 会强制为每一行计算随机值，再排序——这意味着无论你只要 5 条还是 100 条，它都得先扫完整张表、生成全部随机数、再做一次全量排序。百万级用户表下，单次查询可能卡住几秒甚至十几秒，且并发一高就拖垮 CPU 和 I/O。
常见错误现象：SHOW PROCESSLIST 中看到大量 Sorting result 状态；慢查询日志里频繁出现带 ORDER BY RAND() 的语句；线上抽奖接口响应时间毛刺明显。
- 仅适用于小表（
SELECT COUNT(*)结果 - 不能加在已有复杂 WHERE 条件之后还指望高效——WHERE 过滤后仍需对结果集逐行算
RAND() - 如果表有主键自增且无删除空洞，可用替代方案绕过排序
用主键范围随机 + LIMIT 1 实现高效抽样
前提是表的主键是连续或近似连续的整型（如 id 是 INT UNSIGNED AUTO_INCREMENT），且没有大量删除导致严重空洞。思路是：先估算最小/最大 id，取随机值去查，查不到就重试，最多试几次即可收敛。
实操建议：
- 先执行
SELECT MIN(id), MAX(id) FROM users获取边界（可缓存，不必每次查） - 在应用层生成 N 个
RAND() * (max_id - min_id) + min_id的随机整数 - 对每个随机
id执行SELECT * FROM users WHERE id = ? LIMIT 1，收集非空结果 - 若数量不足 5，补采再试（通常 2–3 轮足够）
比 ORDER BY RAND() 快 10 倍以上，且能利用 PRIMARY KEY 索引快速定位。
真正均匀又稳定的方案：用 UUID 或 hash 字段预计算
如果业务允许写入时稍作改造，这是最可控的方式。在用户注册或导入时，额外存一个 rand_hash 字段（比如 MD5(CONCAT(id, UNIX_TIMESTAMP())) 或直接用 UUID() 截取前 8 位），并为其建索引。
后续抽奖直接：
SELECT * FROM users WHERE rand_hash >= '随机字符串' ORDER BY rand_hash LIMIT 5;
或者更稳一点：
SELECT * FROM users ORDER BY rand_hash LIMIT 5 OFFSET FLOOR(RAND() * (SELECT COUNT(*) FROM users));
要点：
-
rand_hash必须是写入时一次性生成，不能每次查都MD5(id)计算——否则又回到全表计算的老路 - 用
ORDER BY rand_hash可走索引，避免排序开销 - 该字段值分布越均匀（推荐用加密安全的哈希或
UUID_SHORT()），抽中结果越接近理论随机性
LIMIT 5 在不同场景下的行为差异
LIMIT 本身不保证顺序，必须配合 ORDER BY 才有确定性。但要注意：ORDER BY RAND() LIMIT 5 和 LIMIT 5 单独用，语义完全不同。
- 没
ORDER BY时，LIMIT 5返回的是存储引擎返回的前 5 行——可能是按插入顺序、也可能是按页物理顺序，完全不可控 -
ORDER BY RAND() LIMIT 5是先全表打乱再截断，逻辑正确但代价高 - 如果用了
ORDER BY id DESC LIMIT 5，那抽出来的永远是最新注册的 5 人，根本不是随机 - 分库分表环境下，
ORDER BY RAND()无法跨分片统一打乱，必须收口到应用层聚合后再随机
真正的难点不在“怎么写 SQL”，而在于理解数据规模、分布特征和一致性要求——小活动用 RAND() 无妨，但一旦涉及真实奖品发放，就得提前规划好可扩展的随机策略。
