誒誒誒誒！！MongoDB竟然換武器攻擊小菜雞了，難道是小菜雞終於成長到，可以輕鬆接下aggregate的攻擊，所以換武器了嗎？（才不是作者想不到aggregate還有什麼運用可以介紹，所以換主題的）

所謂的Index索引，可以想像資料庫的資料就像百科全書的每一頁內文，而index就是書裡面的目錄，透過瀏覽目錄你可以快速找到你想要看的內容是在第幾頁。

而Index是如何快速找到資料，這就必須先提到在MongoDB儲存index會使用到的 B tree 資料結構。

假設我們現在利用 B tree 儲存1–7的數字，如下圖

資料儲存時會按照數字大小進行排序，左邊的數值會小於右邊的數值，在進行資料搜尋時，會有一個好處是一次可以排除一半的資料，加快搜尋速度。

例如：我們現在要搜尋５所在的位置，一開始會先從樹的最頂端開始找起，５先與４比對，比較大所以往右邊往下找，遇到６跟它比對，比較小所以往左邊走，最後找到資料。

如果是一個一個資料比對，最慘的情況下會比對７次，但如果是用B tree儲存資料，搜尋時最慘只會比對３次，如果我們把資料拉大成100筆資料，最多也只需要比對７次，不會比對到100次這麼多。

因為上述的特性，在資料的數量很龐大的情況下，建立索引的確可以加快搜尋的速度，但並不是所有情境都適合建立索引。

比如說我們現在有交易訂單的紀錄，每天都有好幾百筆資料寫入，但是會計部門只會在每個月底搜尋訂單算帳，這時候就不適合建立索引，因為資料會頻繁的寫入。

而且除了一般寫入的行為，MongoDB還必須額外寫入索引，同時為了確保B tree儲存資料會按照指定的順序，再寫入時會頻繁變動到 B tree的結構，所以寫入時會花費比較多的時間，而我們實際搜尋的次數卻很少，因此不太適合建立索引。

如上圖，我們寫入越多筆資料，B tree的樹狀結構就會有更多的分支出現，也更多層。

PS . 如果大家想動手，輸入資料建立 B tree ，在這裡推薦一個視覺化的網站B-Tree Visualization，上述的圖片都是用這個網站做出來的，在輸入資料時，也可會有動畫看到 B tree的樹狀結構是怎麼改變的。

本篇文章同步放在我的部落格，大家有空可以進來逛逛