今天在mongodb索引帮助文档里发现下边的描述:
集合order有以下索引：
{ qty: 1 }
{ status: 1, ord_date: -1 }
{ status: 1 }
{ ord_date: -1 }查询语句：
db.orders.find( { qty: { $gt: 10 } } ).sort( { status: 1 } )That is, MongoDB does not use the { qty: 1 } index for the query, and the separate { status: 1 } or the { status: 1, ord_date: -1 } index for the sort.
sort不能使用{ status: 1 } 或 { status: 1, ord_date: -1 } 我能理解，但是为什么find不能使用{ qty: 1 } 这个索引呢？
补充：是我理解错了，查询最后使用了{qty:1}这个索引
PHPz2017-05-02 09:22:21
先问一个问题，你有没有试过这条查询到底使用了哪个索引呢？
再说一下那段英文，我觉得你大概是理解错了它的意思了。这句话是说：查询引擎不会在使用{qty:1}去满足find的同时再使用{status: 1}或{status: 1, ord_date: -1}去满足sort。我换个明白点的说法：查询要么使用{qty: 1}去满足find（然后使用内存排序），要么使用{status: 1}或{status: 1, ord_date: -1}满足排序（但是只能通过集合扫描查找结果集）。{qty:1}去满足find的同时再使用{status: 1}或{status: 1, ord_date: -1}去满足sort。我换个明白点的说法：查询要么使用{qty: 1}去满足find（然后使用内存排序），要么使用{status: 1}或{status: 1, ord_date: -1}满足排序（但是只能通过集合扫描查找结果集）。
你现有的索引中没有能够同时满足查询和排序的索引，能够达到这个目的的是：{status: 1, qty: 1}。但问题是这也并不见得就是一个好的选择。说不定{qty: 1}+内存排序会更高效。这完全取决于你的数据分布情况。具体原理其实跟RDBMS中的索引是一个道理，或者说使用B/B+树的索引都这德性。几句话说不清楚还是查阅一下相关资料吧。
简单的办法是把刚才提到的索引都建好，然后运行一下这个查询，让它们自己去撕吧，最终查询引擎会基于采样数据为你选出一个最好的索引。
所以回到最初的问题，你有没有去试一下到底选择了哪个索引呢？因为最终哪个索引撕赢了是基于你数据的分布情况确定的，这里没法给出确定的答案。我愿意赌{status: 1, qty: 1}你现有的索引中没有能够同时满足查询和排序的索引，能够达到这个目的的是：{status: 1, qty: 1}。但问题是这也并不见得就是一个好的选择。说不定{qty: 1}+内存排序会更高效。这完全取决于你的数据分布情况。具体原理其实跟RDBMS中的索引是一个道理，或者说使用B/B+树的索引都这德性。几句话说不清楚还是查阅一下相关资料吧。
{status: 1, qty: 1}胜出。🎜