使用MongoDB聚合$sample无法从全集合随机选取文档的问题

首先，咱们先拆解你遇到的问题：你的场景完全符合MongoDB 4.2.x中$sample使用伪随机游标的三个触发条件（$sample是管道首阶段、size=1小于328的5%（≈16）、文档数>100），但抽样结果却严重偏向_id≤251的文档，甚至连_id=1都没出现过。这本质上是MongoDB 4.2版本中$sample伪随机游标实现的抽样偏差问题，和存储引擎的文档分布直接相关。

为什么会出现覆盖不全的情况？ #

MongoDB 4.2中，当触发伪随机游标逻辑时，WiredTiger存储引擎的随机游标是基于数据页面做随机选择的：它会先随机挑一个数据页，再从页内随机选文档。如果你的文档是按_id连续插入的（1到328），这些文档会被连续存储在相邻的数据页中。而4.2版本的随机游标算法在小集合场景下，可能无法均匀遍历所有数据页——比如你的前251条文档占了大部分被随机选中的页面，后面的77条所在的页面几乎没被抽到，才会出现10000次测试都没覆盖到的情况。

另外，_id=1没被抽到可能是因为它在第一个数据页的开头，而随机游标在页内选择时的算法也存在小概率遗漏的情况，叠加页面选择的偏差，就导致它完全没被选中。

代码调整方案 #

针对你的场景，有两种可行的调整方式，既保证随机性覆盖全集合，又不会有太大性能损耗：

方案1：强制$sample使用全集合扫描+随机排序 #

既然伪随机游标有偏差，那我们可以打破它的触发条件，让MongoDB改用全集合扫描后随机排序的方式。只需要在$sample前加一个无意义的阶段，让$sample不再是管道的首阶段即可：

async findOneRandom(collection) {
  try {
    // 用$match匹配所有文档，让$sample不再是首阶段
    return await this.db.collection(collection).aggregate([
      { $match: {} },
      { $sample: { size: 1 } }
    ]).toArray();
  } catch (error) {
    console.log(error.stack);
    return null;
  }
}

这样MongoDB就会放弃伪随机游标，转而扫描全集合、随机排序后取第一条。对于328条文档来说，这个性能开销完全可以忽略，而且能保证覆盖所有文档。

方案2：手动实现随机抽样（适合小集合） #

如果不想依赖$sample，也可以手动生成随机偏移量来获取文档：

async findOneRandom(collection) {
  try {
    // 先获取集合总文档数
    const count = await this.db.collection(collection).countDocuments();
    // 生成0到count-1的随机数
    const randomSkip = Math.floor(Math.random() * count);
    // 跳过randomSkip条，取第一条
    return await this.db.collection(collection).find().skip(randomSkip).limit(1).toArray();
  } catch (error) {
    console.log(error.stack);
    return null;
  }
}

这个方法的好处是逻辑直观、完全可控，缺点是如果集合非常大（比如百万级以上），skip会导致性能下降，但你的集合只有328条，完全没问题。

关于$sample伪随机实现的细节 #

再补充一下你关心的伪随机实现：当满足三个触发条件时，MongoDB的$sample会调用存储引擎的随机游标（Random Cursor）。这个游标不需要遍历全集合，而是直接从存储层随机选取数据页，再从页内随机选文档，性能非常高（时间复杂度O(size)）。但它的随机性依赖于文档在存储层的分布：

• 如果文档是随机写入的（比如_id是ObjectId），数据页的内容比较分散，抽样会相对均匀；
• 如果文档是连续写入的（比如自增_id），数据页是连续的，在小集合场景下，随机游标可能无法覆盖所有页面，导致抽样偏差。

这个问题在MongoDB 4.4及以上版本中已经得到了优化，后续版本的$sample伪随机游标算法改进了页面选择逻辑，减少了这种偏差。如果条件允许，升级到更高版本的MongoDB也是一个长期的解决方案。

内容的提问来源于stack exchange，提问作者Andrew Chart