第二，更重要的是，这些索引的建议对你的应用提高也是有限的。
对于应用的最佳索引策略应该基于很多的重要因素。包含了你期望查询的类型，
数据读取与写入的比率，甚至于你服务器的空闲内存。意思就是，
需要对线上的产品做很多的测试剖析工作，才能调整出最佳的索引策略。
没有什么好的方法可以替代实际经验的。
注意: 如果你是个新手，建议阅读read this introductory article first.
下面有些索引的基本法则
如果你仅仅要查询单个字段。索引这个字段即可。如
db.posts.find({ slug : 'state-of-mongodb-2010' })
这个例子中，唯一索引是最佳的
然而，一般都查询多个键并且排序结果。这种情况，组合索引是最佳的，例子如下
创建的索引如下
要注意的是如果我们按照升序排序created_at。索引效率就低下了。
有的时候查询多个键，需要多个索引。在MongoDB中，这么做没问题。
如果你有个查询要匹配多个键，并且你想更有效地使用索引，请使用组合索引。
Shell中提供了一个查看索引大小的命令，如下:
65443
如果你的查询有点迟缓，你应该查看下索引是否都存入到RAM中了。
一个实例，如果你运行在4GB的RAM机器并且有3GB的索引，那么索引可能并不能全存在RAM中。
你需要添加RAM以及/或者校验实际的索引使用量。
假使你有个字段叫做'status'，就有两个值new和processed。
如果在status上创建索引那么这就是个低选择性的索引。
意味着，查询中没有什么优势并且还占大量的空间。
一个更好一点的策略，当然依赖具体查询需求，可以创建组合索引包括这个低选择性的字段。
举例来说，你可以创建一个组合索引在status和created_at字段上。
另一个选择，当然也依赖你的需求,可以分离collection,一个状态一个。
当然这些建议一定要进行测试，选择最优的方案。
explain输出主要有三个字段：
如果你的应用是偏向于读取，使用索引是非常好的事情。
但是如果你的应用偏向于写，那么创建索引就要小心了。增加索引都很影响写入的性能。
添加索引的理由总是很多的,以及要进行大量的测试选择合适的索引策略。
组合索引有许多特性要记住。
下面的例子都假想在 a,b,c上创建组合索引。因此创建索引语句如下
好的:
不好的: