子查询中RAND()结果相同，因MySQL 5.7+对子查询物化优化致RAND()仅执行一次；正确做法是将RAND()置于主查询SELECT或ORDER BY中以绑定每行，避免隔离。
子查询里用 RAND() 为什么每次结果都一样？
直接在子查询中写 SELECT RAND() FROM table，再拿这个值去参与权重计算，大概率会得到全表统一的随机数——因为 MySQL（5.7+）对子查询中的 RAND() 做了物化优化，子查询只执行一次，结果被复用。PostgreSQL 则默认不缓存，但若子查询出现在 WHERE 或 JOIN 条件里且没关联外层，也可能被提前求值。
正确做法是让随机数生成「绑定到每行」：必须把 RAND() 放在主查询的 SELECT 或 ORDER BY 中，并确保它不被子查询隔离。
- ❌ 错误：
(SELECT RAND() FROM DUAL) AS r在子查询里独立生成 - ✅ 正确：主查询中写
RAND() * weight，或用ORDER BY RAND() * weight DESC LIMIT N - ⚠️ 注意：MySQL 8.0+ 的窗口函数不支持
RAND()作为排序依据，得先用派生表生成带随机权重的临时列
用子查询实现「按权重累积分布抽样」的可靠写法
真正可控的加权随机抽样，得模拟「轮盘赌」逻辑：先算权重累计和，再生成一个 [0, total_weight) 范围内的随机数，找第一个累计和 ≥ 它的记录。子查询在这里用来提供累计值，但必须避免物化陷阱。
以 MySQL 为例，推荐用变量模拟窗口函数（兼容 5.7）：
SELECT id, name, weight
FROM (
SELECT
id, name, weight,
@cum := @cum + weight AS cum_weight
FROM t, (SELECT @cum := 0) AS _
ORDER BY RAND()
) AS ranked
WHERE cum_weight >= RAND() * (SELECT SUM(weight) FROM t)
LIMIT 1;- 子查询内用
@cum累加，ORDER BY RAND()打乱原始顺序，防止偏差 - 外层
RAND() * SUM(weight)是真正的随机目标点，每次执行都重算 - ⚠️ 危险操作：把
SUM(weight)写成子查询放内层（如@cum := @cum + weight * (SELECT SUM(...)...)），会导致子查询重复执行、性能崩坏
PostgreSQL 怎么绕过子查询物化做加权抽样？
PG 不支持变量，但可以用 ROW_NUMBER() + UNNEST 展开权重，再用 ORDER BY RANDOM() 抽——前提是权重是整数且不太大；否则用 LATERAL 子查询强制按行求值。
安全写法（适用于任意浮点权重）：
SELECT id, name FROM t ORDER BY (weight * RANDOM()) DESC LIMIT 5;
但这是「概率性加权」，不是严格按累积分布抽样。要严格实现，必须用 LATERAL 配合子查询生成动态阈值：
SELECT id, name FROM t CROSS JOIN LATERAL ( SELECT SUM(weight) AS total FROM t ) AS s CROSS JOIN LATERAL ( SELECT RANDOM() * s.total AS target ) AS r WHERE ( SELECT SUM(t2.weight) FROM t AS t2 WHERE t2.id <= t.id -- 需有唯一有序字段，或改用 ctid + 窗口函数 ) >= r.target LIMIT 1;
-
LATERAL确保RANDOM()和SUM()对每一行都重新执行（实际只用一次，但语义上绑定） - ⚠️ 没有索引时，
WHERE中的子查询会变成 O(N²)，大数据量务必加索引或改用 CTE 预计算累计值
为什么不能直接用 WHERE RAND() ？
这种写法看似直观，实则严重偏离预期权重：它对每行独立掷一次「是否入选」的硬币，导致最终抽样数量浮动极大，且无法控制样本量（比如你想要固定 10 条，它可能返回 3 条或 17 条）。
- ✅ 适合场景：标记「该行有 weight/total 概率被日志记录」这类异步采样
- ❌ 不适合场景：A/B 测试分组、报表抽样、训练集切分——这些要求精确样本数 + 加权代表性
- ? 替代思路：用
ROW_NUMBER() OVER (ORDER BY RAND() * weight DESC)再取前 N 行，简单、可预测、多数引擎都支持
加权随机抽样的核心矛盾从来不在语法，而在「确定性控制」和「随机性来源」的耦合方式——子查询只是工具，关键看它在哪一层、以什么粒度触发 RAND()。稍不注意，就变成伪随机或性能黑洞。
