find和sort同時使用時，mongodb是如何處理的？

Question

今天在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}這個索引

Answer 1

先問一個問題，你有沒有試過這條查詢到底使用了哪個索引呢？
再說一下那段英文，我覺得你大概是理解錯了它的意思了。這句話是說：查詢引擎不會在使用{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}勝出。 🎜