RAND()直接用于UPDATE的WHERE子句会失效，因为RAND()在每行评估时都重新计算，导致条件结果不可预测且不一致，无法稳定匹配目标行；MySQL优化器可能将其视为非确定性表达式而拒绝执行或产生意外行为。
为什么 RAND() 直接用在 UPDATE 里会失效
很多用户写 UPDATE t SET x = 'a' WHERE RAND() ，发现每次执行更新的行数不稳定，甚至有时一行都不更新——这不是 bug，而是 MySQL（及多数数据库）对 RAND() 的求值时机决定的：RAND() 在每行判断时**不重新计算**，而是在语句开始前只算一次。结果就是整条 WHERE 条件变成固定真假值，要么全更新、要么全跳过。
正确做法：用子查询或派生表强制逐行重算 RAND()
必须让数据库为每一行独立生成随机数。MySQL 8.0+ 可直接在 UPDATE 中嵌套 SELECT；低版本需借助变量或临时表。最通用且安全的方式是：
UPDATE t JOIN ( SELECT id FROM t ORDER BY RAND() LIMIT 100 ) AS r ON t.id = r.id SET t.status = 'processed';
这个写法的关键点：
-
ORDER BY RAND() LIMIT N是真正按比例采样的核心：先打乱全表，再取前 N 行 - 用
JOIN而非WHERE id IN (SELECT ...)，避免某些 MySQL 版本对子查询中RAND()的优化误判 - 若要按百分比（比如 5%），得先算出目标行数：
SELECT CEIL(COUNT(*) * 0.05) FROM t，再代入LIMIT - 注意
id必须有索引，否则ORDER BY RAND()会触发全表排序，大表极慢
PostgreSQL 和 SQL Server 怎么做
不同数据库语法差异明显，不能套用 MySQL 写法：
- PostgreSQL：直接支持
TABLESAMPLE，更高效：UPDATE t SET status = 'done' WHERE ctid IN (SELECT ctid FROM t TABLESAMPLE SYSTEM (5))—— 这里的5是近似百分比，SYSTEM是块级采样，速度快但不精确；如需严格行数，改用ORDER BY RANDOM() LIMIT N - SQL Server：用
TOP N PERCENT+ORDER BY NEWID()：UPDATE TOP (5) PERCENT t SET status = 'sent' FROM t ORDER BY NEWID()；注意TOP后不能跟小数，所以 5% 得写成TOP (5) PERCENT，不是0.05 - 所有方案都默认假设表有主键或唯一标识列，否则无法精准定位要更新的行
更新量不准、性能差？先检查这三件事
实际跑起来发现“明明设了 10%，结果更新了 23 行”，或者卡住十几秒没反应，大概率是：
- 没加
WHERE过滤条件就对全表ORDER BY RAND()—— 百万级表会把整个表读进内存排序，CPU 和 I/O 都爆掉 - 用了
RAND() * 100 这类表达式，却忘了它在大多数数据库里仍只计算一次（尤其 SQLite、旧版 MySQL） - 目标字段无索引，导致
JOIN或IN操作变成嵌套循环，复杂度从 O(N) 变成 O(N²)
真正可控的比例更新，本质是「先抽样、再定位、最后更新」三步分离，任何想一步到位的写法，在大数据量下都容易翻车。
