MongoDB性能问题：单个大型集合与多个小型集合

我测试了两种场景：单个大集合和多个小集合，发现查询时的性能有很大差异。这就是我所做的

案例1：我为10种不同类型的产品创建了一个包含1000万条记录的产品集合，在这个集合中，每种产品类型正好有100万条记录，我创建了ProductType索引。当我在条件ProductType=1、ProductPrice>100和limit（10）下运行一个示例查询以返回ProductType=1且其价格大于100的10条记录时，当集合中有许多价格大于100的产品时，大约需要35毫秒，而相同的查询大约需要8000毫秒（8秒）当我们的ProductType=1中价格大于100的产品数量非常少时

案例2：我为每个产品类型创建了10个不同的产品表，每个表包含100万条记录。在包含productType 1记录的集合1中，当我在条件ProductPrice>100和limit（10）下运行相同的示例查询以返回10条价格大于100的产品记录时，当集合中有很多价格大于100的产品时，大约需要2.5毫秒，当我们拥有的价格高于100的产品数量非常少时，同样的查询大约需要1500毫秒（1.5秒）

那么为什么会有这么大的差异呢？案例一和案例二之间的唯一区别是一个巨大的集合与多个较小的集合，但我在第一个案例中创建了ProductType索引一个巨大的集合。我猜性能差异是由第一种情况下的索引引起的，在第一种情况下我需要该索引，否则性能会更差。由于指数的原因，我预计在第一种情况下会有一些性能下降，但我没想到在第一种情况下会有10倍左右的巨大差异

---

因此，一个大型集合与多个小型集合的时间分别为8000毫秒与1500毫秒。为什么？

分离集合可以为您提供免费索引，而不会产生任何实际开销。索引扫描有一定的开销，尤其是如果索引没有真正帮助您减少必须扫描的结果数量（如果索引中有一百万个结果，但您必须扫描并检查它们，这对您没有多大帮助）

简而言之，分离它们是一种有效的优化，但是在你真正决定采用那个路线之前，你应该让你的索引更好，我认为这是一个激烈的措施（产品价格的指数在这种情况下可能对你有帮助）。

---

使用explain（）可以帮助您了解查询是如何工作的。一些基本原则是：理想情况下，您需要一个较低的n扫描比。通常情况下，您不需要scanander=true，也不需要BasicCursor（这意味着您根本不使用索引）。

Case 1://这里我查询的是一个大集合，ProductType=1db.AllTogather.find的所有记录中都有匹配项（{ProductType:10003，“Data.D_3”：/ksdhfkjsda/}）。explain（）{“cursor”：“BtreeCursor ProductType\u 1”，“isMultiKey”：false，“n”：1000000，“nscannedObjects”：1000101，“nscanned”：1000101，“scanander”：false，“indexOnly”：false，“nYields”：4，“nChunkSkips”：0，“milis”：4016，“indexBounds”：{“ProductType”：[[1000310003]}，“server”：“ANANDD:27017”}案例2://这里我查询的是包含ProductType=1的所有记录的较小集合，所有记录中都有匹配项>db.ProductType_10003.find（{“Data.D_3”：/ksdhfkjsda/}）。explain（）{“cursor”：“BasicCursor”，“isMultiKey”：false，“n”：1000000，“nscannedObjects”：1000000，“nscanned”：1000000，“scanander”：false，“indexOnly”：false，“nYields”：2，“nChunkSkips”：0，“millis”：1876，“indexBounds”：{}，“server”：“ANANDD:27017”}您真的需要查询像这样的特定产品类型的所有结果吗？或者您想对它们进行排序，并按某个值限制到前100名，或者什么的。不，我确实需要限制和跳过。