MySQL中RAND()为每行生成0到1间不同随机浮点数，非恒定表达式；ORDER BY RAND()实现随机排序，FLOOR/CEIL可转整数；不支持稳定种子，且ORDER BY RAND()性能差；PostgreSQL用RANDOM()，行为更严格。
MySQL里用RAND()生成每行不同的随机数
直接在SELECT里写RAND()就能为每一行返回一个0到1之间的浮点随机数，但要注意它**不是常量表达式**——同一查询中多次调用RAND()会得到不同结果，比如SELECT RAND(), RAND()的两列值几乎总是不等。
常见错误是想用RAND()做“固定随机排序”却忘了加ORDER BY，比如SELECT * FROM t ORDER BY RAND()才是随机打乱；而SELECT *, RAND() FROM t只是多一列随机值，不改变顺序。
- 需要整数随机数时，用
FLOOR(RAND() * N)（0到N−1）或CEIL(RAND() * N)（1到N） - 想复现相同随机序列？不行——
RAND()不支持种子参数（除非用RAND(N)，但只在首次调用生效，后续仍漂移） - 性能敏感场景慎用
ORDER BY RAND()，它会强制全表扫描+临时表排序，大数据量极慢
PostgreSQL必须用RANDOM()，且不能在WHERE里依赖确定性
PostgreSQL用RANDOM()而非RAND()，行为类似但更严格：它被标记为VOLATILE函数，意味着优化器不会缓存或复用结果，哪怕同一行内多次出现也各自重新计算。
典型陷阱是写WHERE RANDOM() 本意是抽10%样本，结果确实可行；但如果写成<code>SELECT *, RANDOM() AS r FROM t WHERE r 就会报错——<code>r是列别名，在WHERE阶段还不可见。
- 正确写法只有两种：
WHERE RANDOM() ，或子查询<code>SELECT * FROM (SELECT *, RANDOM() AS r FROM t) s WHERE s.r - 需要可重现的随机序列？用
SET seed配合RANDOM()，例如SELECT SETSEED(0.123); SELECT RANDOM();，但注意SETSEED是会话级的，且只影响后续RANDOM()调用 -
RANDOM()在GROUP BY或ORDER BY里可用，但会导致分组/排序不稳定，除非你明确需要随机分组
SQL Server没有内置RAND()行级函数，得绕道NEWID()或CHECKSUM()
SQL Server的RAND()是会话级单次求值函数——整个查询里所有行都返回同一个值，完全不能满足“每行一个随机数”的需求。真要用，必须借助其他机制。
最常用的是ABS(CHECKSUM(NEWID())) % N：利用NEWID()每次生成唯一GUID，CHECKSUM转成整数，再取模得0~N−1范围整数。这个组合能保证行级独立性，且无需提前初始化种子。
- 避免用
RAND()直接参与WHERE或ORDER BY，否则整张结果集只会按同一个随机值处理 - 如果要随机抽样，
TABLESAMPLE比手工算随机更高效（如SELECT * FROM t TABLESAMPLE (10 PERCENT)），但它基于页抽样，不是严格行级均匀 -
NEWID()方案有轻微性能开销（生成GUID+哈希），但远好过RAND()误用导致的逻辑错误
跨数据库生成固定范围随机整数的可移植写法
没有银弹。各数据库对“随机”的语义和稳定性处理差异太大，强行写统一SQL极易出错。若必须兼顾多个库，建议把随机逻辑提到应用层，或者用条件化SQL模板。
例如生成1~100的随机整数，在各库中对应写法差异明显：MySQL用FLOOR(1 + RAND() * 100)，PostgreSQL用FLOOR(1 + RANDOM() * 100)，SQL Server则必须写ABS(CHECKSUM(NEWID())) % 100 + 1。
- 别试图用
COALESCE(RAND(), RANDOM(), ...)兼容——语法直接报错 - 测试时特别注意：同一SQL在不同执行中结果是否符合预期分布，比如
ORDER BY RAND()是否真随机，还是因索引或缓存看起来“固定” - 真正关键的不是函数名，而是理解“该函数在当前上下文是否被当作稳定表达式”，这决定了它能不能用于
WHERE、GROUP BY或窗口函数中
