MySQL中ORDER BY RAND()不随机是因优化器将其缓存为常量，导致全用同一值排序；PostgreSQL用ORDER BY RANDOM()、SQL Server用ORDER BY NEWID()可保证真随机，大表优先TABLESAMPLE或应用层随机ID查询。
MySQL里用RAND()排序为什么有时不随机？
因为RAND()在ORDER BY中被当作“常量”缓存了——尤其在子查询或带LIMIT时，MySQL可能只算一次RAND()值，然后全用它排序，结果看起来完全不随机。
- 真实场景：想取10条随机用户，但每次执行返回的都是同一组（顺序不同而已）
- 根本原因：优化器把
ORDER BY RAND()误判为“可复用表达式”，尤其在没有WHERE过滤或表很小时更明显 - 最简验证：执行
SELECT id, RAND() AS r FROM users LIMIT 5，看r列是否全一样
PostgreSQL和SQL Server怎么安全实现随机抽样？
它们不认RAND()，但各自有更可控的替代方案，关键是避免触发排序缓存或全表扫描陷阱。
- PostgreSQL用
ORDER BY RANDOM()——注意不是RAND()，且对大表慎用，会强制全表读+内存排序 - SQL Server用
NEWID()：ORDER BY NEWID()，每次生成唯一GUID，确保真随机；但NEWID()是行级计算，大数据量时CPU开销明显 - 如果只要少量随机记录（比如5条），优先考虑
TABLESAMPLE（PostgreSQL/SQL Server都支持）：SELECT * FROM users TABLESAMPLE SYSTEM (1)，它走采样而非排序，快得多，只是不保证绝对均匀
大数据量下ORDER BY RAND()性能崩了怎么办？
当表超百万行，ORDER BY RAND()会让数据库把整张表载入内存排序，I/O和CPU双爆，响应直接卡死。
- 别硬扛：用应用层分两步——先
SELECT COUNT(*)拿到总数，再用程序生成N个随机id，最后SELECT ... WHERE id IN (...) - 前提：主键是连续或近似连续的整型；否则用
OFFSET+ 随机偏移：SELECT * FROM users LIMIT 1 OFFSET FLOOR(RAND() * (SELECT COUNT(*) FROM users))，但重复抽样概率高，要多次去重 - 终极妥协：加个
WHERE RAND() 先筛掉99%数据，再<code>ORDER BY RAND() LIMIT 10，平衡随机性和速度
SQLite里RANDOM()返回负数，排序结果反直觉
SQLite的RANDOM()函数返回的是-9223372036854775808到+9223372036854775807之间的整数，不是0~1小数——直接ORDER BY RANDOM()会按有符号整数排，负数全挤前面，视觉上像“半随机”。
- 正确做法：用
ABS(RANDOM())转成正数，或者更稳一点：ORDER BY RANDOM() % 1000000取模缩放到正区间 - 别信文档里“随机”的字面意思——不同数据库的
RANDOM/RAND语义根本不统一，MySQL返回浮点，SQLite返回大整数，PostgreSQL返回0~1小数 - 跨库移植时，最保险的是彻底避开内置函数，改用应用层生成随机种子传入参数化查询
随机排序真正的难点从来不在语法，而在于你是否清楚自己要的是“统计意义随机”还是“肉眼看着乱”，以及愿不愿意为前者多跑一次查询、为后者接受轻微偏差。没测过数据量和实际耗时就写ORDER BY RAND()，基本等于留了个定时性能炸弹。
