摘要：操作符如何使用索引有一些查詢完全無(wú)法使用索引，也有一些查詢能夠比其他查詢更高效地使用索引。有時(shí)能夠使用索引，但是通常它并不知道要如何使用索引。索引對(duì)象和數(shù)組允許深入文檔內(nèi)部，對(duì)嵌套字段和數(shù)組建立索引。

上一篇文章：MongoDB指南---10、索引、復(fù)合索引 簡(jiǎn)介
下一篇文章：MongoDB指南---12、使用explain()和hint()、何時(shí)不應(yīng)該使用索引

在多個(gè)鍵上建立的索引就是復(fù)合索引，在上面的小節(jié)中，已經(jīng)使用過(guò)復(fù)合索引。復(fù)合索引比單鍵索引要復(fù)雜一些，但是也更強(qiáng)大。本節(jié)會(huì)更深入地介紹復(fù)合索引。

到目前為止，我們的所有索引都是升序的（或者是從最小到最大）。但是，如果需要在兩個(gè)（或者更多）查詢條件上進(jìn)行排序，可能需要讓索引鍵的方向不同。例如，假設(shè)我們要根據(jù)年齡從小到大，用戶名從Z到A對(duì)上面的集合進(jìn)行排序。對(duì)于這個(gè)問(wèn)題，之前的索引變得不再高效：每一個(gè)年齡分組內(nèi)都是按照"username"升序排列的，是A到Z，不是Z到A。對(duì)于按"age"升序排列按"username"降序排列這樣的需求來(lái)說(shuō)，用上面的索引得到的數(shù)據(jù)的順序沒(méi)什么用。
為了在不同方向上優(yōu)化這個(gè)復(fù)合排序，需要使用與方向相匹配的索引。在這個(gè)例子中，可以使用{"age" : 1， "username" : -1}，它會(huì)以下面的方式組織數(shù)據(jù)：

[21, "user999977"] -> 0xe57bf737
[21, "user999954"] -> 0x8bffa512
[21, "user999902"] -> 0x9e1447d1
[21, "user999900"] -> 0x3a6a8426
[21, "user999874"] -> 0xc353ee06
...
[30, "user999936"] -> 0x7f39a81a
[30, "user999850"] -> 0xa979e136
[30, "user999775"] -> 0x5de6b77a
...
[30, "user100324"] -> 0xe14f8e4d
[30, "user100140"] -> 0x0f34d446
[30, "user100050"] -> 0x223c35b1

年齡按照從年輕到年長(zhǎng)順序排列，在每一個(gè)年齡分組中，用戶名是從Z到A排列的（對(duì)于我們的用戶名來(lái)說(shuō)，也可以說(shuō)是按照"9"到"0"排列的）。
如果應(yīng)用程序同時(shí)需要按照{(diào)"age" : 1， "username" : 1}優(yōu)化排序，我們還需要?jiǎng)?chuàng)建一個(gè)這個(gè)方向上的索引。至于索引使用的方向，與排序方向相同就可以了。注意，相互反轉(zhuǎn)（在每個(gè)方向都乘以-1）的索引是等價(jià)的：{"age" : 1， "user name" : -1}適用的查詢與{"age" : -1， "username" : 1}是完全一樣的。
只有基于多個(gè)查詢條件進(jìn)行排序時(shí)，索引方向才是比較重要的。如果只是基于單一鍵進(jìn)行排序，MongoDB可以簡(jiǎn)單地從相反方向讀取索引。例如，如果有一個(gè)基于{"age" : -1}的排序和一個(gè)基于{"age" : 1}的索引，MongoDB會(huì)在使用索引時(shí)進(jìn)行優(yōu)化，就如同存在一個(gè){"age" : -1}索引一樣（所以不要?jiǎng)?chuàng)建兩個(gè)這樣的索引！）。只有在基于多鍵排序時(shí)，方向才變得重要。

在上面的例子中，查詢只是用來(lái)查找正確的文檔，然后按照指示獲取實(shí)際的文檔。然后，如果你的查詢只需要查找索引中包含的字段，那就根本沒(méi)必要獲取實(shí)際的文檔。當(dāng)一個(gè)索引包含用戶請(qǐng)求的所有字段，可以認(rèn)為這個(gè)索引覆蓋了本次查詢。在實(shí)際中，應(yīng)該優(yōu)先使用覆蓋索引，而不是去獲取實(shí)際的文檔。這樣可以保證工作集比較小，尤其與右平衡索引一起使用時(shí)。
為了確保查詢只使用索引就可以完成，應(yīng)該使用投射（詳見(jiàn)4.1.1節(jié)）來(lái)指定不要返回"_id"字段（除非它是索引的一部分）?？赡苓€需要對(duì)不需要查詢的字段做索引，因此需要在編寫(xiě)時(shí)就在所需的查詢速度和這種方式帶來(lái)的開(kāi)銷(xiāo)之間做好權(quán)衡。
如果在覆蓋索引上執(zhí)行explain()，"indexOnly"字段的值要為true。
如果在一個(gè)含有數(shù)組的字段上做索引，這個(gè)索引永遠(yuǎn)也無(wú)法覆蓋查詢（因?yàn)閿?shù)組是被保存在索引中的，5.1.4節(jié)會(huì)深入介紹）。即便將數(shù)組字段從需要返回的字段中剔除，這樣的索引仍然無(wú)法覆蓋查詢。

復(fù)合索引具有雙重功能，而且對(duì)不同的查詢可以表現(xiàn)為不同的索引。如果有一個(gè){"age" : 1， "username" : 1}索引，"age"字段會(huì)被自動(dòng)排序，就好像有一個(gè){"age" : 1}索引一樣。因此，這個(gè)復(fù)合索引可以當(dāng)作{"age" : 1}索引一樣使用。
這個(gè)可以根據(jù)需要推廣到盡可能多的鍵：如果有一個(gè)擁有N個(gè)鍵的索引，那么你同時(shí)“免費(fèi)”得到了所有這N個(gè)鍵的前綴組成的索引。舉例來(lái)說(shuō)，如果有一個(gè){"a": 1， "b": 1， "c": 1， ...， "z": 1}索引，那么，實(shí)際上我們也可以使用 {"a": 1}、{"a": 1， "b" : 1}、{"a": 1， "b": 1， "c": 1}等一系列索引。
注意，這些鍵的任意子集所組成的索引并不一定可用。例如，使用{"b": 1}或者{"a": 1， "c": 1}作為索引的查詢是不會(huì)被優(yōu)化的：只有能夠使用索引前綴的查詢才能從中受益。

有一些查詢完全無(wú)法使用索引，也有一些查詢能夠比其他查詢更高效地使用索引。本節(jié)講述MongoDB對(duì)各種不同查詢操作符的處理。

有一些查詢完全無(wú)法使用索引，比如"$where"查詢和檢查一個(gè)鍵是否存在的查詢（{"key" : {"$exists" : true}}）。也有其他一些操作不能高效地使用索引。
如果"x"上有一個(gè)索引，查詢那些不包含"x"鍵的文檔可以使用這樣的索引({"x" : {"$exists" : false}}。然而，在索引中，不存在的字段和null字段的存儲(chǔ)方式是一樣的，查詢必須遍歷每一個(gè)文檔檢查這個(gè)值是否真的為null還是根本不存在。如果使用稀疏索引（sparse index），就不能使用{"$exists" : true}，也不能使用{"$exists" : false}。
通常來(lái)說(shuō)，取反的效率是比較低的。"$ne"查詢可以使用索引，但并不是很有效。因?yàn)楸仨氁榭此械乃饕龡l目，而不只是"$ne"指定的條目，不得不掃描整個(gè)索引。例如，這樣的查詢遍歷的索引范圍如下：

> db.example.find({"i" : {"$ne" : 3}}).explain()
{
    "cursor" : "BtreeCursor i_1 multi",
    ...,
    "indexBounds" : {
        "i" : [
            [
                {
                    "$minElement" : 1
                },
                3
            ],
            [
                3,
                {
                    "$maxElement" : 1
                }
            ]
        ]
    },
    ...
}

這個(gè)查詢查找了所有小于3和大于3的索引條目。如果索引中值為3的條目非常多，那么這個(gè)查詢的效率是很不錯(cuò)的，否則的話，這個(gè)查詢就不得不檢查幾乎所有的索引條目。
"$not"有時(shí)能夠使用索引，但是通常它并不知道要如何使用索引。它能夠?qū)镜姆秶ū热鐚"key" : {"$lt" : 7}} 變成 {"key" : {"$gte" : 7}}）和正則表達(dá)式進(jìn)行反轉(zhuǎn)。然而，大多數(shù)使用"$not"的查詢都會(huì)退化為進(jìn)行全表掃描。"$nin"就總是進(jìn)行全表掃描。
如果需要快速執(zhí)行一個(gè)這些類(lèi)型的查詢，可以試著找到另一個(gè)能夠使用索引的語(yǔ)句，將其添加到查詢中，這樣就可以在MongoDB進(jìn)行無(wú)索引匹配（non-indexed matching）時(shí)先將結(jié)果集的文檔數(shù)量減到一個(gè)比較小的水平。
假如我們要找出所有沒(méi)有"birthday"字段的用戶。如果我們知道從3月20開(kāi)始，程序會(huì)為每一個(gè)新用戶添加生日字段，那么就可以只查詢3月20之前創(chuàng)建的用戶：

> db.users.find({"birthday" : {"$exists" : false}, "_id" : {"$lt" : march20Id}})

這個(gè)查詢中的字段順序無(wú)關(guān)緊要，MongoDB會(huì)自動(dòng)找出可以使用索引的字段，而無(wú)視查詢中的字段順序。

復(fù)合索引使MongoDB能夠高效地執(zhí)行擁有多個(gè)語(yǔ)句的查詢。設(shè)計(jì)基于多個(gè)字段的索引時(shí)，應(yīng)該將會(huì)用于精確匹配的字段（比如 "x" : "foo"）放在索引的前面，將用于范圍匹配的字段（比如"y" : {"$gt" : 3， "$lt" : 5}）放在最后。這樣，查詢就可以先使用第一個(gè)索引鍵進(jìn)行精確匹配，然后再使用第二個(gè)索引范圍在這個(gè)結(jié)果集內(nèi)部進(jìn)行搜索。假設(shè)要使用{"age" : 1， "username" : 1}索引查詢特定年齡和用戶名范圍內(nèi)的文檔，可以精確指定索引邊界值：

> db.users.find({"age" : 47,
... "username" : {"$gt" : "user5", "$lt" : "user8"}}).explain()
{
    "cursor" : "BtreeCursor age_1_username_1",
    "n" : 2788,
    "nscanned" : 2788,
    ...,
    "indexBounds" : {
        "age" : [
            [
                47,
                47
            ]
        ],
        "username" : [
            [
                "user5",
                "user8"
            ]
        ]
    },
    ...
}

這個(gè)查詢會(huì)直接定位到"age"為47的索引條目，然后在其中搜索用戶名介于"user5"和"user8"的條目。
反過(guò)來(lái)，假如使用{"username" : 1， "age" : 1}索引，這樣就改變了查詢計(jì)劃（query plan），查詢必須先找到介于"user5"和"user8"之間的所有用戶，然后再?gòu)闹刑暨x"age"等于47的用戶。

> db.users.find({"age" : 47,
... "username" : {"$gt" : "user5", "$lt" : "user8"}}).explain()
{
    "cursor" : "BtreeCursor username_1_age_1",
    "n" : 2788,
    "nscanned" : 319499,
    ...,
    "indexBounds" : {
        "username" : [
            [
                "user5",
                "user8"
            ]
        ],
        "age" : [
            [
                47,
                47
            ]
        ]
    },
    "server" : "spock:27017"
}

本次查詢中MongoDB掃描的索引條目數(shù)量是前一個(gè)查詢的10倍！在一次查詢中使用兩個(gè)范圍通常會(huì)導(dǎo)致低效的查詢計(jì)劃。

寫(xiě)作本書(shū)時(shí)，MongoDB在一次查詢中只能使用一個(gè)索引。如果你在{"x" : 1}上有一個(gè)索引，在{"y" : 1}上也有一個(gè)索引，在{"x" : 123， "y" : 456}上進(jìn)行查詢時(shí)，MongoDB會(huì)使用其中的一個(gè)索引，而不是兩個(gè)一起用。"$or"是個(gè)例外，"$or"可以對(duì)每個(gè)子句都使用索引，因?yàn)?$or"實(shí)際上是執(zhí)行兩次查詢?nèi)缓髮⒔Y(jié)果集合并。

 > db.foo.find({"$or" : [{"x" : 123}, {"y" : 456}]}).explain()
 {
      "clauses" : [
        {
            "cursor" : "BtreeCursor x_1",
            "isMultiKey" : false,
            "n" : 1,
            "nscannedObjects" : 1,
            "nscanned" : 1,
            "nscannedObjectsAllPlans" : 1,
            "nscannedAllPlans" : 1,
            "scanAndOrder" : false,
            "indexOnly" : false,
            "nYields" : 0,
            "nChunkSkips" : 0,
            "millis" : 0,
            "indexBounds" : {
                "x" : [
                    [
                        123,
                        123
                    ]
            ]
        }
    },
    {
        "cursor" : "BtreeCursor y_1",
        "isMultiKey" : false,
        "n" : 1,
        "nscannedObjects" : 1,
        "nscanned" : 1,
        "nscannedObjectsAllPlans" : 1,
        "nscannedAllPlans" : 1,
        "scanAndOrder" : false,
        "indexOnly" : false,
        "nYields" : 0,
        "nChunkSkips" : 0,
        "millis" : 0,
        "indexBounds" : {
            "y" : [
                    [
                        456,
                        456
                    ]
                ]
            }
        }
    ],
    "n" : 2,
    "nscannedObjects" : 2,
    "nscanned" : 2,
    "nscannedObjectsAllPlans" : 2,
    "nscannedAllPlans" : 2,
    "millis" : 0,
    "server" : "spock:27017"
}

可以看到，這次的explain()輸出結(jié)果由兩次獨(dú)立的查詢組成。通常來(lái)說(shuō)，執(zhí)行兩次查詢?cè)賹⒔Y(jié)果合并的效率不如單次查詢高，因此，應(yīng)該盡可能使用"$in"而不是"$or"。
如果不得不使用"$or"，記住，MongoDB需要檢查每次查詢的結(jié)果集并且從中移除重復(fù)的文檔（有些文檔可能會(huì)被多個(gè)"$or"子句匹配到）。
使用"$in"查詢時(shí)無(wú)法控制返回文檔的順序（除非進(jìn)行排序）。例如，使用{"x" : [1， 2， 3]}與使用{"x" : [3， 2， 1]}得到的文檔順序是相同的。

MongoDB允許深入文檔內(nèi)部，對(duì)嵌套字段和數(shù)組建立索引。嵌套對(duì)象和數(shù)組字段可以與復(fù)合索引中的頂級(jí)字段一起使用，雖然它們比較特殊，但是大多數(shù)情況下與“正?！彼饕侄蔚男袨槭且恢碌摹?/p> 1. 索引嵌套文檔

可以在嵌套文檔的鍵上建立索引，方式與正常的鍵一樣。如果有這樣一個(gè)集合，其中的第一個(gè)文檔表示一個(gè)用戶，可能需要使用嵌套文檔來(lái)表示每個(gè)用戶的位置：

{
    "username" : "sid",
    "loc" : {
        "ip" : "1.2.3.4",
        "city" : "Springfield",
        "state" : "NY"
    }
}

需要在"loc"的某一個(gè)子字段（比如"loc.city"）上建立索引，以便提高這個(gè)字段的查詢速度：

> db.users.ensureIndex({"loc.city" : 1})

可以用這種方式對(duì)任意深層次的字段建立索引，比如你可以在"x.y.z.w.a.b.c"上建立索引。
注意，對(duì)嵌套文檔本身（"loc"）建立索引，與對(duì)嵌套文檔的某個(gè)字段（"loc.city"）建立索引是不同的。對(duì)整個(gè)子文檔建立索引，只會(huì)提高整個(gè)子文檔的查詢速度。在上面的例子中，只有在進(jìn)行與子文檔字段順序完全匹配的子文檔查詢時(shí)（比如db.users.find({"loc" : {"ip" : "123.456.789.000"， "city" : "Shelbyville"， "state" : "NY"}}})），查詢優(yōu)化器才會(huì)使用"loc"上的索引。無(wú)法對(duì)形如db.users.find({"loc.city" : "Shelbyville"})的查詢使用索引。

也可以對(duì)數(shù)組建立索引，這樣就可以高效地搜索數(shù)組中的特定元素。
假如有一個(gè)博客文章的集合，其中每個(gè)文檔表示一篇文章。每篇文章都有一個(gè)"comments"字段，這是一個(gè)數(shù)組，其中每個(gè)元素都是一個(gè)評(píng)論子文檔。如果想要找出最近被評(píng)論次數(shù)最多的博客文章，可以在博客文章集合中嵌套的"comments"數(shù)組的"date"鍵上建立索引：

> db.blog.ensureIndex({"comments.date" : 1})

對(duì)數(shù)組建立索引，實(shí)際上是對(duì)數(shù)組的每一個(gè)元素建立一個(gè)索引條目，所以如果一篇文章有20條評(píng)論，那么它就擁有20個(gè)索引條目。因此數(shù)組索引的代價(jià)比單值索引高：對(duì)于單次插入、更新或者刪除，每一個(gè)數(shù)組條目可能都需要更新（可能有上千個(gè)索引條目）。
與上一節(jié)中"loc"的例子不同，無(wú)法將整個(gè)數(shù)組作為一個(gè)實(shí)體建立索引：對(duì)數(shù)組建立索引，實(shí)際上是對(duì)數(shù)組中的每個(gè)元素建立索引，而不是對(duì)數(shù)組本身建立索引。
在數(shù)組上建立的索引并不包含任何位置信息：無(wú)法使用數(shù)組索引查找特定位置的數(shù)組元素，比如"comments.4"。
少數(shù)特殊情況下，可以對(duì)某個(gè)特定的數(shù)組條目進(jìn)行索引，比如：

> db.blog.ensureIndex({"comments.10.votes": 1})

然而，只有在精確匹配第11個(gè)數(shù)組元素時(shí)這個(gè)索引才有用（數(shù)組下標(biāo)從0開(kāi)始）。
一個(gè)索引中的數(shù)組字段最多只能有一個(gè)。這是為了避免在多鍵索引中索引條目爆炸性增長(zhǎng)：每一對(duì)可能的元素都要被索引，這樣導(dǎo)致每個(gè)文檔擁有n*m個(gè)索引條目。假如有一個(gè){"x" : 1， "y" : 1}上的索引：

> // x是一個(gè)數(shù)組—— 這是合法的
> db.multi.insert({"x" : [1, 2, 3], "y" : 1})
>
> // y是一個(gè)數(shù)組——這也是合法的
> db.multi.insert({"x" : 1, "y" : [4, 5, 6]})
>
> // x和y都是數(shù)組——這是非法的！
> db.multi.insert({"x" : [1, 2, 3], "y" : [4, 5, 6]})
cannot index parallel arrays [y] [x]

如果MongoDB要為上面的最后一個(gè)例子創(chuàng)建索引，它必須要?jiǎng)?chuàng)建這么多索引條目：{"x" : 1， "y" : 4}、{"x" : 1， "y" : 5}、{"x" : 1， "y" : 6}、{"x" : 2， "y" : 4}、{"x" : 2， "y" : 5}，{"x" : 2， "y" : 6}、{"x" : 3， "y" : 4}、{"x" : 3， "y" : 5}和{"x" : 3， "y" : 6}。盡管這些數(shù)組只有3個(gè)元素。

對(duì)于某個(gè)索引的鍵，如果這個(gè)鍵在某個(gè)文檔中是一個(gè)數(shù)組，那么這個(gè)索引就會(huì)被標(biāo)記為多鍵索引（multikey index）?？梢詮膃xplain()的輸出中看到一個(gè)索引是否為多鍵索引：如果使用了多鍵索引，"isMultikey"字段的值會(huì)是true。索引只要被標(biāo)記為多鍵索引，就無(wú)法再變成非多鍵索引了，即使這個(gè)字段為數(shù)組的所有文檔都從集合中刪除。要將多鍵索引恢復(fù)為非多鍵索引，唯一的方法就是刪除再重建這個(gè)索引。
多鍵索引可能會(huì)比非多鍵索引慢一些?？赡軙?huì)有多個(gè)索引條目指向同一個(gè)文檔，因此MongoDB在返回結(jié)果集時(shí)必須要先去除重復(fù)的內(nèi)容。

基數(shù)（cardinality）就是集合中某個(gè)字段擁有不同值的數(shù)量。有一些字段，比如"gender"或者"newsletter opt-out"，可能只擁有兩個(gè)可能的值，這種鍵的基數(shù)就是非常低的。另外一些字段，比如"username"或者"email"，可能集合中的每個(gè)文檔都擁有一個(gè)不同的值，這類(lèi)鍵的基數(shù)是非常高的。當(dāng)然也有一些介于兩者之間的字段，比如"age"或者"zip code"。
通常，一個(gè)字段的基數(shù)越高，這個(gè)鍵上的索引就越有用。這是因?yàn)樗饕軌蜓杆賹⑺阉鞣秶s小到一個(gè)比較小的結(jié)果集。對(duì)于低基數(shù)的字段，索引通常無(wú)法排除掉大量可能的匹配。
假設(shè)我們?cè)?gender"上有一個(gè)索引，需要查找名為Susan的女性用戶。通過(guò)這個(gè)索引，只能將搜索空間縮小到大約50%，然后要在每個(gè)多帶帶的文檔中查找"name"為"Susan"的用戶。反過(guò)來(lái)，如果在"name"上建立索引，就能立即將結(jié)果集縮小到名為"Susan"的用戶，這樣的結(jié)果集非常小，然后就可以根據(jù)性別從中迅速地找到匹配的文檔了。
一般說(shuō)來(lái)，應(yīng)該在基數(shù)比較高的鍵上建立索引，或者至少應(yīng)該把基數(shù)較高的鍵放在復(fù)合索引的前面（低基數(shù)的鍵之前）。

上一篇文章：MongoDB指南---10、索引、復(fù)合索引 簡(jiǎn)介
下一篇文章：MongoDB指南---12、使用explain()和hint()、何時(shí)不應(yīng)該使用索引