索引是一個(gè)擁有自己唯一存儲(chǔ)的對(duì)象，它為集合提供了一條快速訪問(wèn)路徑。索引的存在主要是為了提高性能，因此，在優(yōu)化MongoDB性能時(shí)，有效理解和使用索引是非常重要的。

1、B-樹(shù)索引

B-樹(shù)索引是MongoDB的默認(rèn)索引結(jié)構(gòu)。以下是B-樹(shù)索引結(jié)構(gòu)高等級(jí)的概述。

B-樹(shù)索引具有分層樹(shù)結(jié)構(gòu)。樹(shù)頂部是頭部塊。此塊包含指向任何給定范圍的鍵值的適當(dāng)分支塊的指針。分支塊通常會(huì)指向適當(dāng)?shù)娜~子塊以獲得更具體的范圍，或者對(duì)于更大的索引，則指向另一個(gè)分支塊。 葉子塊包含一個(gè)鍵值列表和指向磁盤(pán)上文檔位置的指針。

查看上面的圖，讓我們想象一下MongoDB如何遍歷這個(gè)索引。 如果我們需要訪問(wèn)“BAKER”的記錄，我們首先會(huì)查閱頭部塊。 頭部塊會(huì)告訴我們，從A到K開(kāi)始的鍵值存儲(chǔ)在最左邊的分支塊中。 訪問(wèn)這個(gè)分支塊，我們發(fā)現(xiàn)從A到D開(kāi)始的鍵值存儲(chǔ)在最左邊的葉子塊中。 咨詢這個(gè)葉子塊，我們發(fā)現(xiàn)值“BAKER”以及它關(guān)聯(lián)的磁盤(pán)位置，我們將用它來(lái)獲得有關(guān)的文件。

葉子塊包含前一個(gè)和后一個(gè)葉子塊的鏈接。 這允許我們以升序或降序掃描索引，并且允許使用$gt或$lt操作符的范圍查詢使用索引進(jìn)行處理。

與其他索引策略相比，B-樹(shù)索引具有以下優(yōu)點(diǎn)：

1. 由于每個(gè)葉子節(jié)點(diǎn)處于相同的深度，所以性能是非常可預(yù)測(cè)的。 從理論上講，集合中的任何文檔都不會(huì)超過(guò)三或四次I/O。
2. B樹(shù)為大型集合提供了良好的性能，因?yàn)樯疃茸疃酁樗膫€(gè)（一個(gè)頭部塊，兩個(gè)分支塊級(jí)別和一個(gè)葉子塊級(jí)別）。 一般來(lái)說(shuō)，沒(méi)有任何文件需要四個(gè)以上的I/O來(lái)定位。 實(shí)際上，因?yàn)轭^部塊幾乎總是已經(jīng)加載到內(nèi)存中，而分支塊通常加載到內(nèi)存中，所以實(shí)際的物理磁盤(pán)讀取次數(shù)通常只有一次或兩次。
3. 因?yàn)榕c前一個(gè)和后一個(gè)葉子塊的鏈接，所以B-樹(shù)索引支持范圍查詢以及精確的查找是可行的。

B-樹(shù)索引提供了靈活高效的查詢性能。但是，在更改數(shù)據(jù)時(shí)維護(hù)B-樹(shù)可能很昂貴。例如，考慮在上面的圖表中插入一個(gè)鍵值為“NIVEN”的文檔。要插入集合，我們必須在“L-O”塊中添加一個(gè)新條目。如果在這個(gè)區(qū)域內(nèi)有空閑空間，那么成本是很大的，但也許不會(huì)過(guò)多。但是如果塊中沒(méi)有可用空間會(huì)發(fā)生什么？

如果葉子塊中沒(méi)有空閑空間用于新條目，則需要索引拆分。必須分配新塊，并將現(xiàn)有塊中的一半條目移入新塊。除此之外，還需要在分支塊中添加一個(gè)新條目（以便指向新創(chuàng)建的葉子塊）。如果分支塊中沒(méi)有空閑空間，則分支塊也必須分割。

這些索引拆分是一項(xiàng)昂貴的操作：必須分配新塊，并將索引條目從一個(gè)塊移到另一個(gè)塊。

2、索引選擇性

屬性或?qū)傩越M的選擇性是對(duì)這些屬性的索引的有用性的常用度量。如果文檔或索引具有大量的唯一值或重復(fù)值很少，則它們是有選擇的。例如，DATE_AND_TIME_OF_BIRTH屬性將非常有選擇性，而GENDER屬性將不會(huì)被選擇。

選擇性索引比非選擇性索引更有效，因?yàn)樗鼈兏苯拥刂赶蛱囟ǖ闹?。MongoDB優(yōu)化器通常會(huì)使用最有選擇性的索引。

3、唯一索引

唯一的索引是阻止組成索引的屬性的任何重復(fù)值的索引。如果你嘗試在包含此類(lèi)重復(fù)值的集合上創(chuàng)建唯一索引，則會(huì)收到錯(cuò)誤消息。同樣，如果嘗試插入包含重復(fù)唯一索引鍵值的文檔，也會(huì)收到錯(cuò)誤。

通常會(huì)創(chuàng)建一個(gè)唯一索引，以防止重復(fù)值而不是提高性能。 但是，唯一的索引文件通常非常有效 - 它們只能指向一個(gè)文件，因此非常有選擇性。

4、連接索引

連接索引只是一個(gè)包含多個(gè)屬性的索引。連接鍵的優(yōu)點(diǎn)在于它比單個(gè)鍵索引更具有選擇性。屬性的組合將指向比由單個(gè)屬性組成的索引更少數(shù)量的文檔。包含find()或$match子句中引用的所有屬性的連接索引將特別有效。

如果你經(jīng)常查詢集合中的多個(gè)文檔，那么為這些文檔創(chuàng)建一個(gè)連接索引是一個(gè)很好的主意。例如，我們可以通過(guò)Surname(姓氏)和Firstname(名字)查詢people集合。在這種情況下，我們可能希望在Surname和Firstname上創(chuàng)建一個(gè)索引。例如：

 
 
 
 

  
  
  
  
db.people.createIndex({ "Surname":1 ,"Firstname":1}  ); 
 
 
 
 

使用這樣的索引，我們可以快速找到people中所有匹配給定的Surname \ Firstname 組合。 這樣的索引比單獨(dú)的Surname索引或單獨(dú)的Surname和Firstname索引要有效得多。

如果連接索引只能在所有鍵出現(xiàn)find()或$match時(shí)使用，則連接索引的使用可能會(huì)非常有限。幸運(yùn)的是，連接索引可以非常有效地使用，提供任何初始或主要屬性。主要屬性是在索引定義中最早指定的屬性。

上圖顯示了將屬性添加到連接索引時(shí)獲得的改進(jìn)。涉及的查詢是在一個(gè)1,000,000個(gè)文檔的people集合上：

 
 
 
 

  
  
  
  
db.people.find( 
  
  
  
  
 
  
  
  
  
  {    Firstname: "KAREN", 
  
  
  
  
 
  
  
  
  
    Surname: "SMITH", 
  
  
  
  
 
  
  
  
  
    dob: ISODate("2006-01-21T05:55:32.520Z") 
  
  
  
  
 
  
  
  
  
  }, 
  
  
  
  
 
  
  
  
  
  { _id: 0, tel: 1 } 
  
  
  
  
 
  
  
  
  
); 
 
 
 
 

例如，我們通過(guò)提供Surname，F(xiàn)irstname和dob來(lái)檢索電話號(hào)碼。

全面集合掃描要求我們?cè)L問(wèn)所有1,000,000個(gè)文檔。僅索引surname就減少到20,028個(gè)文件 - 實(shí)際上是收集中的所有“SMITHS”。添加firstname將文檔數(shù)減少到188個(gè)。通過(guò)添加dob，我們只需可以訪問(wèn)兩個(gè)：訪問(wèn)一個(gè)索引條目并從那里訪問(wèn)集合以獲取電話號(hào)碼。 ***的優(yōu)化是添加電話號(hào)碼tel屬性。 現(xiàn)在我們根本不需要訪問(wèn)集合 - 我們需要的就是索引。 這有時(shí)被稱(chēng)為“覆蓋”指數(shù)。

請(qǐng)注意，覆蓋索引通常要求查詢包含一個(gè)投影，以消除索引中包含的屬性以外的所有屬性。

5、連接索引指南

以下指南將有助于確定何時(shí)使用連接索引，以及如何確定應(yīng)包含哪些屬性以及按何種順序。

1. 在集合中為find()或$match條件一起出現(xiàn)的屬性創(chuàng)建連接索引。
2. 如果屬性有時(shí)會(huì)以find()或$match的形式出現(xiàn)，請(qǐng)將它們放在索引的開(kāi)頭。
3. 如果連接的索引還支持不是所有屬性都被指定的查詢，則連接索引更有用。 例如，createIndex({"Surname" : 1, "Firstname" : 1})比createIndex({"Firstname" : 1, "Surname" : 1})更有用，因?yàn)橹会槍?duì)surname的查詢比僅針對(duì)firstname的查詢更有可能發(fā)生。
4. 屬性越有選擇性，在索引的前端越有用。但是，請(qǐng)注意，WiredTiger索引壓縮可以從根本上縮小索引。當(dāng)領(lǐng)先的列較少選擇時(shí)，索引壓縮更有效。所以如果屬性的順序不是由前面三個(gè)考慮因素決定的，你可能不得不嘗試索引順序。 

總結(jié)

在MongoDB的優(yōu)化過(guò)程中，只有深入理解內(nèi)部的索引機(jī)制，我們才能更好的提升MongoDB的性能。

文章題目：帶你深入理解有效的MongoDB索引
文章來(lái)源：http://uogjgqi.cn/article/ccoeghh.html