MySQL中RAND()生成[0,1)浮点数，同一行多次调用值相同；需FLOOR(RAND()*N)+1得1–N随机整数；ORDER BY RAND()性能差，大数据量应避免。
MySQL中RAND()生成0到1之间的浮点随机数
RAND()在MySQL里每次调用都返回一个[0, 1)区间内的浮点数，不是整数，也不是固定种子——它默认用系统时间做种子，所以同一语句内多次调用结果不同，但同一行里多次调用RAND()值相同（因为MySQL会缓存该行的随机值）。如果需要可复现的随机序列，必须显式传入整数种子，比如RAND(42)。
常见错误是想直接用RAND() * 100取整得到1–100之间的整数，结果发现FLOOR(RAND() * 100) + 1才能稳定覆盖1–100（RAND()不会返回1，所以*100最大是99.999…，FLOOR后是0–99）。
- 要生成1–N的随机整数：
FLOOR(RAND() * N) + 1 - 要生成A–B范围（含端点）的随机整数：
FLOOR(RAND() * (B - A + 1)) + A - 避免在WHERE中直接用
RAND() > 0.5做采样——MySQL可能对每行重复计算，导致行为不稳定；应优先用子查询或ORDER BY RAND()替代
PostgreSQL里没有RAND()，得用RANDOM()
PostgreSQL用的是RANDOM()函数，行为和MySQL的RAND()基本一致：返回[0, 1)的double precision浮点数。但它不支持传入种子参数，所以无法复现结果。若需可重现的随机性，得自己实现，比如结合md5(CAST(id AS TEXT) || 'seed')再哈希取模。
注意：RANDOM()在WHERE、JOIN条件里使用时，PostgreSQL会对每一行重新求值，这可能导致意外的非确定性行为（比如LEFT JOIN中右表匹配行数波动）。实际中更稳妥的做法是先生成随机序号再JOIN，或者用TABLESAMPLE做系统抽样。
- 生成1–100随机整数：
FLOOR(RANDOM() * 100) + 1 - 抽样10%行：
SELECT * FROM t TABLESAMPLE SYSTEM (10)（比ORDER BY RANDOM() LIMIT ...快得多） -
ORDER BY RANDOM()在大数据集上极慢，因为要为全表每行计算并排序，慎用
ORDER BY RAND()取随机行的性能陷阱
这是最常用也最容易翻车的操作：SELECT * FROM users ORDER BY RAND() LIMIT 5。表面上简洁，但MySQL会为表中每一行计算一次RAND()，再全部排序——哪怕只取5行，100万行表也要算100万次随机数+完整排序。
替代方案取决于场景：
- 表有自增主键且数据密集（无大片空缺ID）：
SELECT * FROM users WHERE id >= FLOOR(RAND() * (SELECT MAX(id) FROM users)) LIMIT 5，但需配合多次尝试或补足逻辑 - 要求严格均匀随机且数据量不大（ORDER BY RAND()仍可接受
- PostgreSQL建议用
TABLESAMPLE BERNOULLI(0.5)或SYSTEM(0.5)，底层走块级采样，不计算每行 - 真正大数据场景，应预生成随机ID列表或用应用层分页+随机offset（注意offset大时性能也差）
SQL Server和SQLite的随机函数差异
SQL Server用NEWID()模拟随机排序：ORDER BY NEWID()，本质是生成GUID再排序，效果类似RAND()但开销略高；它没有内置的标量随机数函数，如需数值得用CHECKSUM(NEWID()) % 100这类变通写法。
SQLite用random()（小写），返回-9223372036854775808到+9223372036854775807之间的整数，不是0–1浮点数。所以生成1–100要写成(ABS(random()) % 100) + 1，且注意ABS()防负数溢出。
- SQLite中
random()在单条语句内多次调用结果不同（不像MySQL缓存），这点容易引发逻辑偏差 - SQL Server若需可重现随机序列，只能靠
NEWID()拼接固定字符串再哈希，没有原生种子支持 - 所有数据库里，把随机函数放进JOIN ON或WHERE里都可能破坏执行计划，尽量移至子查询或CTE中预先计算
真正难的不是写出RAND()，而是判断当前查询是否真的需要“每行独立随机”——很多时候业务只要“从全集中随机挑几个”，用采样或ID范围跳过全表计算，效率能差一两个数量级。
