MySQL中RAND()返回[0,1)浮点数，直接取整得0或1；正确生成[5,15]整数需FLOOR(RAND()*(15-5+1))+5，缺+1则范围错误；PostgreSQL用RANDOM()同理；SQL Server需ABS(CHECKSUM(NEWID()))%11+5。
MySQL里用 RAND() 生成整数随机数，为什么总得到0或1？
因为 RAND() 只返回 [0, 1) 区间的浮点数，直接取整（比如 INT(RAND())）几乎永远是 0。要得到指定范围的整数，必须先缩放再取整。
- 正确做法是：用
FLOOR()配合线性变换，例如生成 [5, 15] 闭区间整数 →FLOOR(RAND() * (15 - 5 + 1)) + 5 - 关键点：
+ 最小值和* (最大值 - 最小值 + 1)缺一不可，漏掉 +1 就会少一个可选数字 - 常见错误写法：
FLOOR(RAND() * 10) + 5看似想生成 5~14，但实际是 [5, 14]，不是 [5, 15] —— 范围长度算错
PostgreSQL和SQL Server的等效写法有啥区别？
各数据库对随机数的支持差异不小，不能直接套用 MySQL 写法。
- PostgreSQL：没有内置
RAND()，改用RANDOM()，行为一致（[0,1)），所以表达式结构相同：FLOOR(RANDOM() * (15 - 5 + 1)) + 5 - SQL Server：
NEWID()或CHECKSUM(NEWID())是常用替代，但需额外取模：(ABS(CHECKSUM(NEWID())) % 11) + 5—— 这里% 11对应 11 个数（5 到 15 共 11 个整数） - 注意：
CHECKSUM(NEWID())可能为负，必须套ABS()，否则模运算结果可能为负，破坏范围
在 WHERE 子句里用 RAND() 为什么每次查结果都不同？
因为 RAND() 在每一行上都会重新计算，导致过滤条件动态漂移 —— 这不是 bug，是设计如此。
- 典型陷阱：写
WHERE RAND() 想随机抽样 10%，但执行多次，返回行数和内容都可能变化 - 如果需要稳定抽样（比如测试环境复现），得用确定性种子：
RAND(123)，不过 MySQL 8.0.17+ 才支持常量种子；旧版本只能靠ORDER BY RAND() LIMIT N一次性取，但性能差 -
ORDER BY RAND()在大数据表上极慢，它会为每行计算一次随机值再全表排序，千万级表慎用
生成随机字符串或日期时，还能只靠 RAND() + FLOOR() 吗？
不能直接套用，但思路一致：先生成随机数，再映射到目标类型。
- 随机日期（如近30天内）：
DATE_SUB(CURDATE(), INTERVAL FLOOR(RAND() * 30) DAY)—— 注意用INTERVAL而非直接加减 - 随机字符串（如6位字母数字）：需配合字符串拼接和查表，
RAND()本身不输出字符，常见做法是用SUBSTRING('ABCDEFGHJKLMNPQRSTUVWXYZ23456789', FLOOR(RAND() * 33) + 1, 1)循环拼接 - 性能提醒：多层嵌套
SUBSTRING(..., FLOOR(RAND() * N) + 1, 1)在大结果集上开销明显，不如应用层生成再传入
真正麻烦的从来不是“怎么写出第一版”，而是当数据量上去、跨数据库迁移、或者需要可重现结果时，那些没显式声明的依赖和隐含假设——比如以为 RAND() 在所有上下文里都按行求值，其实某些优化器会提前折叠。
