order by rand()在大数据量下极慢，因mysql需为每行调用rand()并全量排序，无法走索引，10万行约2秒、100万行超30秒；推荐改用主键范围随机跳查或应用层shuffle。
MySQL中用ORDER BY RAND()直接实现随机排序
这是最常用也最直观的方式，但必须清楚它在大数据量下会严重拖慢查询速度。MySQL会对每一行都调用一次 RAND()，再全量排序，没有索引可走。
适用场景：表行数在几千以内，或只是临时取几条测试数据。
- 基本写法：
SELECT * FROM users ORDER BY RAND() LIMIT 10 - 不能加
WHERE后再套ORDER BY RAND()还想快——只要用了RAND()，MySQL 就大概率放弃优化路径 - 如果表有自增主键且分布较均匀，可用「随机ID范围采样」替代，性能提升明显（见下一条）
用主键范围+RAND()避免全表扫描
当表有连续或近似连续的 id（如 AUTO_INCREMENT），可以绕过 ORDER BY RAND() 的性能陷阱。
原理是先估算主键最大值，生成随机ID，再用 WHERE id >= ? ORDER BY id LIMIT 1 模拟抽样，重复多次拼成结果集。
- 第一步查边界：
SELECT MIN(id), MAX(id) FROM users - 第二步在应用层生成 N 个随机整数，比如 Python 中用
random.randint(min_id, max_id) - 第三步拼查询：
SELECT * FROM users WHERE id IN (123, 456, 789)—— 注意要去重，且可能查不到对应行（ID空缺），需补足 - 这个方法不保证严格等概率，但对大多数业务场景足够，响应时间从秒级降到毫秒级
PostgreSQL和SQL Server的替代方案
不同数据库对随机排序的支持差异很大，硬套 RAND() 会报错或无效。
- PostgreSQL 用
ORDER BY RANDOM()（注意是RANDOM，不是RAND），行为类似 MySQL 的RAND()，同样有性能问题 - SQL Server 用
ORDER BY NEWID()，每次返回一个新 GUID 并据此排序，效果等价但函数名完全不同 - SQLite 用
ORDER BY RANDOM()，和 PostgreSQL 一致 - 所有这些写法都不能被索引加速，大数据量时务必考虑 ID 采样或应用层 shuffle
RAND() 的常见陷阱与误用
很多人以为加个 WHERE 条件就能让 ORDER BY RAND() 变快，实际并非如此。
-
SELECT * FROM logs WHERE status = 'error' ORDER BY RAND() LIMIT 5：即使status有索引，MySQL 仍需先取出所有 error 行，再逐行算RAND()排序 -
RAND(123)是固定种子，每次执行结果相同，适合测试但不适合生产随机需求 - 在子查询或视图里用
RAND()可能触发不可预期的多次求值，尤其配合JOIN时行数会膨胀 - 如果真需要可重现的“伪随机”，建议在应用层生成 shuffle 序列，传入
IN或VALUES列表，完全避开 SQL 随机函数
真正影响性能的不是“怎么写随机”，而是“要不要在数据库里做随机”。数据量一过十万，ORDER BY RAND() 类操作就该被当成危险信号对待。
