假设我有一个具有固定数量条目的mongo集合，其数量永远不会超过300-400。 例如：
User{
String name;
String phoneNumber;
String address;
String dob;
Integer noOfCars;
}
在这些字段中，我想索引name和phoneNumber。
是否建议为这种小型集合创建索引？该决定是否完全取决于收集的大小？它取决于我想要创建的索引数量吗？
答案 0 :(得分：3)
没关系。我刚试了一个包含384个条目的样本集合。根据{{1}}，索引扫描需要0毫秒，而第一次集合扫描需要2毫秒 - 每次后续采集扫描也需要0毫秒。
这个决定是否完全取决于收集的大小？
是的，索引的想法是它增加了创建和更新数据的成本，这些成本通过更快地进行查询来分摊。特别是，一个简单的列表具有O（1）的渐近插入性能和O（N）的搜索时间，而B-Tree对于两者都有O（log n），即我们接受较慢的插入，因为我们假设我们读取比我们写的更频繁，或者数据太大以至于即使少数O（N）读数也会影响性能，即如果N>＆gt;记录N。
只有几百个元素，所有这些都不重要，因为log n和n之间的差异很小，并且因为更复杂的算法的运行时间开销（即常量） 因Landau-Notation隐藏的因素，因为它在很大程度上取决于实施，因此在同一个联盟中发挥作用。这同样适用于您的代码：将200个元素放入哈希表中没有意义，列表迭代甚至可能更快，因为它避免了分支。
如果文档非常庞大，那么集合扫描将需要处理更多数据（而不仅仅是查看索引）。
答案 1 :(得分：3)
是否建议为这种小型集合创建索引？
这可能是一种观点，因为集合太小而且数据库可能对这些小集合进行了优化。我的意见是做到这一点，但有利有弊。
con：增加系统复杂性。这类似于更多的LOC，你可能有更多的错误。
亲：如果使用量增加或收集量增加，未来将对收集进行验证。
这个决定是否完全取决于收集的大小？
是的。除非在这样小的集合上可能发生任何数据库优化，否则它还取决于使用情况。
是否取决于我想要创建的索引数量？
更多索引会增加写入时间，但这需要针对您的特定设置进行测试。没有什么能比真正的测试更好，因为有很多因素在起作用。我知道在以前的项目中我们已经使用了TokuMX for MongoDB并且看到了令人惊叹的写入性能...使用Toko的2分钟与使用19个索引编写500k条目的常规mongo的12分钟。
答案 2 :(得分：0)
我认为你应该这样做。持久存储几乎不是问题。小集合的索引也很小。它还取决于查询量。如果查询量很大，那么即使对单个查询进行微小改进也会汇总到巨大的性能提升。