MySQL中RAND()在UPDATE中默认每行只计算一次，导致同值覆盖；应加ORDER BY RAND()或用(SELECT RAND())强制逐行重算，PostgreSQL的RANDOM()虽逐行但需分批更新防锁表，SQL Server推荐CHECKSUM(NEWID())生成随机数。
MySQL里用RAND()直接更新字段为什么总“不动”？
因为UPDATE语句中，RAND()在每行执行时默认只计算一次（尤其在没有ORDER BY或子查询干预时），导致整批更新变成“同值覆盖”。这不是bug，是MySQL对非确定性函数的优化行为——它把RAND()当成了常量。
实操建议：
- 强制让
RAND()逐行重算：加ORDER BY RAND()（但注意性能代价） - 更稳妥的做法是用子查询包裹
RAND()，例如：(SELECT RAND())，MySQL无法将其提升为外层常量 - 如果字段是整数型，常用写法：
UPDATE t SET col = FLOOR(1 + RAND() * 100)，但需确认RAND()是否真被逐行调用
PostgreSQL怎么安全地随机更新字段而不锁全表？
PostgreSQL的RANDOM()是真正的逐行函数，不会被优化掉，但直接UPDATE ... SET col = RANDOM()会触发全表扫描+全行锁定，高并发下容易卡住。
实操建议：
- 加
LIMIT分批更新，比如每次只改1000行：UPDATE t SET col = RANDOM() WHERE ctid IN (SELECT ctid FROM t ORDER BY RANDOM() LIMIT 1000) - 用
ctid代替主键做定位，避免索引失效问题；但注意ctid在VACUUM后可能变化，仅适用于临时/离线场景 - 若需范围随机（如年龄18–65），写成：
ROUND(RANDOM() * 47 + 18)，RANDOM()返回[0,1)，所以乘数要减1
SQL Server里NEWID()和CRYPT_GEN_RANDOM()怎么选？
NEWID()生成GUID，适合做“随机排序”或“伪随机ID”，但不能直接转数值；CRYPT_GEN_RANDOM()是加密级随机字节，需配合CONVERT才能用于数值字段，且开销更大。
实操建议：
- 只要求“打乱顺序”或“取随机样本”：用
ORDER BY NEWID()，比如UPDATE TOP(100) t SET col = ABS(CHECKSUM(NEWID())) % 100 - 需要稳定分布的数值（如模拟测试数据）：优先用
CHECKSUM(NEWID())，它比NEWID()本身更容易转整数 - 避免在大表上用
ORDER BY NEWID()做全表随机排序——会爆内存，SQL Server没做流式随机算法
跨数据库统一写法不存在，但可避开最大陷阱
不同数据库对“随机函数是否逐行执行”的实现逻辑差异太大，硬写通用SQL只会踩坑。最常被忽略的是：你以为在更新“随机值”，其实只是在反复赋同一个值。
关键检查点：
- 执行前先
SELECT col, RAND() FROM t LIMIT 5（MySQL）或SELECT col, RANDOM() FROM t LIMIT 5（PG），看第二列是否真变化 - UPDATE后立刻
SELECT MIN(col), MAX(col), COUNT(DISTINCT col) FROM t，验证是否真随机分布 - 生产环境务必加
WHERE条件限定范围，哪怕只是WHERE id BETWEEN 1 AND 1000，防止误更新全表
随机不是玄学，是得盯着执行计划和结果集才敢信的细节。
