$sample 是 mongodb 5.0+ 唯一稳定实现无偏随机采样的原生方式，依赖\_id索引优化、文档数＞100、size≤总量5%且位于管道首阶段；不满足则退化为全表扫描+排序，易内存溢出或结果偏差。
$sample 是 MongoDB 5.0+ 中唯一能稳定实现无偏随机采样的原生方式，但“无偏”不等于“绝对均匀”，它依赖输入流和参数设置是否合理。
为什么 $sample 在 5.0+ 才真正可靠
MongoDB 5.0 起，$sample 底层引入了对 _id 索引的隐式利用路径（非强制走索引，但具备优化条件），在满足前提时可避免全表扫描；此前版本（如 4.4）即使写 {$sample: {size: 10}}，也大概率触发 COLLSCAN + 随机跳过，I/O 开销大且结果易偏向新文档。
关键前提有三个：
- 集合文档数 > 100
-
size≤ 集合总文档数的 5% -
$sample是聚合管道的第一个阶段（或前面只有$changeStream这类元数据阶段）
不满足任一条件，MongoDB 就会退化为“全读 + $sort + $limit”，受 maxSortKeyMemoryUsageBytes（默认 100MB）限制，可能直接报错 Sort exceeded memory limit。
如何避免采样结果有偏
所谓“无偏”，是指每条文档被抽中的概率严格相等。但实际中容易因以下原因失效：
-
$match放在$sample前面 → 抽的是过滤后子集的随机样本，不是全量无偏；放在后面 → 可能抽不到足够数量（比如{$sample: {size: 100}}, {$match: {status: "paid"}}，最终返回少于 100 条） - 用
_id索引加速时，若写入集中在最近几小时（如日志系统），ObjectId的时间戳成分会导致新文档密集堆积在索引尾部，$sample的伪随机游标更可能命中这部分，造成时间偏差 - 分片集群下，
mongos对各 shard 的样本再做一次合并采样，若某 shard 文档极少，它贡献的样本数可能为 0，导致整体分布失衡
真要逼近统计学意义的无偏，最稳方案是：插入时加一个 rand 字段（值为 Math.random()），并建索引 {rand: 1}，然后用 {$sample: {size: N}} —— 此时 MongoDB 可高效利用该索引跳转，且 rand 均匀性由应用层保障。
size 参数设多少才安全
size 不是越大越好，它直接决定执行策略：
- 集合有 200 万文档，
size: 10000（占 0.5%）→ 启用蓄水池抽样（reservoir sampling），内存占用低，毫秒级完成 - 同样 200 万文档，
size: 150000（占 7.5%）→ 强制全读 + 排序，若单条文档平均 1KB，光加载就需 200MB 内存，大概率触发内存限制报错 - 集合仅 500 文档，
size: 100→ 即使只占 20%，也会退化为全读排序，因为总量未过 100 文档阈值
生产环境建议把 size 控在 ≤1000；超过这个量，先问自己：是不是真需要“随机”，还是用 $mod（如 {$expr: {$eq: [{$mod: ["$_id", 100]}, 0]}}）做确定性分桶更可控、更快、更可复现？
别踩 $sampleRate 的坑
有人看到 Azure Cosmos DB 文档里有 $sampleRate，就以为本地 MongoDB 也能用 {$match: {$sampleRate: 0.1}} —— 这会直接报错 unknown operator: $sampleRate。原生 MongoDB 从不支持该操作符。
如果你需要按概率采样（比如“每条日志有 1% 概率被保留”），正确写法是：
db.logs.aggregate([
{$addFields: {rand: {$rand: {}}}},
{$match: {rand: {$lt: 0.01}}}
])
但注意：$rand 每次调用都生成新值，无法与 $sample 组合用于固定数量抽样；且该方式不保证最终条数，只保证期望值。
真正容易被忽略的点是：你写的 $sample 看似在管道开头，但如果作用在视图（view）上，MongoDB 会自动把它拼接到视图定义的聚合末尾——此时它已不是第一阶段，必然退化为全扫。查视图定义用 db.getCollectionInfos({name: "your_view"})，确认 pipeline 字段内容。
