OFFSET + LIMIT 分组随机抽样极慢，因需全量分组、排序并跳过大量行；应改用窗口函数（如ROW_NUMBER() OVER PARTITION BY...ORDER BY RANDOM()）或预置哈希列实现高效抽样。
OFFSET + LIMIT 在大表分组随机抽样时为什么慢得离谱
因为 OFFSET 会强制数据库扫描并跳过前面所有行——哪怕你只要第 100 万行之后的 1 条。对一个按 GROUP BY category 后有上百万组的大表，如果先 GROUP BY 再 OFFSET，执行计划往往触发全量分组+排序+跳行，I/O 和 CPU 双爆表。
真正可行的“分组内随机抽样”替代方案
别指望靠 OFFSET 实现“每组抽 N 条随机样本”，它不是为这个设计的。正确路径是用窗口函数或子查询控制每组内部的随机序号：
-
ROW_NUMBER() OVER (PARTITION BY category ORDER BY RANDOM())（PostgreSQL）或ORDER BY RAND()（MySQL）给每组内行打乱序号 - 外层只取
rn 这类条件，避免跳行逻辑 - 若数据库不支持窗口函数（如旧版 MySQL），改用
JOIN自关联 + 子查询生成每组最小随机 ID，再回表取值
硬要用 OFFSET/LIMIT？至少避开这几个坑
如果业务强依赖 LIMIT + OFFSET（比如分页式抽样），必须配合物理优化：
- 确保
ORDER BY字段有索引，且该字段分布均匀（别用单调递增的id直接ORDER BY id OFFSET x LIMIT 1） - 用游标替代偏移：记录上一页最后的
random_score值，下一页查WHERE random_score > ? ORDER BY random_score LIMIT 10 - 提前在表里加一列
sample_hash INT DEFAULT (FLOOR(RANDOM()*100))，抽样时直接WHERE sample_hash = 7，误差可控且毫秒级
不同数据库对 RANDOM() 的行为差异很关键
RANDOM() 不是标准 SQL 函数，各库实现不同：
- PostgreSQL：每次调用返回新值，
ORDER BY RANDOM()真随机 - MySQL：
ORDER BY RAND()在GROUP BY后可能被优化掉，需包裹成(SELECT RAND())强制重算 - SQLite：
RANDOM()是整数，需ABS(RANDOM()) % 1000模拟浮点效果 - SQL Server：用
NEWID()替代，但注意它不可重复读，多次执行结果不一致
没测过目标数据库的 RANDOM() 行为就写分组抽样，大概率抽到同一组的固定几条——因为优化器悄悄把随机计算上提或缓存了。
