MongoDB實戰第二版筆記（9）第八章筆記
1、正確設置索引，MongoDB可以高效使用其硬件，並且快速服務查詢。而錯誤索引導致查詢減速、寫減速、惡化硬件設備使用。【高效使用MongoDB爲何要理解索引？】
2、索引分簡單索引和複合索引。
3、索引規則：
（1）索引可大大減少要處理的文檔數量。沒有適當索引，唯一滿足條件的查詢方式則是掃描全部文檔，直到找到滿足條件的查詢。這通常指的是查詢整個集合。
（2）唯一的單鍵索引將會用來處理查詢【 $or操作符查詢是例外】。對於包含多個鍵的查詢，包含這些鍵的複合索引是最好的解決方案。
（3）如果有一個複合索引a-b，那麼a上的索引是多餘的，b上的不多於。
（4）複合索引的鍵值順序很重要。
4、單鍵索引。每個索引入口對應文檔索引裏的單個值。默認的索引在_id字段。
5、複合索引。2.6版本後可以一個查詢使用多個索引，但最好還是隻使用一個索引。複合索引是每個入口由多個鍵值組成的單個索引。
6、MongoDB絕大部分索引使用B-樹結構。B樹結構的特點：一、方便各種查詢，包括精確匹配、範圍條件查詢、排序、前綴匹配、索引查詢。二、在添加和刪除鍵值之後都會保持平衡。
7、唯一索引，會確保在所有文檔中的一致性，要創建指定unique參數即可。
db.users.createIndex({username:1},{unique:true})
如果在集合上需要唯一索引，最好在插入數據之前創建索引。提前創建索引，可以確保從開始建立約束。當在包含數據的集合上創建唯一索引可能會失敗，因爲集合中可能存在重複數據。當重複鍵值存在，則索引創建失敗。
8、要在已有集合上創建唯一索引，可以重複嘗試創建唯一索引，用錯誤信息刪除重複鍵值。如果數據部重要，可以用dropDups參數來讓MongoDB刪除重複鍵值，但該參數在3.0版本已刪除，可以創建新集合，在新集合上創建，然後從舊集合複製到新集合（確保複製過程中忽略錯誤或手動處理重複鍵值）。
9、稀疏索引，只有包含某些索引鍵值的文檔纔會出現，要創建，則指定{sparse:true}。
10、使用稀疏索引的情況：
- 想在集合裏不是每個文檔中都出現的字段上建立唯一索引
- 集合中大佬文檔不包含所有鍵值
11、多鍵索引。思想是多個索引入口或鍵值，引用同一個文檔。智能使用該索引對MongoDB scheme設計十分重要。
12、哈希索引。通過hashed參數創建。
db.recipes.createIndex({recipe_name:'hashed'})
因爲所言值是最初參數的哈希值，所以有如下限制：
- 等值查詢相似，不支持範圍查詢
- 不支持多鍵哈希
- 浮點數在哈希之前轉換爲整數
既然有這些限制爲什麼使用哈希? 因爲哈希索引上的入口是均勻分佈的。當有鍵值數據不均勻分佈時，哈希函數可以創建均勻性。哈希索引可以跨片或跨機存儲。
13、地理空間索引。功能是查詢某個地點附近的文檔，基於經緯度來存儲每個文檔。
14、創建索引是createIndex()方法，原理創建一個帶有新索引的文檔並把它存儲到專門的system.indexes集合。刪除則使用deleteIndexes。
use green
db.runCommand({deleteIndexes:"users",index:"zip"})
15、使用getIndexes（）方法檢查索引規範。也可以使用dropIndex方法刪除索引。
use green
db.users.dropIndex("zip")
16、索引構建分兩步，第一步對構建索引的值進行排序。排序過的值插入B-樹裏效率更高，排序進度使用有序文檔佔全部文檔的比例表示。第二步，排序後的值插入索引中，構建索引花費時間使用插入system.indexes的時間來指示。
17、可以使用currentOp()方法來檢查索引構建進度。
18、如果在生產情況下無法停止數據庫訪問，可以指定在後臺構建索引。只需要聲明索引時指定{background:true}參數就可以【構建索引會佔用寫鎖，但允許其他用戶讀/寫數據庫，後臺索引有時會影響性能】。
db.values.createIndex({open:1,close:1},{background:true})
19、離線索引。由於後臺構建索引可能對生成服務器造成無法接受的壓力，就需要離線構建索引。這需要離線複製一個新的服務器節點，在此服務器上創建索引，並允許此服務器複製主服務器數據。一旦更新完畢，就把此服務器當主服務器，然後採用第二臺離線服務器構建其所有的版本。
該策略假設複製oplog日誌足夠大，以避免脫機服務器在索引構建中丟失數據。
20、索引碎片最大問題是實際空間遠遠大於數據所需空間，導致使用更多的內存空間，則考慮重建索引。
使用reIndex命令重新創建索引。
db.values.reIndex()
21、查詢優化是找出慢速查詢，發現問題並解決問題的過程。
22、MongoDB日誌器會打印索引查詢時間超過100ms的操作，可以作爲分析慢速查詢的第一個入口。
23、可用下面命令簡單的實現查詢工作
grep -E '[0-9]+ms' mongod.log
在啓動MongoDB可以設置-slowms參數記錄超過多少ms的操作。
24、FROFILER通常被禁用，如果找不到比內置分析器更好的工具則使用該工具分析慢速查詢。
use stocks
db.setProfilingLevel(2)
首先選擇要監控的數據庫，分析範圍是某個數據庫。分析級別爲2.則會告訴分析器記錄每個讀/寫操作。爲1，記錄慢速操作耗時超時100ms的。爲0，只記錄耗時超時的操作，傳遞毫秒爲第二個參數。
db.setProfillingLevel(1,50)
25、監控結果保存到特殊的蓋子集合，system.profile裏，存儲在執行setProfilingLevel命令的數據庫中。
蓋子集合，固定大小，一旦達到最大數量，新文檔取代舊文檔。
system.profile集合分配128KB，確保監控分析數據不耗費太多資源。
26、查詢所有耗時超過150ms的操作
db.system.profile.find({millis:{$gt:150}})
27、監控策略：
- 使用監控分析器良好方式是使用粗略設置和向下工作模式啓動它【先確保沒有超過100ms的，再繼續75ms的】。
- 啓用監控分析器後，若要監控所有應用程序的操作，則意味測試所有應用程序的讀取和寫入操作
- 要徹底分析問題，則這些讀/寫操作應在真實條件下執行，當數據大小、查詢負載、硬件與生產環境一樣時，查詢效果最好。
28、最簡單的情況，缺少所有，不恰當的索引低於期望查詢，可以用explain命令找出原因。
29、查詢優化器使用的簡單規則：
- 避免scanAndOrder。如果查詢包含排序，則嘗試使用索引排序
- 使用有用索引約束滿足所有字段—嘗試爲查詢選擇器中的字段使用索引
- 如果查詢包含範圍或者排序，則選擇最後一個key使用的索引來幫助處理範圍和排序。
如果對任意的索引這些條件都滿足，則所有索引就會是最佳的而且可以使用。如果多個索引都最佳，則任意選擇其中一個。如果可以爲查詢構建最佳索引，就可以大大簡化優化器的工作，因此請儘量做到。
30、優化器在下列事件發生後會自動過期計劃：
- 集合中寫入了100次
- 集合新建或者刪除了所有
- 如果查詢計劃的查詢做了比期望更多的工作。衡量“更多的工作”用的是nscanned的值超過了緩存的nscanned的值至少是10。
31、單鍵索引的應用環境：
- 精確匹配。無論是返回0個，1個還是多個結果都使用索引。
- 排序：在索引字段上排序
- 範圍查詢。可能在同一個字段上使用或不使用排序
32、複合索引的可能應用場景：
- 精確匹配。在第一個鍵上精確匹配。第一和第二個鍵，或第一，第二和第三個鍵使用指定的順序
- 範圍匹配。在任意集合最左邊鍵（包括none)上的精確匹配，並且使用限制範圍或者排序。
- 覆蓋索引。是索引的特殊使用。當需要的數據都駐留在所有裏，索引可以說覆蓋了查詢，又稱爲索引查詢。因爲這些查詢不需要訪問具體的索引文檔。