MongoDB索引原理

lyhabc

為什么需要索引？

當(dāng)你抱怨MongoDB集合查詢(xún)效率低的時(shí)候，可能你就需要考慮使用索引了，為了方便后續(xù)介紹，先科普下MongoDB里的索引機(jī)制（同樣適用于其他的數(shù)據(jù)庫(kù)比如mysql）。

mongo-9552RIMARY> db.person.find()
{ "_id" : ObjectId("571b5da31b0d530a03b3ce82", "name" : "jack", "age" : 19 }
{ "_id" : ObjectId("571b5dae1b0d530a03b3ce83", "name" : "rose", "age" : 20 }
{ "_id" : ObjectId("571b5db81b0d530a03b3ce84", "name" : "jack", "age" : 18 }
{ "_id" : ObjectId("571b5dc21b0d530a03b3ce85", "name" : "tony", "age" : 21 }
{ "_id" : ObjectId("571b5dc21b0d530a03b3ce86", "name" : "adam", "age" : 18 }
當(dāng)你往某各個(gè)集合插入多個(gè)文檔后，每個(gè)文檔在經(jīng)過(guò)底層的存儲(chǔ)引擎持久化后，會(huì)有一個(gè)位置信息，通過(guò)這個(gè)位置信息，就能從存儲(chǔ)引擎里讀出該文檔。比如mmapv1引擎里，位置信息是『文件id + 文件內(nèi)offset 』， 在wiredtiger存儲(chǔ)引擎（一個(gè)KV存儲(chǔ)引擎）里，位置信息是wiredtiger在存儲(chǔ)文檔時(shí)生成的一個(gè)key，通過(guò)這個(gè)key能訪問(wèn)到對(duì)應(yīng)的文檔；為方便介紹，統(tǒng)一用pos(position的縮寫(xiě))來(lái)代表位置信息。

比如上面的例子里，person集合里包含插入了4個(gè)文檔，假設(shè)其存儲(chǔ)后位置信息如下(為方便描述，文檔省去_id字段)

位置信息        文檔
pos1        {“name” : “jack”, “age” : 19 }
pos2        {“name” : “rose”, “age” : 20 }
pos3        {“name” : “jack”, “age” : 18 }
pos4        {“name” : “tony”, “age” : 21}
pos5        {“name” : “adam”, “age” : 18}
假設(shè)現(xiàn)在有個(gè)查詢(xún) db.person.find( {age: 18} ), 查詢(xún)所有年齡為18歲的人，這時(shí)需要遍歷所有的文檔（『全表掃描』），根據(jù)位置信息讀出文檔，對(duì)比age字段是否為18。當(dāng)然如果只有4個(gè)文檔，全表掃描的開(kāi)銷(xiāo)并不大，但如果集合文檔數(shù)量到百萬(wàn)、甚至千萬(wàn)上億的時(shí)候，對(duì)集合進(jìn)行全表掃描開(kāi)銷(xiāo)是非常大的，一個(gè)查詢(xún)耗費(fèi)數(shù)十秒甚至幾分鐘都有可能。

如果想加速 db.person.find( {age: 18} ），就可以考慮對(duì)person表的age字段建立索引。

db.person.createIndex( {age: 1} )  // 按age字段創(chuàng)建升序索引
建立索引后，MongoDB會(huì)額外存儲(chǔ)一份按age字段升序排序的索引數(shù)據(jù)，索引結(jié)構(gòu)類(lèi)似如下，索引通常采用類(lèi)似btree的結(jié)構(gòu)持久化存儲(chǔ)，以保證從索引里快速（O(logN)的時(shí)間復(fù)雜度）找出某個(gè)age值對(duì)應(yīng)的位置信息，然后根據(jù)位置信息就能讀取出對(duì)應(yīng)的文檔。

AGE        位置信息
18        pos3
18        pos5
19        pos1
20        pos2
21        pos4
簡(jiǎn)單的說(shuō)，索引就是將文檔按照某個(gè)（或某些）字段順序組織起來(lái)，以便能根據(jù)該字段高效的查詢(xún)。有了索引，至少能優(yōu)化如下場(chǎng)景的效率：

查詢(xún)，比如查詢(xún)年齡為18的所有人
更新/刪除，將年齡為18的所有人的信息更新或刪除，因?yàn)楦�新或刪除時(shí)，需要根據(jù)條件先查詢(xún)出所有符合條件的文檔，所以本質(zhì)上還是在優(yōu)化查詢(xún)
排序，將所有人的信息按年齡排序，如果沒(méi)有索引，需要全表掃描文檔，然后再對(duì)掃描的結(jié)果進(jìn)行排序
眾所周知，MongoDB默認(rèn)會(huì)為插入的文檔生成_id字段（如果應(yīng)用本身沒(méi)有指定該字段），_id是文檔唯一的標(biāo)識(shí)，為了保證能根據(jù)文檔id快遞查詢(xún)文檔，MongoDB默認(rèn)會(huì)為集合創(chuàng)建_id字段的索引。

mongo-9552RIMARY> db.person.getIndexes() // 查詢(xún)集合的索引信息
[
    {
        "ns" : "test.person",  // 集合名
        "v" : 1,               // 索引版本
        "key" : {              // 索引的字段及排序方向
            "_id" : 1           // 根據(jù)_id字段升序索引
        },
        "name" : "_id_"        // 索引的名稱(chēng)
    }
]
MongoDB索引類(lèi)型

MongoDB支持多種類(lèi)型的索引，包括單字段索引、復(fù)合索引、多key索引、文本索引等，每種類(lèi)型的索引有不同的使用場(chǎng)合。

單字段索引 （Single Field Index）

    db.person.createIndex( {age: 1} )
上述語(yǔ)句針對(duì)age創(chuàng)建了單字段索引，其能加速對(duì)age字段的各種查詢(xún)請(qǐng)求，是最常見(jiàn)的索引形式，MongoDB默認(rèn)創(chuàng)建的id索引也是這種類(lèi)型。

{age: 1} 代表升序索引，也可以通過(guò){age: -1}來(lái)指定降序索引，對(duì)于單字段索引，升序/降序效果是一樣的。

復(fù)合索引 (Compound Index)

復(fù)合索引是Single Field Index的升級(jí)版本，它針對(duì)多個(gè)字段聯(lián)合創(chuàng)建索引，先按第一個(gè)字段排序，第一個(gè)字段相同的文檔按第二個(gè)字段排序，依次類(lèi)推，如下針對(duì)age, name這2個(gè)字段創(chuàng)建一個(gè)復(fù)合索引。

    db.person.createIndex( {age: 1, name: 1} )
上述索引對(duì)應(yīng)的數(shù)據(jù)組織類(lèi)似下表，與{age: 1}索引不同的時(shí)，當(dāng)age字段相同時(shí)，在根據(jù)name字段進(jìn)行排序，所以pos5對(duì)應(yīng)的文檔排在pos3之前。

AGE        位置信息
18        pos5
18        pos3
19        pos1
20        pos2
21        pos4
復(fù)合索引能滿(mǎn)足的查詢(xún)場(chǎng)景比單字段索引更豐富，不光能滿(mǎn)足多個(gè)字段組合起來(lái)的查詢(xún)，比如db.person.find( {age： 18， name: "jack"} )，也能滿(mǎn)足所以能匹配符合索引前綴的查詢(xún)，這里{age: 1}即為{age: 1, name: 1}的前綴，所以類(lèi)似db.person.find( {age： 18} )的查詢(xún)也能通過(guò)該索引來(lái)加速；但db.person.find( {name: "jack"} )則無(wú)法使用該復(fù)合索引。如果經(jīng)常需要根據(jù)『name字段』以及『name和age字段組合』來(lái)查詢(xún)，則應(yīng)該創(chuàng)建如下的復(fù)合索引

db.person.createIndex( {name: 1, age: 1} )
除了查詢(xún)的需求能夠影響索引的順序，字段的值分布也是一個(gè)重要的考量因素，即使person集合所有的查詢(xún)都是『name和age字段組合』（指定特定的name和age），字段的順序也是有影響的。

age字段的取值很有限，即擁有相同age字段的文檔會(huì)有很多；而name字段的取值則豐富很多，擁有相同name字段的文檔很少；顯然先按name字段查找，再在相同name的文檔里查找age字段更為高效。

多key索引 （Multikey Index）

當(dāng)索引的字段為數(shù)組時(shí)，創(chuàng)建出的索引稱(chēng)為多key索引，多key索引會(huì)為數(shù)組的每個(gè)元素建立一條索引，比如person表加入一個(gè)habbit字段（數(shù)組）用于描述興趣愛(ài)好，需要查詢(xún)有相同興趣愛(ài)好的人就可以利用habbit字段的多key索引。

{"name" : "jack", "age" : 19, habbit: ["football, runnning"]}
db.person.createIndex( {habbit: 1} )  // 自動(dòng)創(chuàng)建多key索引
db.person.find( {habbit: "football"} )
其他類(lèi)型索引

哈希索引（Hashed Index）是指按照某個(gè)字段的hash值來(lái)建立索引，目前主要用于MongoDB Sharded Cluster的Hash分片，hash索引只能滿(mǎn)足字段完全匹配的查詢(xún)，不能滿(mǎn)足范圍查詢(xún)等。

地理位置索引（Geospatial Index）能很好的解決O2O的應(yīng)用場(chǎng)景，比如『查找附近的美食』、『查找某個(gè)區(qū)域內(nèi)的車(chē)站』等。

文本索引（Text Index）能解決快速文本查找的需求，比如有一個(gè)博客文章集合，需要根據(jù)博客的內(nèi)容來(lái)快速查找，則可以針對(duì)博客內(nèi)容建立文本索引。

索引額外屬性

MongoDB除了支持多種不同類(lèi)型的索引，還能對(duì)索引定制一些特殊的屬性。

唯一索引 (unique index)：保證索引對(duì)應(yīng)的字段不會(huì)出現(xiàn)相同的值，比如_id索引就是唯一索引
TTL索引：可以針對(duì)某個(gè)時(shí)間字段，指定文檔的過(guò)期時(shí)間（經(jīng)過(guò)指定時(shí)間后過(guò)期 或 在某個(gè)時(shí)間點(diǎn)過(guò)期）
部分索引 (partial index): 只針對(duì)符合某個(gè)特定條件的文檔建立索引，3.2版本才支持該特性
稀疏索引(sparse index): 只針對(duì)存在索引字段的文檔建立索引，可看做是部分索引的一種特殊情況
索引優(yōu)化

db profiling

MongoDB支持對(duì)DB的請(qǐng)求進(jìn)行profiling，目前支持3種級(jí)別的profiling。

0： 不開(kāi)啟profiling
1： 將處理時(shí)間超過(guò)某個(gè)閾值(默認(rèn)100ms)的請(qǐng)求都記錄到DB下的system.profile集合 （類(lèi)似于mysql、redis的slowlog）
2： 將所有的請(qǐng)求都記錄到DB下的system.profile集合（生產(chǎn)環(huán)境慎用）
通常，生產(chǎn)環(huán)境建議使用1級(jí)別的profiling，并根據(jù)自身需求配置合理的閾值，用于監(jiān)測(cè)慢請(qǐng)求的情況，并及時(shí)的做索引優(yōu)化。

如果能在集合創(chuàng)建的時(shí)候就能『根據(jù)業(yè)務(wù)查詢(xún)需求決定應(yīng)該創(chuàng)建哪些索引』，當(dāng)然是最佳的選擇；但由于業(yè)務(wù)需求多變，要根據(jù)實(shí)際情況不斷的進(jìn)行優(yōu)化。索引并不是越多越好，集合的索引太多，會(huì)影響寫(xiě)入、更新的性能，每次寫(xiě)入都需要更新所有索引的數(shù)據(jù)；所以你system.profile里的慢請(qǐng)求可能是索引建立的不夠?qū)е�，也可能是索引過(guò)多導(dǎo)致。

查詢(xún)計(jì)劃

索引已經(jīng)建立了，但查詢(xún)還是很慢怎么破？這時(shí)就得深入的分析下索引的使用情況了，可通過(guò)查看下詳細(xì)的查詢(xún)計(jì)劃來(lái)決定如何優(yōu)化。通過(guò)執(zhí)行計(jì)劃可以看出如下問(wèn)題

根據(jù)某個(gè)/些字段查詢(xún)，但沒(méi)有建立索引
根據(jù)某個(gè)/些字段查詢(xún)，但建立了多個(gè)索引，執(zhí)行查詢(xún)時(shí)沒(méi)有使用預(yù)期的索引。
建立索引前，db.person.find( {age： 18} )必須執(zhí)行COLLSCAN，即全表掃描。

mongo-9552RIMARY> db.person.find({age: 18}).explain()
{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "test.person",
        "indexFilterSet" : false,
        "parsedQuery" : {
            "age" : {
                "$eq" : 18
            }
        },
        "winningPlan" : {
            "stage" : "COLLSCAN",
            "filter" : {
                "age" : {
                    "$eq" : 18
                }
            },
            "direction" : "forward"
        },
        "rejectedPlans" : [ ]
    },
    "serverInfo" : {
        "host" : "localhost",
        "port" : 9552,
        "version" : "3.2.3",
        "gitVersion" : "b326ba837cf6f49d65c2f85e1b70f6f31ece7937"
    },
    "ok" : 1
}
建立索引后，通過(guò)查詢(xún)計(jì)劃可以看出，先進(jìn)行[IXSCAN]((https://docs.mongodb.org/manual/ ... sults/#queryplanner)(從索引中查找)，然后FETCH，讀取出滿(mǎn)足條件的文檔。

mongo-9552RIMARY> db.person.find({age: 18}).explain()
{
    "queryPlanner" : {
        "plannerVersion" : 1,
        "namespace" : "test.person",
        "indexFilterSet" : false,
        "parsedQuery" : {
            "age" : {
                "$eq" : 18
            }
        },
        "winningPlan" : {
            "stage" : "FETCH",
            "inputStage" : {
                "stage" : "IXSCAN",
                "keyPattern" : {
                    "age" : 1
                },
                "indexName" : "age_1",
                "isMultiKey" : false,
                "isUnique" : false,
                "isSparse" : false,
                "isPartial" : false,
                "indexVersion" : 1,
                "direction" : "forward",
                "indexBounds" : {
                    "age" : [
                        "[18.0, 18.0]"
                    ]
                }
            }
        },
        "rejectedPlans" : [ ]
    },
    "serverInfo" : {
        "host" : "localhost",
        "port" : 9552,
        "version" : "3.2.3",
        "gitVersion" : "b326ba837cf6f49d65c2f85e1b70f6f31ece7937"
    },
    "ok" : 1
}