我测试了两个场景Single Huge collection vs Multiple Small Collections，并在查询时发现了巨大的性能差异。这就是我所做的。
案例1：我创建了一个产品集合，其中包含10种不同类型产品的1000万条记录，而且每种产品类型的记录都是100万条，我在ProductType上创建了索引。当我运行条件ProductType = 1和ProductPrice＆gt; 100并且限制（10）的示例查询返回10个ProductType = 1且价格大于100的记录时，当集合中有很多产品的价格时花了大约35毫秒如果ProductType = 1的产品数量非常少，且价格大于100，那么同样的查询大约需要8000毫秒（8秒）。
案例2：我为每个ProductType创建了10个不同的Product表，每个ProductType包含100万条记录。在包含productType 1记录的集合1中，当我运行条件为ProductPrice＆gt; 100且限制（10）的相同样本查询以返回价格大于100的产品的10条记录时，当集合有很多时，它花了大约2.5毫秒价格超过100的产品，当价格大于100的产品数量非常少时，同样的查询大约需要1500毫秒（1.5秒）。
那为什么会有这么大的差异呢？案例一和案例二之间的唯一区别是一个巨大的集合与多个较小的集合，但我在第一个案例中创建了一个单一巨大集合的ProductType索引。我猜性能差异是由第一种情况下的索引引起的，我在第一种情况下需要该索引，否则性能会更差。我预计在第一种情况下由于指数会有一些表现缓慢但我没想到在第一种情况下差异大约10倍。
一个巨大的集合与多个小集合相比，8000毫秒对1500毫秒。为什么呢？
答案 0 :(得分：14)
分隔集合为您提供免费索引，没有任何实际开销。索引扫描会有开销，特别是如果索引并没有真正帮助您减少必须扫描的结果数量（如果索引中有一百万个结果，但您必须全部扫描并检查它们，这对你没什么帮助。）
简而言之，将它们分开是一种有效的优化，但在实际决定采用该路线之前，您应该使您的指数更好地适用于您的查询，我认为这是一个极端的措施（产品价格指数可能对您有所帮助）这种情况）。
使用explain（）可以帮助您了解查询的工作方式。一些基础知识是：理想情况下，您需要较低的nscanned与n的比率。您不希望scanAndOrder = true，并且您通常不需要BasicCursor（这意味着您根本不使用索引）。