为什么SQL RAND函数不适合生产环境随机排序

ORDER BY RAND()在MySQL中极慢，因其必须全表扫描、为每行计算RAND()并全量排序，即使LIMIT 1也无法避免，100万行耗时可达30秒，且索引完全失效；替代方案为主键范围随机采样等避开排序的方法。

因为 RAND() 在大多数数据库里触发全表扫描 + 全行随机数计算 + 全量排序，不是“慢一点”，而是随数据量指数级恶化，生产环境根本扛不住。

MySQL 的 ORDER BY RAND() 实际干了三件事

它不是“给结果排个随机序”，而是：

• 对表中每一行调用一次 RAND()（哪怕你只想要 1 条）
• 把所有行连同生成的随机值一起载入内存或磁盘临时表
• 执行完整排序（Using filesort），再取 LIMIT 前几条

这意味着：10 万行表可能 2 秒，100 万行就奔着 30 秒去；并发 5 QPS 就能把 CPU 和 sort_buffer 耗尽。EXPLAIN 里永远显示 type: ALL，索引完全失效。

SQL Server 的 RAND() 根本不随机

RAND() 在单条语句中只计算一次——所有行拿到的是同一个浮点数。所以 ORDER BY RAND() 实际等价于 ORDER BY 0.6789，结果固定、顺序可预测，只是你看不出规律而已。

真正可用的是 NEWID()，但它同样要全表计算 GUID + 排序，大表一样卡死。更糟的是：RAND() 还不能用在视图、内联函数或计算列里，一用就报错。

PostgreSQL 的 RANDOM() 看似可靠，但依赖统计信息

ORDER BY RANDOM() LIMIT 10 每行确实独立调用，结果等概率。但它的执行计划依赖 ANALYZE 输出的行数估算。如果刚导入 100 万行却没运行 ANALYZE，规划器还以为只有 10 万行，LIMIT 10 可能提前截断，实际只返回 2 条。

另外，RANDOM() 不支持传种子，没法复现结果——AB 测试分流、回归测试都做不到。

SQLite 的 RANDOM() 返回负数，排序反直觉

它所返回的是从 -9223372036854775808 到 +9223372036854775807 的整数。要是直接使用 ORDER BY RANDOM() 的话，所有负数会挤在最前面，视觉上看起来就像是“半随机”的效果。必须写成 ORDER BY ABS(RANDOM()) 或者 ORDER BY RANDOM() % 1000000 才勉强能够使用。

而且 SQLite 没有真正的并发控制，RANDOM() 在 WAL 模式下仍可能因 page cache 复用导致重复序列。

真正让人头疼的并非函数本身，而是不同数据库对于“随机”的实现方式完全不一致：MySQL返回的是浮点数，SQLite返回的是大整数，PostgreSQL返回的是0至1之间的小数，SQL Server甚至没有RANDOM()函数，只有NEWID()函数。这意味着，如果想要编写能够跨库兼容的随机逻辑，几乎等同于要自己重新发明轮子。