MySQL 8.0+ 分组随机抽样的正确方法是：使用 ROW_NUMBER() OVER (PARTITION BY category ORDER BY RAND()) 为每组内记录分配随机序号，再筛选 rn = 1 的行；错误做法包括外层 ORDER BY RAND()、GROUP BY 配合 MAX(id) 或 GROUP_CONCAT，均无法保证真正随机且语义错误。
MySQL 8.0+ 用 ROW_NUMBER() + RAND() 实现分组随机抽样
直接结论：在 MySQL 8.0 及以上，ROW_NUMBER() OVER (PARTITION BY ... ORDER BY RAND()) 是最可靠、语义清晰的方案。它先对每组内记录打乱顺序，再编号，最后取每组 rn = 1 的行。
常见错误是写成 ORDER BY RAND() 放在最外层——这会先全表打乱再分组，结果不是“每组一条”，而是不可控的任意行数；还有人误用 GROUP BY 配合 MIN(id)，本质是取最小 ID，完全不随机。
- 必须把
RAND()放在窗口函数的ORDER BY子句里，且不能加其他确定性排序字段（比如ORDER BY category, RAND()会因category稳定导致同组多次执行结果相同） - 窗口函数只支持 MySQL 8.0+ 和 PostgreSQL；MariaDB 10.2+ 也支持，但旧版 MySQL（5.7 及之前）不支持，需换方案
- 性能注意：全表扫描 + 每组内部排序，数据量大时较慢；若只是偶尔执行或百万级以下，可接受
SELECT * FROM (
SELECT *,
ROW_NUMBER() OVER (PARTITION BY category ORDER BY RAND()) AS rn
FROM products
) t WHERE rn = 1;PostgreSQL 用 DISTINCT ON + ORDER BY RANDOM()
PostgreSQL 提供了更简洁的语法：DISTINCT ON 先按指定列去重，配合 ORDER BY ... RANDOM() 控制“保留哪一条”。它天然适合分组抽样，且无需子查询。
容易踩的坑是漏掉 ORDER BY 中的分组字段——DISTINCT ON (category) 要求 ORDER BY 最左字段必须是 category，否则报错；另外 RANDOM() 必须出现在 ORDER BY 中，不能只靠 WHERE 过滤。
-
DISTINCT ON返回的是“每组第一条”，所以ORDER BY category, RANDOM()才能保证每组内随机选 - 如果还想返回原表所有字段，必须把
category放在ORDER BY开头，后面接RANDOM()，其他字段顺序不影响结果 - 相比窗口函数，这个写法更轻量，执行计划通常更优，尤其在有
category索引时
SELECT DISTINCT ON (category) * FROM products ORDER BY category, RANDOM();
MySQL 5.7 或 SQLite 等不支持窗口函数的场景
只能退回到“关联子查询 + LIMIT 1”模式，但要注意：MySQL 5.7 不允许子查询里直接用 LIMIT 配合外部引用，必须包装成派生表；SQLite 则支持 LIMIT 直接写在子查询里。
性能差是最大问题——对主表每行都执行一次子查询，O(n²) 复杂度；数据超 1 万行就明显卡顿。线上环境慎用，仅限临时查或小表。
- MySQL 5.7 正确写法：子查询用
(SELECT * FROM ... WHERE group_col = t.group_col ORDER BY RAND() LIMIT 1)会报错，必须改成(SELECT * FROM (SELECT ... ORDER BY RAND() LIMIT 1) AS tmp) - SQLite 可直接写
(SELECT * FROM products p2 WHERE p2.category = p1.category ORDER BY RANDOM() LIMIT 1) - 所有方案中，这是唯一可能重复返回同一行（虽然概率低），因为
RAND()在子查询里每次独立生成，无法保证组内真正“只选一次”
-- MySQL 5.7 示例（注意双层括号）
SELECT p1.* FROM products p1
WHERE p1.id = (
SELECT id FROM (
SELECT id FROM products p2
WHERE p2.category = p1.category
ORDER BY RAND() LIMIT 1
) AS tmp
);为什么不能用 GROUP BY + AGGREGATE(比如 MAX(id)) 模拟随机？
因为 MAX(id)、MIN(name) 这类聚合函数返回的是确定值，和随机无关。有人试图用 GROUP_CONCAT(id ORDER BY RAND()) 再 SUBSTRING_INDEX 截取第一个，看似随机，实则隐患极大：
-
GROUP_CONCAT有长度限制（默认 1024 字符），超长组会截断，导致取不到真实 ID - 字符串拼接后取子串，无法保证类型安全；若 ID 是 UUID 或含逗号，解析直接失败
- MySQL 5.7 默认不开启
sql_mode=ONLY_FULL_GROUP_BY时，SELECT *配合GROUP BY会返回非确定性行，看起来像随机，其实是引擎随意选的，不可靠也不可移植
真要兼容老版本且不能接受性能损耗，优先考虑应用层分组后随机取——查出全部分组数据，用 Python/JS 在内存里按组 shuffle 再取首项，比 SQL 黑魔法更稳。
