2. 程式人生 > >關於mongodb建立索引的一些經驗總結

關於mongodb建立索引的一些經驗總結

阿新 • • 發佈：2019-01-10

想來接觸mongodb已經快一年了，對於它的索引知識也積攢了不少經驗，趁著這個月黑風高的夜晚，就把mongodb的索引總結一番吧。

一，索引介紹

    mongodb具有兩類索引，分別為單鍵索引和複合索引。

    1.單鍵索引是最簡單的一種索引，建立單鍵索引的開銷要比複合索引小很多。單鍵索引主要用於針對單值查詢的條件。

    2.複合索引是將文件中的幾個鍵聯合起來建立的一種索引，建立這種索引需要更多的空間與效能開銷。分別體現在：

        1).在給大量資料建立複合索引時，會阻塞資料庫的查詢，更不用說修改和插入操作了；

        2).插入一條資料時，要花費更多的時間來給複合索引加資料；

        3).建立的複合索引所站得空間大小根據資料的型別以及鍵的數量而有所不同。比如，如果你用五個NumberInt的鍵建立的複合索引的空間大小，並不會比兩個NumberInt和一個String型別建立的複合索引佔用更多的空間。索引在設計資料型別時，儘量將資料型別設定為NumberInt型別，以及儘量少使用string型別的資料做索引；

二，建立索引

    建立索引的語句很簡單。

    1.單鍵索引的建立：db.test.ensureIndex({name:1},{name:'index_name'})

    2.複合索引的建立：db.test.ensureIndex({name:1,age:1,sex:1},{name:'index_nas'})

三，索引優化

    索引的優化是一個重頭戲，需要詳細的來解釋。我得測試資料插入了100萬條。欄位分別為name,sex,type,time,id

    1.我們來看一個簡單的查詢：db.test.find({name:'name_1'})  相信大家對這個查詢已經很熟悉了，然後我們來看看這個語句的索引執行計劃：

{
	"cursor" : "BasicCursor",   查詢語句所用到的索引，而BasicCursor代表沒有索引
	"isMultiKey" : false,     是否為複合索引
	"n" : 1,       查詢到的結果數
	"nscannedObjects" : 1000000,    掃描的文件數量
	"nscanned" : 1000000,     掃面的索引數量
	"nscannedObjectsAllPlans" : 1000000,   //影響的所有的被掃描文件的總數量
	"nscannedAllPlans" : 1000000,      //所有被掃描的索引的總數量
	"scanAndOrder" : false,  是否排序
	"indexOnly" : false,
	"nYields" : 2,
	"nChunkSkips" : 0,
	"millis" : 342,   花費的時間
	"indexBounds" : {
		
	},
	"server" : "node1:27017"
}

    從這個執行計劃中可以看出，該條查詢語句查詢一條資料需要掃描整個表，這肯定扯淡了嘛，那這時候就該給這個欄位建立索引了，建立一個單鍵索引

    db.test.ensureIndex({name:1},{name:'index_name'})

    建立完索引之後，再來檢視看這條查詢語句的執行計劃：

{
	"cursor" : "BtreeCursor index_name",
	"isMultiKey" : false,
	"n" : 1,
	"nscannedObjects" : 1,
	"nscanned" : 1,
	"nscannedObjectsAllPlans" : 1,
	"nscannedAllPlans" : 1,
	"scanAndOrder" : false,
	"indexOnly" : false,
	"nYields" : 0,
	"nChunkSkips" : 0,
	"millis" : 0,
	"indexBounds" : {
		"name" : [
			[
				"name_1",
				"name_1"
			]
		]
	},
	"server" : "node1:27017"
}

    簡直是逆天啊，nscanned和nscannedObjects居然從100萬下降到1條，也就是查詢資料時，只掃描了一條就已經找到，而且花費的時間是0秒，沒有建立索引時，居然是342毫秒，絕對索引威武啊。

    2.這時候我想通過type和sex來組合查詢某一條件的資料: db.test.find({type:1,sex:0})  看看這句的執行計劃：

{
	"cursor" : "BasicCursor",
	"isMultiKey" : false,
	"n" : 55555,
	"nscannedObjects" : 1000000,
	"nscanned" : 1000000,
	"nscannedObjectsAllPlans" : 1000000,
	"nscannedAllPlans" : 1000000,
	"scanAndOrder" : false,
	"indexOnly" : false,
	"nYields" : 0,
	"nChunkSkips" : 0,
	"millis" : 529,
	"indexBounds" : {
		
	},
	"server" : "node1:27017"
}

    從這個計劃中可以看出，為了查詢幾萬條資料，它也掃描了整個表，很顯然，該建立索引了：

    db.test.ensureIndex({type:1,sex:1},{name:'index_ts'})

    建立完索引之後，再來執行查詢語句，看看執行計劃：

db.test.find({type:1,sex:0}).explain()
{
	"cursor" : "BtreeCursor index_ts",
	"isMultiKey" : false,
	"n" : 55555,
	"nscannedObjects" : 55555,
	"nscanned" : 55555,
	"nscannedObjectsAllPlans" : 55555,
	"nscannedAllPlans" : 55555,
	"scanAndOrder" : false,
	"indexOnly" : false,
	"nYields" : 0,
	"nChunkSkips" : 0,
	"millis" : 112,
	"indexBounds" : {
		"type" : [
			[
				1,
				1
			]
		],
		"sex" : [
			[
				0,
				0
			]
		]
	},
	"server" : "node1:27017"
}

    很顯然，絕對是一個最佳索引，因為n=nscannedObjects=nscanned了，而且查詢時間從529毫秒下降到112毫秒了，這也是一個質的飛躍，可以明顯的看到，它使用了剛剛建立的index_ts索引。

    現在我又有一個需求了，我想通過時間再來排序，好的，我們執行查詢語句： db.test.find({type:1,sex:0}).sort({time:-1})    我們來看看這個查詢語句的執行計劃：

{
	"cursor" : "BtreeCursor index_ts",
	"isMultiKey" : false,
	"n" : 55555,
	"nscannedObjects" : 1000000,
	"nscanned" : 1000000,
	"nscannedObjectsAllPlans" : 1000000,
	"nscannedAllPlans" : 1000000,
	"scanAndOrder" : true,
	"indexOnly" : false,
	"nYields" : 1,
	"nChunkSkips" : 0,
	"millis" : 695,
	"indexBounds" : {
		"type" : [
			[
				1,
				1
			]
		],
		"sex" : [
			[
				0,
				0
			]
		]
	},
	"server" : "node1:27017"
}

    看到沒，這個查詢語句跟上一個建立索引之後的查詢出來的結果相差還是很大的，scanAndOrder和millis,時間花費了將近700毫秒，而且在查詢完畢之後還要排序，這也太不近人情了，就加了一個排序操作，怎麼會讓它從白天鵝變成醜小鴨了呢？啊，關鍵引數就是scanAndOrder，意思就是在記憶體中把結果排序了嘛，那好啊，既然你如此薄情，那我就建個複合索引來對抗:   db.test.ensureIndex({type:1,sex:1,time:-1},{name:'index_tst'})

{
	"cursor" : "BtreeCursor index_tst",
	"isMultiKey" : false,
	"n" : 55555,
	"nscannedObjects" : 55555,
	"nscanned" : 55555,
	"nscannedObjectsAllPlans" : 55555,
	"nscannedAllPlans" : 55555,
	"scanAndOrder" : false,
	"indexOnly" : false,
	"nYields" : 0,
	"nChunkSkips" : 0,
	"millis" : 126,
	"indexBounds" : {
		"type" : [
			[
				1,
				1
			]
		],
		"sex" : [
			[
				0,
				0
			]
		],
		"time" : [
			[
				{
					"$maxElement" : 1
				},
				{
					"$minElement" : 1
				}
			]
		]
	},
	"server" : "node1:27017"
}

    看到了嗎？各種引數又回到最佳狀態了。這時候可能有人會問了，為什麼要把time放到索引的最後而不是其它位置呢？其實這在建立索引時是有要求的，即：

  1.  將等值索引放在最前面

  2. 儘量將排序欄位放在範圍欄位的後面

  3. $nin和$ne跟索引沒有關係

   接下來我們再給查詢語句加條件： db.test.find({type:1,sex:0,id:{$gt:1,$lt:500000}}) 執行計劃如下:

{
	"cursor" : "BasicCursor",
	"isMultiKey" : false,
	"n" : 55555,
	"nscannedObjects" : 1000000,
	"nscanned" : 1000000,
	"nscannedObjectsAllPlans" : 1000000,
	"nscannedAllPlans" : 1000000,
	"scanAndOrder" : false,
	"indexOnly" : false,
	"nYields" : 2,
	"nChunkSkips" : 0,
	"millis" : 553,
	"indexBounds" : {
		
	},
	"server" : "node1:27017"
}

    可以看到，只返回兩萬多條資料，但是卻掃描了整個表，這肯定是很蛋疼的事情嘛，索引走起：

    db.test.ensureIndex({type:1,sex:1,id:1},{name:'index_tis'})

{
	"cursor" : "BtreeCursor index_tis",
	"isMultiKey" : false,
	"n" : 55555,
	"nscannedObjects" : 55555,
	"nscanned" : 55555,
	"nscannedObjectsAllPlans" : 55555,
	"nscannedAllPlans" : 55555,
	"scanAndOrder" : false,
	"indexOnly" : false,
	"nYields" : 1,
	"nChunkSkips" : 0,
	"millis" : 137,
	"indexBounds" : {
		"type" : [
			[
				1,
				1
			]
		],
		"sex" : [
			[
				0,
				0
			]
		],
		"id" : [
			[
				1,
				1000000
			]
		]
	},
	"server" : "node1:27017"
}

    很顯然，這是個非常不錯的組合索引，那為何不把id放在其它地方，偏偏放在最後面呢？因為在mongodb中，索引是從左到右執行的，因此顯然要從左到右一次過濾最大數量的資料顯然type和sex的組合過濾資料量要比id高更多，因為id的忙查率要遠高於這兩個組合。

    接著再把按time排序加上，查詢：db.test.find({type:1,sex:1,id:{$gt:0,$lt:1000000}}).sort({time:-1}).explain()    

{
	"cursor" : "BasicCursor",
	"isMultiKey" : false,
	"n" : 55556,
	"nscannedObjects" : 1000000,
	"nscanned" : 1000000,
	"nscannedObjectsAllPlans" : 1000000,
	"nscannedAllPlans" : 1000000,
	"scanAndOrder" : true,
	"indexOnly" : false,
	"nYields" : 1,
	"nChunkSkips" : 0,
	"millis" : 725,
	"indexBounds" : {
		
	},
	"server" : "node1:27017"
}

    可以看到，這個查詢語句也是極其慢的，而且還要再記憶體中排序，所以肯定要建立索引了：

    db.test.ensureIndex({type:1,sex:1,id:1,time:-1},{name:'index_tist'}) 我們先這樣建立索引，看看執行計劃：

{
	"cursor" : "BtreeCursor index_tist",
	"isMultiKey" : false,
	"n" : 55556,
	"nscannedObjects" : 55556,
	"nscanned" : 55556,
	"nscannedObjectsAllPlans" : 55657,
	"nscannedAllPlans" : 55657,
	"scanAndOrder" : true,
	"indexOnly" : false,
	"nYields" : 0,
	"nChunkSkips" : 0,
	"millis" : 404,
	"indexBounds" : {
		"type" : [
			[
				1,
				1
			]
		],
		"sex" : [
			[
				1,
				1
			]
		],
		"id" : [
			[
				0,
				1000000
			]
		],
		"time" : [
			[
				{
					"$maxElement" : 1
				},
				{
					"$minElement" : 1
				}
			]
		]
	},
	"server" : "node1:27017"
}

    看到了沒有，雖然查詢時間縮短了，但是這個查詢結果還是會排序結果，好，我們再把索引改改：

    db.test.ensureIndex({type:1,sex:1,time:-1,id:1},{name:'index_tist'})

{
	"cursor" : "BtreeCursor index_tist",
	"isMultiKey" : false,
	"n" : 55556,
	"nscannedObjects" : 55556,
	"nscanned" : 55556,
	"nscannedObjectsAllPlans" : 55657,
	"nscannedAllPlans" : 55657,
	"scanAndOrder" : false,
	"indexOnly" : false,
	"nYields" : 0,
	"nChunkSkips" : 0,
	"millis" : 168,
	"indexBounds" : {
		"type" : [
			[
				1,
				1
			]
		],
		"sex" : [
			[
				1,
				1
			]
		],
		"time" : [
			[
				{
					"$maxElement" : 1
				},
				{
					"$minElement" : 1
				}
			]
		],
		"id" : [
			[
				0,
				1000000
			]
		]
	},
	"server" : "node1:27017"
}

    再來看看，快到什麼程度了，這個查詢的速度和引數條件已經比上一個索引的快了很多，那為什麼會出現這種情況呢？為什麼time在id的前後會有不同的表現？這是因為通過type和sex欄位過濾完之後，已經在記憶體中有了資料，而這些資料下一步需要怎麼辦？是先通過id來篩選，還是按照排序篩選呢？這裡有一個知識點，在把id放在time前面時，程式首先會取複合id值，然後再把複合的資料排序，但是如果id放在排序的後面，那麼程式將直接通過順序掃描索引樹的方式取出複合id範圍的資料。

四，總結

    1.mongodb建立索引難點在於排序和範圍查詢的欄位位置選擇

    2.mongodb的複合索引的索引擷取查詢是順序的，即如果(a:1,b:1,c:1},則可以是查詢{a:1},{a:1,b:1},{a:1,b:1,c:1}中得任何一種都會使用該索引，其它查詢情況將不會用到該索引；

    3.儘量建立更少的索引以提高資料庫效能

    4.以上的索引優化只是生產環境的一部分，具體情況可能還要看自己的業務來定

相關推薦

關於mongodb建立索引的一些經驗總結

想來接觸mongodb已經快一年了，對於它的索引知識也積攢了不少經驗，趁著這個月黑風高的夜晚，就把mongodb的索引總結一番吧。 一，索引介紹     mongodb具有兩類索引，分別為單鍵索引和複合索引。     1.單鍵索引是最簡單的一種索引，建立單鍵索引的開

MongoDB 建立索引的語法

1.為普通欄位新增索引，並且為索引命名 db.集合名.createIndex( {"欄位名": 1 },{"name":'idx_欄位名'}) 說明： （1）索引命名規範：idx_<構成索引的欄位名>。如果欄位名字過長，可採用欄位縮寫。        

MongoDB 建立索引導致鎖庫

MongoDB 建立索引導致鎖庫 背景描述 兩千多萬資料，204G 的資料建立索引，執行 db.collection.ensureIndex({key:1}) 之後，是要鎖庫的，開啟另一個終端，任何操作都不能執行。 根本原因 在資料庫建立索引時

Mongodb 建立索引並利用索引進行排序

python課上需要實現對經度和緯度進行排序，並篩選資料。 由於給出的資料很大，有1200W吧，而mongodb只能支援32MB的排序。。。 上網上搜了一下，決定建立索引，建立完索引之後就直接對資料進行排序了。 這裡貼一下實驗的資料型別： 這裡用的pyhton連線mongdb建

mongodb建立索引及索引優化效率案例

查詢監控結果 監控結果儲存在一個特殊的蓋子集合system.profile裡,這個集合分配了128kb的空間,要確保監控分 析資料不會消耗太多的系統性資源；蓋子集合維護了自然的插入順序,可以使用KaTeX parse error: Expected '}', got 'EOF' at end of input

開發流程及團隊規範化的一些經驗總結

一、開發前: 開發模式採用流行的敏捷流程極限程式設計模式(XP)。 計劃任務:根據市場客戶需求了及現有的開發能力制定版本迭代週期和開發需求，如兩到三週一次版本釋出，再後期推動中不斷修正。 1. 需求:由專案經理或產品經理編寫需要說明書(PRD),讓測試和開發明確開發需求(使用

Elasticsearch & Logstash -- 一些經驗總結

本文作為一些實踐經驗的總結，未必是最佳實踐，歡迎大家交流。 ES叢集環境： 節點配置：  8核CPU, 48GB記憶體, 4*2TB磁碟JBOD 節點數量：9 作業系統：CentOS 6.4 Final JDK 1.7.0_45 ES版本：1.2.1 1.  通過管線

處理bug的一些經驗總結

如何積累解決bug的經驗？ 遇到bug並解決了，詳細把bug表現描述出來，並把解決經過寫出來，做成筆記，就算以後不翻看，這樣至少會加深你對類似bug的印象，下回就會知道類似的問題如何解決； 程式執行緩慢，首先應該檢查資料結構是否合理，然後檢查遍歷這個資料結構的遍歷語句是否寫

專案的一些經驗總結

1、系統設計        在專案開始前的階段著重理解式樣書和需求，把握住專案整體框架（業務邏輯，程式流程）等大方向。然後根據式樣書的詳細程度確定是否需要詳細設計，詳細設計的製作可由高階程式設計師或專案經理參與設計，也可由程式設計師自身設計並整理形成文件，一方面促使對系統的理解和業務邏輯的正確把握，另一方面便

web api 中get和post一些經驗總結

        百度提示 常用的web api場景是一個介面多平臺呼叫，例如給安卓呼叫 給ios呼叫 給平板呼叫 主要為移動網際網路提供服務， web api雖然可以脫離iis自寄宿 但目前大多還是託管在IIS上的 會提示跨域呼叫錯誤 解決辦法好幾個 我採用cors(Cr

mongodb建立索引

一、索引 MongoDB 提供了多樣性的索引支援，索引資訊被儲存在system.indexes 中，且預設總是為_id建立索引，它的索引使用基本和MySQL 等關係型資料庫一樣。其實可以這樣說說，索引是凌駕於資料儲存系統之上的另一層系統，所以各種結構迥異的儲存都有相同或相似的索引實現及使用介面並不足為 奇

安卓App耗電量優化的一些經驗總結

1、準備工作 磨刀不誤砍柴工。開始優化工作之前，一定要確定“測試場景”和“測試用例” （1）應用後臺 ——滅屏 ——亮屏 （2）應用後臺 分析埋點資料 -> 找出高頻頁面 -> 頁面分類歸納 -> 總結出一系列場景 【備註】 <1>

關於程式設計的一些經驗總結

 編寫程式是一項系統而繁瑣的工作，它不僅需要程式設計人員具有一定的功底，更需要有良好的程式設計習慣和風格。良好的程式設計習慣和風格不僅可以使程式程式碼更易於讀懂和修改，更重要的是，它可以使程式的結構更加合理，有助於提高程式的執行效率。下面是我在程式設計中總結的一些經驗，供大家參考。 　　 設計順序 　　 在我

Altium Designer16繪制51單片機的一些經驗總結

改進 正常 排列 崩潰 寫博客 科技 紀念 ima 芯片 制作這塊51單片機的還是蠻艱辛的，應該是我水平太差，現在這塊51單片機已經穩定了，也把這塊板子制作過程中的一些問題及經驗總結記錄下來。這塊板子制作出了很大問題很大原因是因為我對Altium Designer16這個軟

內部業務系統的一些經驗總結

　　從業那麼久，之前做的要不就是軟體外包，要不就是C端的產品，對於B端，或者企業內部系統還真沒怎麼接觸。 　　最近這兩年都是接觸愜意內部業務系統，其實也就那麼一回事而已，產品的設計還是那樣，只是會多了一個業務方、對接人，相比起C端使用者的不明確，需要自己去研究，自己去嘗試，企業內部業務系統，會有更明確的需求

【原】深度學習的一些經驗總結和建議 | To do v.s Not To Do

前言：本文同步釋出於公眾號：Charlotte資料探勘，歡迎關注，獲得最新干貨～　　 　　昨天看到幾篇不同的文章寫關於機器學習的to do & not to do，有些觀點贊同，有些不贊同，是現在演算法崗位這麼熱門，已經不像幾年前一樣，可能跑過一些專案、懂點原理就可以了，現在對大家的要求更高，尤其工

「mysql優化專題」單表查詢優化的一些小總結，非索引設計（3）

flush src innodb atp show 優化 ase 驗證 where子句 單表查詢優化：（關於索引，後面再開單章講解） （0）可以先使用 EXPLAIN 關鍵字可以讓你知道MySQL是如何處理你的SQL語句的。這可以幫我們分析是查詢語句或是表結構的性能瓶頸。

3.MySQL優化---單表查詢優化的一些小總結(非索引設計)

sql優化 所有 結果集 單表 搜索 結果 查詢語句 cnblogs sel 整理自互聯網.摘要: 接下來這篇是查詢優化。其實，大家都知道，查詢部分是遠遠大於增刪改的，所以查詢優化會花更多篇幅去講解。本篇會先講單表查詢優化（非索引設計）。然後講多表查詢優化。索引優化設計以及

Hybrid APP混合開發的一些經驗和總結

後臺 機制 獲取 功能 前端 如果 導致 接口 編寫 寫在前面： 由於業務需要，接觸到一個Hybrid APP混合開發的項目。當時是第一次接觸混合開發，有一些經驗和總結，歡迎各位一起交流學習~ 1、混合開發概述 Hybrid App主要以JS+Native兩者

image_pyradid和自己的一些訓練經驗總結

nbsp 一個 技術 物體 感覺 自己的 其他 什麽 img 這是訓練的路錐、警示柱的數據,也就是小物體的.小物體有兩個定義,一個是本身像素少,另一個是物體相對於整張圖片的比例小 這是把圖片縮小到600 proposal_target_layer選取用來訓練的pro