<p>正确写法是FLOOR(RAND() (b - a + 1)) + a，例如生成1–100用FLOOR(RAND() 100) + 1；避免ROUND导致分布不均；验证码用FLOOR(RAND() * 900000) + 100000；大表抽奖应避免ORDER BY RAND()，改用COUNT+OFFSET或主键范围查询；RAND()不可用于安全场景。</p>
SQL中用RAND()生成整数随机数的正确写法
RAND()返回的是0到1之间的浮点数（不包含1），直接乘以范围再取整容易出边界错误。比如想生成1–100之间的整数，FLOOR(RAND() * 100) + 1才是安全的——FLOOR(RAND() * 100)结果是0–99，加1后才是1–100。
常见错误写法：ROUND(RAND() * 99) + 1，因为ROUND()在0.5处四舍五入，会导致0.5概率略高，且RAND() * 99最大为98.999…，ROUND()后可能得99，加1变成100，但0出现概率极低，分布不均。
- 要生成
[a, b]闭区间整数：用FLOOR(RAND() * (b - a + 1)) + a - MySQL 8.0+支持
RAND() OVER()窗口用法，但仅限于派生表或CTE中配合ORDER BY RAND()做随机排序，不能直接用于生成列值 - PostgreSQL不用
RAND()，而是RANDOM()，用法一致：FLOOR(RANDOM() * 100) + 1
生成6位数字验证码的典型SQL写法
验证码要求固定长度、纯数字、无前导零，但FLOOR(RAND() * 900000) + 100000能稳定产出6位数（100000–999999），比拼字符串更可靠。
别用LPAD(FLOOR(RAND() * 1000000), 6, '0')：虽然看起来简洁，但RAND() * 1000000可能等于1000000，FLOOR()后是1000000，LPAD截成'1000000'共7位，超出长度；而且000000无法生成（最小是0，LPAD(0,6,'0')虽是'000000'，但RAND()几乎不可能精确落在0）。
- 稳妥方案：
FLOOR(RAND() * 900000) + 100000 - 如需带前导零字符串（例如导出报表用），再套
LPAD(..., 6, '0')，但底层仍是整数生成逻辑 - 注意：每次SELECT都会重新计算
RAND()，所以同一行里多次调用RAND()会得到不同值
抽奖序号场景下RAND()的陷阱与替代方案
直接用ORDER BY RAND() LIMIT 1抽一个获奖者，在小表上可行，但大表（比如百万用户）会触发全表扫描+临时文件排序，性能急剧下降，MySQL甚至可能OOM。
真正可用的优化方式不是“怎么让RAND()更快”，而是绕过它：
- 先用
SELECT COUNT(*)拿到总行数N，再应用层生成一个1–N随机整数r，然后SELECT ... LIMIT 1 OFFSET r-1 - 或者给表加自增主键id，用
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）
跨数据库兼容性与安全提醒
RAND()在MySQL中是会话级种子，同一SQL内多次调用返回相同值（除非显式SET RAND(seed)），而PostgreSQL的RANDOM()每次调用都独立；SQL Server用NEWID()或CHECKSUM(NEWID())模拟，Oracle用DBMS_RANDOM.VALUE。
最关键的一点：所有这些函数都不适合安全敏感场景，比如密码重置令牌或支付验证码——RAND()是伪随机，可预测，且不满足密码学强度。真要发验证码，请用应用层调用crypto.randomBytes（Node.js）或secrets模块（Python）生成。
