優(yōu)化參考

查詢優(yōu)化問題，需要有大量的數(shù)據(jù)來支持，我們通過java插入了500W條數(shù)據(jù)到數(shù)據(jù)庫(kù)中，數(shù)據(jù)結(jié)構(gòu)如下所示

{
    "_id" : ObjectId("5a3b28b8b932f02bc038744d"),
    "type" : "fatal",
    "date" : ISODate("2000-07-19T13:03:25.207Z"),
    "ip" : "111.176.23.100",
    "operator" : "error",
    "user" : "asd"
}

我們要進(jìn)行查詢優(yōu)化，首先需要一些參考依據(jù)，當(dāng)我們完成如下查詢

db.logs.find({type:"fatal"}).sort({date:-1}).limit(1)

查詢時(shí)間為6m，當(dāng)查詢時(shí)間超過100ms，這個(gè)查詢就會(huì)在日志系統(tǒng)中有所記錄

2017-12-21T17:59:17.409+0800 I COMMAND  [conn95] command demo.logs appName: "MongoDB Shell" command: find { find: "logs", filter: { type: "fatal" }, limit: 1.0, singleBatch: false, sort: { date: -1.0 } } planSummary: COLLSCAN keysExamined:0 docsExamined:5000000 hasSortStage:1 cursorExhausted:1 numYields:39176 nreturned:1 reslen:194 locks:{ Global: { acquireCount: { r: 78354 } }, Database: { acquireCount: { r: 39177 } }, Collection: { acquireCount: { r: 39177 } } } protocol:op_command 6552ms

這個(gè)信息是我們排查查詢效率的一個(gè)非常好的途徑，通過這個(gè)信息我們首先看到{find:"logs",filter:{type:"fatal"}} 這里指明了查詢的collection，通過type來查詢，并且limit了1條和通過Date排序，通過這個(gè)信息我們可以定位到我們具體的查詢中，后面的信息，我們會(huì)在explain中詳細(xì)講解。

日志是第一種慢查詢的分析手段，我們的第二種手段是使用PROFILER查詢分析器，PROFILER查詢分析器默認(rèn)是關(guān)閉的使用setProfilingLevel 可以開啟查詢分析器。

db.setProfilingLevel(2)表示開啟查詢分析器，級(jí)別為2級(jí)，會(huì)詳細(xì)的記錄每個(gè)讀寫操作
db.setProfilingLevel(1,50)表示設(shè)置監(jiān)控級(jí)別為1級(jí)，并且當(dāng)查詢時(shí)間超過50ms就會(huì)啟動(dòng)監(jiān)控
db.setProfilingLevel(0)表示關(guān)閉監(jiān)控級(jí)別

當(dāng)開啟了2級(jí)查詢之后，默認(rèn)會(huì)監(jiān)聽100ms已上的查詢，當(dāng)使用了以下查詢之后

db.logs.find({type:"fatal"}).sort({ip:-1}).limit(1)

查詢時(shí)間超過了7秒，所有的監(jiān)控結(jié)果會(huì)保存在一個(gè)特殊的集合中，可以通過system.profile來進(jìn)行查詢，這個(gè)集合的大小是固定的，在3.0版本后分配了128k的空間，當(dāng)超過這個(gè)大小會(huì)覆蓋掉原來的信息，目前由于只有一條信息，我們可以通過findOne來進(jìn)行查詢

>db.system.profile.findOne({})
{
    "op" : "query",
    "ns" : "demo.logs",
    "query" : {
        "find" : "logs",
        "filter" : {
            "type" : "fatal"
        },
        "limit" : 1.0,
        "singleBatch" : false,
        "sort" : {
            "ip" : -1.0
        }
    },
    "keysExamined" : 0,
    "docsExamined" : 5000000,
    "hasSortStage" : true,
    "cursorExhausted" : true,
    "numYield" : 39169,
    "locks" : {
        "Global" : {
            "acquireCount" : {
                "r" : NumberLong(78340)
            }
        },
        "Database" : {
            "acquireCount" : {
                "r" : NumberLong(39170)
            }
        },
        "Collection" : {
            "acquireCount" : {
                "r" : NumberLong(39170)
            }
        }
    },
    "nreturned" : 1,
    "responseLength" : 191,
    "protocol" : "op_command",
    "millis" : 7010,
    "planSummary" : "COLLSCAN",
    "execStats" : {
        "stage" : "SORT",
        "nReturned" : 1,
        "executionTimeMillisEstimate" : 6386,
        "works" : 5000005,
        "advanced" : 1,
        "needTime" : 5000003,
        "needYield" : 0,
        "saveState" : 39169,
        "restoreState" : 39169,
        "isEOF" : 1,
        "invalidates" : 0,
        "sortPattern" : {
            "ip" : -1.0
        },
        "memUsage" : 114,
        "memLimit" : 33554432,
        "limitAmount" : 1,
        "inputStage" : {
            "stage" : "SORT_KEY_GENERATOR",
            "nReturned" : 1000696,
            "executionTimeMillisEstimate" : 5824,
            "works" : 5000003,
            "advanced" : 1000696,
            "needTime" : 3999306,
            "needYield" : 0,
            "saveState" : 39169,
            "restoreState" : 39169,
            "isEOF" : 1,
            "invalidates" : 0,
            "inputStage" : {
                "stage" : "COLLSCAN",
                "filter" : {
                    "type" : {
                        "$eq" : "fatal"
                    }
                },
                "nReturned" : 1000696,
                "executionTimeMillisEstimate" : 4380,
                "works" : 5000002,
                "advanced" : 1000696,
                "needTime" : 3999305,
                "needYield" : 0,
                "saveState" : 39169,
                "restoreState" : 39169,
                "isEOF" : 1,
                "invalidates" : 0,
                "direction" : "forward",
                "docsExamined" : 5000000
            }
        }
    },
    "ts" : ISODate("2017-12-21T23:59:36.779Z"),
    "client" : "127.0.0.1",
    "appName" : "MongoDB Shell",
    "allUsers" : [],
    "user" : ""
}

這是非常有用的分析性能的文檔，前面幾個(gè)字段說明了，查詢的基本信息，后面就是一些查詢的分析信息，需要注意的是監(jiān)控策略開啟之后會(huì)自動(dòng)監(jiān)控所有的讀操作和寫操作，所以策略時(shí)間建議有一個(gè)漸進(jìn)，如先開啟100ms，然后慢慢過渡到90ms，不要一次性減少的間隔過大，這樣有可能會(huì)找不到你想要的信息。解決慢查詢最佳的時(shí)間應(yīng)該是在集成測(cè)試階段，如果在實(shí)際的運(yùn)行環(huán)境中檢測(cè)，發(fā)現(xiàn)問題和解決問題的成本會(huì)比較高，但在實(shí)際情況看，更多的問題都是在項(xiàng)目運(yùn)行過程之中才會(huì)體現(xiàn)。另外需要注明的是system.profile里面內(nèi)容存儲(chǔ)得比較多的時(shí)候，會(huì)通過$natural進(jìn)行自然排序，我們可以通過sort來獲取最后的數(shù)據(jù)

db.system.profile.find().sort({$natural:-1})

已上介紹了發(fā)現(xiàn)慢查詢的方法，發(fā)現(xiàn)很簡(jiǎn)單，但要處理就需要根據(jù)實(shí)際情況來考慮，出現(xiàn)慢查詢的原因很多，有一部分是設(shè)計(jì)問題，一部分是硬件問題，還一部分是索引問題，我們首選的解決方案就是添加索引，通過合理的索引設(shè)置來解決部分問題。已上內(nèi)容目前并沒有詳細(xì)的解釋，請(qǐng)大家看完下一小節(jié)的內(nèi)容再回過頭來看看，這個(gè)信息，是不是就一目了然了。

explain()的運(yùn)用

通過查詢分析器和日志，可以檢測(cè)到慢查詢，這些在實(shí)際的項(xiàng)目運(yùn)行中比較有效，但是在索引設(shè)計(jì)時(shí)，使用這種方式效率就比較低，MongoDB提供了explain()函數(shù)來找到原因。注意MongoDB2和3之后的explain的文檔結(jié)構(gòu)有很大區(qū)別，文中主要以3.4為例，使用如下查詢

db.logs.find({type:"error"}).sort({data:-1}).limit(1).explain("executionStats")

在explain中加入executionStats之后可以根據(jù)運(yùn)行的結(jié)果生成統(tǒng)計(jì)，先看看查詢出來的結(jié)果

{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "demo.logs",
        "indexFilterSet" : false,
        "parsedQuery" : {
            "type" : {
                "$eq" : "error"
            }
        },
        "winningPlan" : {
            "stage" : "SORT",
            "sortPattern" : {
                "data" : -1.0
            },
            "limitAmount" : 1,
            "inputStage" : {
                "stage" : "SORT_KEY_GENERATOR",
                "inputStage" : {
                    "stage" : "COLLSCAN",
                    "filter" : {
                        "type" : {
                            "$eq" : "error"
                        }
                    },
                    "direction" : "forward"
                }
            }
        },
        "rejectedPlans" : []
    },
    "executionStats" : {
        "executionSuccess" : true,
        "nReturned" : 1,
        "executionTimeMillis" : 5698,
        "totalKeysExamined" : 0,
        "totalDocsExamined" : 5000000,
        "executionStages" : {
            "stage" : "SORT",
            "nReturned" : 1,
            "executionTimeMillisEstimate" : 5189,
            "works" : 5000005,
            "advanced" : 1,
            "needTime" : 5000003,
            "needYield" : 0,
            "saveState" : 39157,
            "restoreState" : 39157,
            "isEOF" : 1,
            "invalidates" : 0,
            "sortPattern" : {
                "data" : -1.0
            },
            "memUsage" : 122,
            "memLimit" : 33554432,
            "limitAmount" : 1,
            "inputStage" : {
                "stage" : "SORT_KEY_GENERATOR",
                "nReturned" : 1000421,
                "executionTimeMillisEstimate" : 4728,
                "works" : 5000003,
                "advanced" : 1000421,
                "needTime" : 3999581,
                "needYield" : 0,
                "saveState" : 39157,
                "restoreState" : 39157,
                "isEOF" : 1,
                "invalidates" : 0,
                "inputStage" : {
                    "stage" : "COLLSCAN",
                    "filter" : {
                        "type" : {
                            "$eq" : "error"
                        }
                    },
                    "nReturned" : 1000421,
                    "executionTimeMillisEstimate" : 3048,
                    "works" : 5000002,
                    "advanced" : 1000421,
                    "needTime" : 3999580,
                    "needYield" : 0,
                    "saveState" : 39157,
                    "restoreState" : 39157,
                    "isEOF" : 1,
                    "invalidates" : 0,
                    "direction" : "forward",
                    "docsExamined" : 5000000
                }
            }
        }
    },
    "serverInfo" : {
        "host" : "SD-201709290948",
        "port" : 27017,
        "version" : "3.4.10-22-gb6132d8",
        "gitVersion" : "b6132d87fe4c108dfb0c94980a49d97406b42dce"
    },
    "ok" : 1.0
}

首先queryPlan表示查詢的基本信息，這個(gè)里面除了顯示查詢的基本操作外，有一個(gè)是值得大家注意的，那就是winning.Plans 中的stage，這里顯示的SORT，說明是文檔排序，這是嚴(yán)重影響效率的排序，馬上就會(huì)詳細(xì)介紹。

接下來關(guān)注executionStats中的內(nèi)容，這個(gè)內(nèi)容非常重要，個(gè)人先篩選如下幾個(gè)重要的信息出來，我們需要慢慢來分析

"executionStats" : {
        "executionSuccess" : true,
        "nReturned" : 1,  ##實(shí)際獲取的文檔數(shù)
        "executionTimeMillis" : 5104, ##查詢時(shí)間
        "totalKeysExamined" : 0, ##掃描的索引總數(shù)
        "totalDocsExamined" : 5000000,##掃描的總文檔數(shù)
        .....
    },

通過已上信息，我們發(fā)現(xiàn)實(shí)際只獲取了一個(gè)文檔，但卻花費(fèi)了5秒的時(shí)間，并且沒有去掃描索引，但文檔卻掃描了500W條，因?yàn)槲覀兗尤肓伺判?，它?huì)把所有文檔讀取到內(nèi)存然后倒序得到最后一個(gè)結(jié)果，此時(shí)，我們不進(jìn)行排序，看看結(jié)果

>db.logs.find({type:"error"}).limit(1).explain("executionStats")
"executionStats" : {
        "executionSuccess" : true,
        "nReturned" : 1,
        "executionTimeMillis" : 0,
        "totalKeysExamined" : 0,
        "totalDocsExamined" : 4,##沒有排序，僅僅掃描了4個(gè)文檔
        ...
  }

此時(shí)我們發(fā)現(xiàn)totalDocsExamined為4，由于查詢的是type為error的信息，當(dāng)從頭掃描，當(dāng)掃描到第4個(gè)文檔的時(shí)候就發(fā)現(xiàn)了，然后就返回了，當(dāng)然也沒有執(zhí)行索引。所以totalDocsExamined和nReturned是非常具有價(jià)值的兩個(gè)數(shù)據(jù)，如果這兩個(gè)懸殊太大肯定就是查詢有問題，我們期望這兩值越接近越好，說明檢索的東西就是我們想要的內(nèi)容

下面來分析executionStages中的信息，首先看原始查詢的

"executionStages" : {
            "stage" : "SORT",##這個(gè)非常重要
            "nReturned" : 1,
            "executionTimeMillisEstimate" : 5366,
            ....
 }

stage是非常重要的一個(gè)信息，幾種類型，SORT表示文檔排序，這是我們比較害怕的操作，因?yàn)樗鼪]有進(jìn)行索引，而是對(duì)文檔進(jìn)行排序，（就等于我們要讀一本書，我們順著內(nèi)容去找內(nèi)容而不是通過目錄找信息），我們還會(huì)看到另外一個(gè)值COLLSCAN,這也是非常影響效率的操作，因?yàn)樗鼘儆谌頀呙?。下面我們?cè)倏匆粋€(gè)操作

> db.logs.find({type:"error"}).skip(50000).limit(1).explain("executionStats")
"executionStats" : {
        "executionSuccess" : true,
        "nReturned" : 1,
        "executionTimeMillis" : 129,
        "totalKeysExamined" : 0,
        "totalDocsExamined" : 249186,
        ...
        "inputStage" : {
                "stage" : "SKIP",
                "nReturned" : 1,
                "executionTimeMillisEstimate" : 103,
                "works" : 249187,
                ....

此處我們沒有排序，而是skip了50000條文檔，雖然只查一條數(shù)據(jù)，但是卻在文檔中掃描了24w的數(shù)據(jù)，掃描這么多數(shù)據(jù)都是在SKIP操作上發(fā)生的，所以skip其實(shí)會(huì)做全表掃描。效率極不理想。所以stage我們一般都不希望出現(xiàn)“SORT”、“COLLSCAN”和不理想的“SKIP”。下面我們通過_id 進(jìn)行一下檢索，默認(rèn)_id 都會(huì)加上唯一索引，看看結(jié)果

> db.logs.find({type:"error"}).sort({_id:-1}).limit(1).explain("executionStats")
/* 1 */
{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "demo.logs",
        "indexFilterSet" : false, 
        "parsedQuery" : {
            "type" : {
                "$eq" : "error"
            }
        },
        "winningPlan" : {
            ...
            "inputStage" : {
                    "stage" : "IXSCAN", ##sort是基于索引的查詢
                    "keyPattern" : {
                        "_id" : 1
                    },
                    "indexName" : "_id_", ##索引的名稱，基于主鍵的查詢
                    "isMultiKey" : false,
                    "multiKeyPaths" : {
                        "_id" : []
                    },
                    "isUnique" : true, ##唯一索引
                    "isSparse" : false, ##不是稀疏索引
                    ....
                    }
                }
            }
        },
        "rejectedPlans" : []
    },
    "executionStats" : {
        "executionSuccess" : true,
        "nReturned" : 1, ##返回一個(gè)文檔
        "executionTimeMillis" : 2, ##花費(fèi)了2毫秒
        "totalKeysExamined" : 5, ##檢索了5個(gè)索引
        "totalDocsExamined" : 5, ##檢索了5篇document
        "executionStages" : {
        。。。。
            "inputStage" : {
                "stage" : "FETCH", ##通過索引進(jìn)行抓取
                "filter" : {
                    "type" : {
                        "$eq" : "error"
                    }
                },
                "nReturned" : 1,
                "executionTimeMillisEstimate" : 0,
                "works" : 5,
                "inputStage" : {
                    "stage" : "IXSCAN", ##索引檢索
                    "nReturned" : 5,
                    ....
                }
            }
        }
    },
}

這次查詢雖然查詢的字段沒有增加索引，但排序時(shí)已經(jīng)通過索引。所以僅僅檢索了5個(gè)文檔就得到了結(jié)果，效率從7秒減少到了2毫秒，大家看到檢索的優(yōu)勢(shì)了吧。

下面我們?yōu)閐ate增加索引，看看效果

> db.logs.createIndex({date:1})
> db.logs.find({type:"error"}).sort({date:-1}).limit(15).explain("executionStats")
{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "demo.logs",
        "indexFilterSet" : false,
        "parsedQuery" : {
            "type" : {
                "$eq" : "error"
            }
        },
        "winningPlan" : {
            "stage" : "LIMIT",
            "limitAmount" : 15,
            "inputStage" : {
                "stage" : "FETCH",
                "filter" : {
                    "type" : {
                        "$eq" : "error"
                    }
                },
                "inputStage" : {
                    "stage" : "IXSCAN",
                    "keyPattern" : {
                        "date" : 1.0
                    },
                    "indexName" : "date_1",
                    "isMultiKey" : false,
                    "multiKeyPaths" : {
                        "date" : []
                    },
                    "isUnique" : false,
                    "isSparse" : false,
                    "isPartial" : false,
                    "indexVersion" : 2,
                    "direction" : "backward",
                    "indexBounds" : {
                        "date" : [ 
                            "[MaxKey, MinKey]"
                        ]
                    }
                }
            }
        },
        "rejectedPlans" : [ 
            {
                "stage" : "SORT",
                "sortPattern" : {
                    "date" : -1.0
                },
                "limitAmount" : 15,
                "inputStage" : {
                    "stage" : "SORT_KEY_GENERATOR",
                    "inputStage" : {
                        "stage" : "FETCH",
                        "inputStage" : {
                            "stage" : "IXSCAN",
                            "keyPattern" : {
                                "type" : 1.0
                            },
                            "indexName" : "type_1",
                            "isMultiKey" : false,
                            "multiKeyPaths" : {
                                "type" : []
                            },
                            "isUnique" : false,
                            "isSparse" : false,
                            "isPartial" : false,
                            "indexVersion" : 2,
                            "direction" : "forward",
                            "indexBounds" : {
                                "type" : [ 
                                    "[\"error\", \"error\"]"
                                ]
                            }
                        }
                    }
                }
            }
        ]
    },
    "executionStats" : {
        "executionSuccess" : true,
        "nReturned" : 15,
        "executionTimeMillis" : 34,
        "totalKeysExamined" : 68,
        "totalDocsExamined" : 68,
        "executionStages" : {
            "stage" : "LIMIT",
            "nReturned" : 15,
            "executionTimeMillisEstimate" : 11,
            "works" : 69,
            "advanced" : 15,
            "needTime" : 53,
            "needYield" : 0,
            "saveState" : 2,
            "restoreState" : 2,
            "isEOF" : 1,
            "invalidates" : 0,
            "limitAmount" : 15,
            "inputStage" : {
                "stage" : "FETCH",
                "filter" : {
                    "type" : {
                        "$eq" : "error"
                    }
                },
                "nReturned" : 15,
                "executionTimeMillisEstimate" : 11,
                "works" : 68,
                "advanced" : 15,
                "needTime" : 53,
                "needYield" : 0,
                "saveState" : 2,
                "restoreState" : 2,
                "isEOF" : 0,
                "invalidates" : 0,
                "docsExamined" : 68,
                "alreadyHasObj" : 0,
                "inputStage" : {
                    "stage" : "IXSCAN",
                    "nReturned" : 68,
                    "executionTimeMillisEstimate" : 0,
                    "works" : 68,
                    "advanced" : 68,
                    "needTime" : 0,
                    "needYield" : 0,
                    "saveState" : 2,
                    "restoreState" : 2,
                    "isEOF" : 0,
                    "invalidates" : 0,
                    "keyPattern" : {
                        "date" : 1.0
                    },
                    "indexName" : "date_1",
                    "isMultiKey" : false,
                    "multiKeyPaths" : {
                        "date" : []
                    },
                    "isUnique" : false,
                    "isSparse" : false,
                    "isPartial" : false,
                    "indexVersion" : 2,
                    "direction" : "backward",
                    "indexBounds" : {
                        "date" : [ 
                            "[MaxKey, MinKey]"
                        ]
                    },
                    "keysExamined" : 68,
                    "seeks" : 1,
                    "dupsTested" : 0,
                    "dupsDropped" : 0,
                    "seenInvalidated" : 0
                }
            }
        }
    },
    "serverInfo" : {
        "host" : "SD-201709290948",
        "port" : 27017,
        "version" : "3.4.10-22-gb6132d8",
        "gitVersion" : "b6132d87fe4c108dfb0c94980a49d97406b42dce"
    },
    "ok" : 1.0
}

這個(gè)結(jié)果和_id 排序類似，效率提高了很多。

下面我們來看skip，在剛才的演示結(jié)果是，使用skip會(huì)在文檔中檢索，效率接近130ms，現(xiàn)在我們?yōu)閠ype增加索引看看效果。

>db.logs.createIndex({type:1})
>db.logs.find({type:"error"}).skip(50000).limit(10).explain("executionStats")
{
    "queryPlanner" : {
        ...
        "winningPlan" : {
            "stage" : "LIMIT",
            "limitAmount" : 15,
            "inputStage" : {
                "stage" : "FETCH", ##查詢都是基于FETCH和索引的
                "filter" : {
                    "type" : {
                        "$eq" : "error"
                    }
                },
                "inputStage" : {
                    "stage" : "IXSCAN",
                    "keyPattern" : {
                        "date" : 1.0
                    },
                    "indexName" : "date_1",
                    ...
                    }
                }
            }
        },
        "rejectedPlans" : [  ##其他可能的查詢計(jì)劃，但是被MongoDB否決的。
            {
                "stage" : "SORT",
                "sortPattern" : {
                    "date" : -1.0
                },
                "limitAmount" : 15,
                "inputStage" : {
                    "stage" : "SORT_KEY_GENERATOR",
                    "inputStage" : {
                        "stage" : "FETCH",
                        "inputStage" : {
                            "stage" : "IXSCAN",
                            "keyPattern" : {
                                "type" : 1.0
                            },
                            "indexName" : "type_1",
                           ....
    },
    "executionStats" : {
        "executionSuccess" : true,
        "nReturned" : 15, ##返回15條
        "executionTimeMillis" : 0, ##時(shí)間接近0ms
        "totalKeysExamined" : 68, ##從索引里面查詢
        "totalDocsExamined" : 68,
        ...
            }
        }
    }
}

這個(gè)里面我們看到了rejectedPlans這個(gè)值，這表示MongoDB的查詢優(yōu)化器找到了兩種方案，一種是基于date的方案，但發(fā)現(xiàn)基于type的效率要高一些，所以基于sort的方案就放到了rejectedPlans中了。最后我們發(fā)現(xiàn)檢索了68個(gè)文檔，返回了15條記錄，效率接近0ms。此時(shí)如果我們?yōu)閠ype和date添加一個(gè)復(fù)合索引

>db.logs.createIndex({type:1,date:1})
>db.logs.find({type:"error"}).sort({date:-1}).limit(15).explain("executionStats")
{
    "queryPlanner" : {
       ...
        "winningPlan" : {
            "stage" : "LIMIT",
            "limitAmount" : 15,
            "inputStage" : {
                "stage" : "FETCH",
                "inputStage" : {
                    "stage" : "IXSCAN",
                    "keyPattern" : {
                        "type" : 1.0,
                        "date" : 1.0
                    },
                    "indexName" : "type_1_date_1",
                    ....
        },
        ...
    },
    "executionStats" : {
        "executionSuccess" : true,
        "nReturned" : 15, ##返利15條信息
        "executionTimeMillis" : 0,
        "totalKeysExamined" : 15,
        "totalDocsExamined" : 15, ##查找了15條信息
        .....
    },
    ...
    "ok" : 1.0
}

這次得到的結(jié)果就更加了理想了，此時(shí)就可以把type的單鍵索引刪除了，因?yàn)橐呀?jīng)沒有意義，通過這個(gè)復(fù)合索引就可以獲取同樣的值。

> db.logs.dropIndex({type:1})
> db.logs.getIndexes()

下面我們把所有復(fù)合索引刪除，并且為type，date，operator分別創(chuàng)建三個(gè)單獨(dú)索引

> db.logs.dropIndex("type_1")
> db.logs.dropIndex("type_1_data_1")
> db.logs.dropIndex("operator_1")
> db.logs.createIndex({type:1})
> db.logs.createIndex({date:1})
> db.logs.createIndex({operator:1})

下面我們運(yùn)行如下查詢

db.logs.find({type:"error",date:{$gt:new Date("2010-01-01")}}).explain(true)

通過explain(true)可以查詢所有的計(jì)劃

{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "demo.logs",
        "indexFilterSet" : false,
        "parsedQuery" : {
            "$and" : [ 
                {
                    "type" : {
                        "$eq" : "error"
                    }
                }, 
                {
                    "date" : {
                        "$gt" : ISODate("2010-01-01T00:00:00.000Z")
                    }
                }
            ]
        },
        "winningPlan" : {
            "stage" : "FETCH",
            "filter" : {
                "date" : {
                    "$gt" : ISODate("2010-01-01T00:00:00.000Z")
                }
            },
            "inputStage" : {
                "stage" : "IXSCAN",
                "keyPattern" : {
                    "type" : 1.0
                },
                "indexName" : "type_1",
                "isMultiKey" : false,
                "multiKeyPaths" : {
                    "type" : []
                },
                "isUnique" : false,
                "isSparse" : false,
                "isPartial" : false,
                "indexVersion" : 2,
                "direction" : "forward",
                "indexBounds" : {
                    "type" : [ 
                        "[\"error\", \"error\"]"
                    ]
                }
            }
        },
        "rejectedPlans" : [ 
            {
                "stage" : "FETCH",
                "filter" : {
                    "type" : {
                        "$eq" : "error"
                    }
                },
                "inputStage" : {
                    "stage" : "IXSCAN",
                    "keyPattern" : {
                        "date" : 1.0
                    },
                    "indexName" : "date_1",
                    "isMultiKey" : false,
                    "multiKeyPaths" : {
                        "date" : []
                    },
                    "isUnique" : false,
                    "isSparse" : false,
                    "isPartial" : false,
                    "indexVersion" : 2,
                    "direction" : "forward",
                    "indexBounds" : {
                        "date" : [ 
                            "(new Date(1262304000000), new Date(9223372036854775807)]"
                        ]
                    }
                }
            }
        ]
    },
    "executionStats" : {
        "executionSuccess" : true,
        "nReturned" : 399346,
        "executionTimeMillis" : 1675,
        "totalKeysExamined" : 1000421,
        "totalDocsExamined" : 1000421,
        ...
        },
        "allPlansExecution" : [ 
           ....
        ]
    },
    "serverInfo" : {
       ...
    },
    "ok" : 1.0
}

我們看到winningPlan是基于type的，而rejectedPlan是基于deat的，為什么會(huì)選擇date而不是type呢？我們可以通過hint函數(shù)來指定執(zhí)行的索引，這種查詢totalDocsExamined為100W條數(shù)據(jù)，返回了39W多的數(shù)據(jù)，下面我們通過hint指定使用date

> var query = {type:"error",date:{$gt:new Date("2010-01-01")}}
> db.logs.find(query).hint({date:1}).explain(true)

 "executionStats" : {
        "executionSuccess" : true,
        "nReturned" : 399346,
        "executionTimeMillis" : 6506,
        "totalKeysExamined" : 1995711,
        "totalDocsExamined" : 1995711,

發(fā)現(xiàn)查詢了190W才找到這些數(shù)據(jù)，所以查詢優(yōu)化器就會(huì)選擇第一種方案，hint方法可以指定使用的索引，大家可以試一下hint({$natural:1}) 這個(gè)表示使用自然搜索，而不使用索引。

到這里索引的內(nèi)容就基本講完了，這里僅僅提供了一個(gè)思路，很多情況需要實(shí)際問題，實(shí)際分析，現(xiàn)在大家再折回頭去看看日志和profile分析器中的內(nèi)容，應(yīng)該就有一定的思路了！