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()——想写跨库兼容的随机逻辑，基本等于自己造轮子。
