ORDER BY RAND()必然绕过索引，因其是非确定性函数，每行实时计算无序随机值，破坏B+树依赖的确定性与有序性，导致优化器放弃所有索引，强制全表扫描并filesort。
因为 RAND() 是非确定性函数，MySQL 无法为其建立有序索引结构，执行时必须为每一行实时计算随机值，导致优化器放弃所有索引，强制全表扫描 + filesort。
ORDER BY RAND() 为什么必然绕过索引
索引（B+树）依赖列值的**确定性与有序性**。RAND() 每次调用返回值都不同，且无规律可循，MySQL 无法预建“随机序”，也无法用索引做等值定位或范围跳转。即使 id 有主键索引，ORDER BY RAND() 也完全不利用它——EXPLAIN 会显示 type: ALL 和 Extra: Using temporary; Using filesort。
- 不是配置问题，也不是写法瑕疵，是 MySQL 5.7 及更早版本的固有限制
- MyISAM 和 InnoDB 表表现一致，引擎无关
- 哪怕只取 1 条：
SELECT * FROM t ORDER BY RAND() LIMIT 1，仍需全表计算 + 排序
WHERE RAND()
有人误以为把 RAND() 放在 WHERE 子句就能避免排序，但实际同样失效。例如：SELECT * FROM user WHERE RAND() —— 这里 <code>RAND() 是对**每一行独立求值**的条件，优化器无法下推、无法剪枝，只能逐行计算判断，仍是全表扫描。
-
RAND()在WHERE中属于“每行计算型谓词”，和UPPER(name)失效原理类似 - MySQL 不会对该表达式做任何索引匹配尝试，
key字段在 EXPLAIN 中恒为NULL - 这种写法还可能造成结果集大小不可控（比如空表返回 0 行，而百万表可能返回几千行）
MySQL 8.0.13+ 的函数索引对 RAND() 无效
虽然 MySQL 8.0.13 引入了函数索引（如 CREATE INDEX idx_upper ON t ((UPPER(name)))），但它**明确要求函数必须是 deterministic（确定性）的**。RAND() 被 MySQL 标记为 NOT DETERMINISTIC，建索引时会直接报错：ERROR 3952 (HY000): Function 'rand' is not allowed in generation expression。
- 其他常见非确定性函数同理：如
NOW()、CURRENT_TIMESTAMP()、UUID() - 试图用生成列（STORED COLUMN）存
RAND()值也不可行——生成列只允许确定性表达式 - 所以别指望靠新版本语法“修复”
RAND()的索引问题，得换思路
真正能替代的方案只有三类
所有可用方案都绕开“运行时随机排序”这个核心瓶颈，转为利用主键/索引的有序性做快速定位。
-
主键范围抽样：查
MIN(id)和MAX(id)，应用层生成 K 个随机 ID，用WHERE id IN (...)查询——全部命中主键索引 -
OFFSET + 主键有序跳转：先
SELECT COUNT(*)，再ORDER BY id LIMIT 1 OFFSET ?——ORDER BY id走主键索引，LIMIT让优化器用 B+ 树快速跳转 -
预置随机池表：业务低峰期把候选 ID 打散写入一张轻量表（如
random_pool(user_id, rand_order)），查询时ORDER BY rand_order LIMIT N——索引建在rand_order上即可高效服务
关键点在于：任何依赖运行时逐行计算随机值的写法，都会让索引彻底失效。真正落地时，要根据数据分布（ID 是否稠密）、QPS、一致性要求，在这三种路径中选最稳的那个——而不是反复调优 RAND() 写法。
