4.8 小技巧——使用explain命令驗證優(yōu)化

前面說過，建立索引的目的是用來加速數(shù)據(jù)查詢的。那么，如何判斷索引是否合理，或者說怎樣評估索引所起到的作用呢？

是否存在這么一個工具，可以提前告知我們一些預(yù)期的效果呢？答案是肯定的。MongoDB提供了explain命令，它可以幫助我們評估指定查詢模型（query model）的計劃。

通常，我們需要關(guān)心的問題如下：

● 查詢是否使用了索引。

● 索引是否減少了掃描的記錄數(shù)量。

● 是否存在低效的內(nèi)存排序。

● ……

接下來，繼續(xù)使用之前創(chuàng)建的book集合，在沒有任何索引的情況下嘗試評估查詢計劃，代碼如下：

返回的信息量有點多，但務(wù)必記住一點，現(xiàn)在的集合沒有創(chuàng)建任何索引（除了自動創(chuàng)建的_id索引），所以查詢計劃顯得有些糟糕：

● winningPlan表示獲勝的計劃，即數(shù)據(jù)庫經(jīng)過一系列評估后選擇的最優(yōu)計劃，stage=COLLSCAN則說明這是一個全表掃描。

● executionStats描述了執(zhí)行的過程信息，其中，nReturned=1是指返回了一條結(jié)果，而totalDocsExamined=50說明整個過程掃描了50條記錄。

盡管集合中的數(shù)據(jù)量并不大，但至少可以看出在沒有索引的情況下查詢會多么低效。為了返回1個文檔需要耗費50次的掃描，假設(shè)集合有1000萬個文檔，那么就需要掃描5億次！

為了優(yōu)化這個查詢，我們?yōu)闃祟}建立一個升序索引，代碼如下：

繼續(xù)評估查詢計劃，代碼如下：

這次的結(jié)果明顯有些不同，相比第一次查詢計劃，其優(yōu)化如下：

● 不再使用全表掃描（COLLSCAN）方式，取而代之的是索引掃描（IXSCAN）。

● totalDocsExamined=1，意味著掃描的文檔數(shù)量只有1個。同時由于使用了索引掃描，因此可以看到totalKeysExamined=1。

executionStats.executionTimeMillis這個屬性描述了執(zhí)行過程所消耗的時間，一般需要配合一定的數(shù)據(jù)規(guī)模才能看出差異。

本例所提供的數(shù)據(jù)量太小，因此表現(xiàn)出來的執(zhí)行時間并沒有什么不同。但通過explain結(jié)果中的查詢計劃、命中比率（返回數(shù)/掃描數(shù)），卻能明顯地看到索引對于查詢效率帶來的提升。