没有一个解决方案对我有效。尤其是当缝隙多、集小的时候。 这对我来说很好(在php中):

$count = $collection->count($search);
$skip = mt_rand(0, $count - 1);
$result = $collection->find($search)->skip($skip)->limit(1)->getNext();

下面的方法比mongo烹饪书解决方案稍慢(在每个文档上添加一个随机键)，但是返回分布更均匀的随机文档。与跳过(随机)解决方案相比，它的分布稍微不那么均匀，但在删除文档时要快得多，而且更安全。

function draw(collection, query) {
    // query: mongodb query object (optional)
    var query = query || { };
    query['random'] = { $lte: Math.random() };
    var cur = collection.find(query).sort({ rand: -1 });
    if (! cur.hasNext()) {
        delete query.random;
        cur = collection.find(query).sort({ rand: -1 });
    }
    var doc = cur.next();
    doc.random = Math.random();
    collection.update({ _id: doc._id }, doc);
    return doc;
}

它还要求您添加一个随机的“random”字段到您的文档中，所以不要忘记在创建它们时添加这个:您可能需要初始化您的集合，如Geoffrey所示

function addRandom(collection) { 
    collection.find().forEach(function (obj) {
        obj.random = Math.random();
        collection.save(obj);
    }); 
} 
db.eval(addRandom, db.things);

基准测试结果

该方法比(ceejayoz)的skip()方法快得多，并且比Michael报告的“cookbook”方法生成更均匀的随机文档:

对于包含1,000,000个元素的集合:

这种方法在我的机器上花费的时间不到1毫秒 skip()方法平均花费180毫秒

cookbook方法将导致大量文档永远不会被选中，因为它们的随机数对它们不利。

该方法将在一段时间内均匀地挑选所有元素。 在我的基准测试中，它只比食谱方法慢了30%。 随机性并不是100%完美的，但是它已经很好了(如果有必要的话还可以进行改进)

这个配方并不完美——正如其他人所指出的那样，完美的解决方案将是内置功能。 然而，对于许多目的来说，这应该是一个很好的折衷方案。

下面的聚合操作从集合中随机选择3个文档:

db.users.aggregate ( [{$sample: {size: 3}}] )

https://docs.mongodb.com/manual/reference/operator/aggregation/sample/

我建议使用map/reduce，其中使用map函数只在随机值高于给定概率时发出。

function mapf() {
    if(Math.random() <= probability) {
    emit(1, this);
    }
}

function reducef(key,values) {
    return {"documents": values};
}

res = db.questions.mapReduce(mapf, reducef, {"out": {"inline": 1}, "scope": { "probability": 0.5}});
printjson(res.results);

上面的reducef函数可以工作，因为map函数只发出一个键('1')。

“probability”的值在“scope”中定义，当调用mapRreduce(…)

像这样使用mapReduce在分片数据库上也可以使用。

如果你想从db中选择n (m)个文档，你可以这样做:

function mapf() {
    if(countSubset == 0) return;
    var prob = countSubset / countTotal;
    if(Math.random() <= prob) {
        emit(1, {"documents": [this]}); 
        countSubset--;
    }
    countTotal--;
}

function reducef(key,values) {
    var newArray = new Array();
for(var i=0; i < values.length; i++) {
    newArray = newArray.concat(values[i].documents);
}

return {"documents": newArray};
}

res = db.questions.mapReduce(mapf, reducef, {"out": {"inline": 1}, "scope": {"countTotal": 4, "countSubset": 2}})
printjson(res.results);

其中“countTotal”(m)是数据库中的文档数量，“count子集”(n)是要检索的文档数量。

这种方法可能会在分片数据库上产生一些问题。

当我面对类似的解决方案时，我回溯并发现业务请求实际上是为了创建所呈现的库存的某种形式的轮换。在这种情况下，有更好的选择，它们有来自Solr这样的搜索引擎的答案，而不是MongoDB这样的数据存储。

In short, with the requirement to "intelligently rotate" content, what we should do instead of a random number across all of the documents is to include a personal q score modifier. To implement this yourself, assuming a small population of users, you can store a document per user that has the productId, impression count, click-through count, last seen date, and whatever other factors the business finds as being meaningful to compute a q score modifier. When retrieving the set to display, typically you request more documents from the data store than requested by the end user, then apply the q score modifier, take the number of records requested by the end user, then randomize the page of results, a tiny set, so simply sort the documents in the application layer (in memory).

如果用户的范围太大，可以将用户划分为行为组，按行为组而不是按用户进行索引。

如果产品范围足够小，您可以为每个用户创建一个索引。

我发现这种技术效率更高，但更重要的是在创建相关的、有价值的软件解决方案使用体验方面更有效。

为了获得确定数量的无重复的随机文档:

first get all ids get size of documents loop geting random index and skip duplicated number_of_docs=7 db.collection('preguntas').find({},{_id:1}).toArray(function(err, arr) { count=arr.length idsram=[] rans=[] while(number_of_docs!=0){ var R = Math.floor(Math.random() * count); if (rans.indexOf(R) > -1) { continue } else { ans.push(R) idsram.push(arr[R]._id) number_of_docs-- } } db.collection('preguntas').find({}).toArray(function(err1, doc1) { if (err1) { console.log(err1); return; } res.send(doc1) }); });