说到SQL里生成随机数，很多人第一反应就是RAND()，但真要用它来生成指定范围内的整数，踩坑的还真不少。比如想生成1到100之间的随机整数，直接ROUND(RAND() * 99) + 1看着挺合理，实际上因为ROUND()在0.5处四舍五入，会导致边缘概率分布不均，0出现的概率极低，而99到100之间的数值又偏高——这种偏差在做抽奖或分桶测试时尤其致命。
SQL中用RAND()生成整数随机数的正确写法
安全公式就一个：FLOOR(RAND() * (b - a + 1)) + a。拿1–100举例，FLOOR(RAND() * 100)稳稳落在0–99，再加1正好1–100，闭区间无死角。为什么不用ROUND？因为ROUND在0.5边界处的手法是四舍五入，而RAND() * 99的最大值只有98.999…，取整后最多99，加1得到100，但0呢？RAND() * 99的极小值接近0，经ROUND后大概率还是0或1，但0出现的概率被压缩了，且整个分布不再均匀。
- MySQL 8.0+支持
RAND() OVER()窗口用法，但只能用在派生表或CTE里配合ORDER BY RAND()做随机排序，无法直接当列值用。 - PostgreSQL用户注意：他们用
RANDOM()而非RAND()，公式完全一致：FLOOR(RANDOM() * 100) + 1。
生成6位数字验证码的典型SQL写法
验证码需要固定长度、纯数字、不能有前导零。一个稳定且不用拼接字符串的方案是FLOOR(RAND() * 900000) + 100000，输出范围100000–999999，刚好6位。有人喜欢用LPAD(FLOOR(RAND() * 1000000), 6, '0')，看着简洁，但这里藏了个边界问题：RAND() * 1000000有可能恰好等于1000000（虽然概率极低），FLOOR后就是1000000，LPAD变成7位字符串，不符合要求；而且000000这个值几乎不可能出现——因为RAND()精确落在0的概率无限小。所以稳妥的做法还是先保证整数范围，需要前导零显示时再在外面套LPAD。
还要注意一个细节：每次SELECT都会重新计算RAND()，所以同一行里多次调用会得到不同值，这在某些场景下可能不是你预期的行为。
抽奖序号场景下RAND()的陷阱与替代方案
用ORDER BY RAND() LIMIT 1来抽一个获奖者，在小表上很写意，但一旦表数据量达到百万级别，这条语句会触发全表扫描加临时文件排序，性能直接崩掉，MySQL甚至可能撑爆内存。真正的优化思路不是让RAND()跑得更快，而是绕过它。
- 先用
SELECT COUNT(*)拿到总行数N，应用层生成一个1到N之间的随机整数r，然后SELECT ... LIMIT 1 OFFSET r-1。 - 如果表里有自增主键且连续（无空洞），可以用
WHERE id >= FLOOR(RAND() * N) + 1 ORDER BY id LIMIT 1，但一定要确认id字段没有断裂，否则随机性会偏离均匀分布。 - 注意：
ORDER BY RAND()在UPDATE或INSERT中不可用，MySQL会直接报错Incorrect usage of RAND() and ORDER BY。
跨数据库兼容性与安全提醒
不同数据库的随机函数名字和特性差异挺大：MySQL的RAND()是会话级种子，同一次SQL内多次调用返回相同值（除非显式SET RAND(seed)）；PostgreSQL的RANDOM()每次调用独立；SQL Server没有直接等价函数，通常用NEWID()或CHECKSUM(NEWID())来模拟；Oracle则是DBMS_RANDOM.VALUE。
最后，也是最重要的一点：所有这些数据库自带的随机函数，都不适合安全敏感场景。比如密码重置令牌、支付验证码、抽奖种子——RAND()的本质是伪随机且可预测，不满足密码学强度要求。真要生成防破解的验证码，请务必在应用层用crypto.randomBytes（Node.js）或secrets模块（Python）这类安全随机源来生产。
