我会尝试描述我的情景：
集合中的每个文档都有一系列元素：["element X", "element Y"...]
最终用户希望找到与他选择的元素数组最匹配的集合。
用户元素数组：["Element foo, element bar, element w"]
我所做的是在查询中使用$ all - 从原始用户数组开始，然后是所有排列（所有n-1个元素的可能性，所有n-2个元素的可能性等等），直到我得到他为50结果
当然我索引了数组的字段，一切正常。
问题是 - 我有一个用户输入了超过40个元素...这导致了一个慢查询"millis" : 125根据分析而不是mongoDB被卡在100％CPU上直到重新启动。
我一遍又一遍地看到这个问题，直到重启。
所以我的问题分为两个问题：
技术 - 为什么查询会继续重试？好的 - 这是一个艰难而缓慢的查询，但是我可以通过不必要的配置重试来阻止它吗？
算法 - 任何人都知道这个问题的优雅解决方案，而不会限制用户使用搜索中的元素数量？
代码段：（PHP）
$combinations_array = $this->combinations($elements_array, $current_match_count);
foreach ($combinations_array as $combination)
{
$query = array( 'element.name' => array('$all' => $combination ) ) ;
$cursor = $collection->find($query);
}
其中combinations是一个输出大小为$current_match_count