ROW_NUMBER() 无法直接随机抽样，需配合 ORDER BY RAND()；MySQL 8.0 中窗口函数在排序后执行，故“每组抽N条”须先用 RAND() 打乱组内顺序，否则会固定取每组前N条。
ROW_NUMBER() 不能直接实现随机抽样，必须配合 ORDER BY RAND()
MySQL 8.0 支持 ROW_NUMBER()，但它本身不带随机性——窗口函数的执行顺序在排序之后，所以如果想“每组抽 N 条”，必须先打乱组内顺序。常见错误是写成 ROW_NUMBER() OVER (PARTITION BY category ORDER BY id)，结果抽到的永远是每组前 N 条固定记录。
正确做法是把 RAND() 塞进 ORDER BY 子句里：
SELECT * FROM (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY RAND()) AS rn
FROM products
) t WHERE rn <= 3;注意：这里 RAND() 在窗口排序中每次计算都生成新值，确保组内行顺序随机。但代价是无法使用索引，大数据量时性能明显下降。
抽样数量动态控制：用变量或参数替代硬编码
硬写 rn 不灵活，尤其当不同分组要抽不同数量（比如热门类目抽 5 条、冷门抽 1 条）时，得提前算好阈值。更实用的方式是预先聚合出各组目标样本数，再做 JOIN 或 LATERAL（MySQL 8.0.14+ 支持）。
简单场景下可用用户变量模拟动态阈值：
SET @sample_size := 3;
SELECT * FROM (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY RAND()) AS rn
FROM products
) t WHERE rn <= @sample_size;-
@sample_size必须在查询前显式SET，不能写成WHERE rn 占位符（PREPARE 语句中不支持窗口函数） - 若需按组差异化抽样，建议先建临时表存
category → target_count映射，再用JOIN+ 窗口函数过滤
ORDER BY RAND() 的性能陷阱和替代思路
对百万级以上表，ORDER BY RAND() 会触发全表扫描+内存排序，极易拖垮查询。不是所有场景都必须“绝对随机”，可考虑折中方案：
- 用
WHERE id % 100 = FLOOR(RAND() * 100)做哈希抽样（快但非均匀，适合预估） - 先用
SELECT id FROM products TABLESAMPLE SYSTEM (5)（MySQL 8.0.22+）快速取 5% 行，再在子集上分组抽样 - 业务允许前提下，改用应用层抽样：先查各组总行数，再用
OFFSET+LIMIT随机跳转（需配合主键范围估算）
真正需要统计级随机性且数据量大时，ROW_NUMBER() + ORDER BY RAND() 是最直白的解法，但务必加好 WHERE 过滤条件缩小初始数据集——比如先限定 status = 'active' 再抽样。
NULL 值和重复排序键导致的抽样偏差
如果分组字段（如 category）含 NULL，MySQL 会把所有 NULL 归为同一组——这常被忽略，导致“未知类目”被大量抽中。同样，若 ORDER BY RAND() 碰上并列值（虽然概率极低），ROW_NUMBER() 仍会强制分配唯一序号，但实际随机性已受损。
稳妥做法是显式排除或归类 NULL：
ROW_NUMBER() OVER ( PARTITION BY COALESCE(category, 'unknown') ORDER BY RAND() ) AS rn
- 用
COALESCE()或CASE统一处理空值，避免意外聚合 - 若表中存在大量重复
category+ 其他字段组合，建议先DISTINCT或加辅助排序字段（如ORDER BY RAND(), id）缓解并列问题
真正影响结果代表性的，往往不是语法写法，而是对 NULL 和数据分布的误判。
