今天分享下mongodb中關於索引的基本操作，我們日常做開發都避免不了要對程式進行效能優化，而程式的操作無非就是curd，通常我們
又會花費50%的時間在r上面，因為read操作對使用者來說是非常敏感的，處理不好就會被人唾棄，呵呵。
從演算法上來說有5種經典的查詢，具體的可以參見我的演算法速成系列，這其中就包括我們今天所說的「索引查詢」，如果大家對sqlserver比較了解
的話，相信索引查詢能給我們帶來什麼樣的效能提公升吧。
我們首先插入10w資料，上圖說話：
一：效能分析函式（explain）
好了，資料已經插入成功，既然我們要做分析，肯定要有分析的工具，幸好mongodb中給我們提供了乙個關鍵字叫做「explain"，那麼怎麼用呢？
還是看圖，注意，這裡的name欄位沒有建立任何索引，這裡我就查詢乙個「name10000」的姓名。
仔細看紅色區域，有幾個我們關心的key。
cursor: 這裡出現的是」basiccursor",什麼意思呢，就是說這裡的查詢採用的是「表掃瞄」，也就是順序查詢，很悲催啊。
nscanned: 這裡是10w，也就是說資料庫瀏覽了10w個文件，很恐怖吧，這樣玩的話讓人受不了啊。
n: 這裡是1，也就是最終返回了1個文件。
millis: 這個就是我們最最最....關心的東西，總共耗時114毫秒。
二：建立索引（ensureindex）
在10w條這麼簡單的集合中查詢乙個文件要114毫秒有一點點讓人不能接收，好，那麼我們該如何優化呢？mongodb中給
我們帶來了索引查詢，看看能不能讓我們的查詢一飛沖天.....
這裡我們使用了ensureindex在name上建立了索引。」1「：表示按照name進行公升序，」-1「：表示按照name進行降序。
我的神啊，再來看看這些敏感資訊。
cursor: 這裡出現的是」btreecursor"，這麼牛x，mongodb採用b樹的結構來存放索引，索引名為後面的「name_1"。
nscanned: 我擦，資料庫只瀏覽了乙個文件就ok了。
n: 直接定位返回。
millis: 看看這個時間真的不敢相信，秒秒殺。
通過這個例子相信大家對索引也有了感官方面的認識了吧。
三：唯一索引
和sqlserver一樣都可以建立唯一索引，重複的鍵值自然就不能插入，在mongodb中的使用方法是：
四：組合索引
有時候我們的查詢不是單條件的，可能是多條件，比如查詢出生在『1989-3-2』名字叫『jack』的同學，那麼我們可以建立「姓名」和"生日「
的聯合索引來加速查詢。
看到上圖，大家或者也知道name跟birthday的不同，建立的索引也不同，公升序和降序的順序不同都會產生不同的索引，
那麼我們可以用getindexes來檢視下person集合中到底生成了那些索引。
此時我們肯定很好奇，到底查詢優化器會使用哪個查詢作為操作，呵呵，還是看看效果圖：
看完上圖我們要相信查詢優化器，它給我們做出的選擇往往是最優的，因為我們做查詢時，查詢優化器會使用我們建立的這些索引來建立查詢方案，
如果某乙個先執行完則其他查詢方案被close掉，這種方案會被mongodb儲存起來，當然如果非要用自己指定的查詢方案，這也是
可以的，在mongodb中給我們提供了hint方法讓我們可以暴力執行。
五： 刪除索引
可能隨著業務需求的變化，原先建立的索引可能沒有存在的必要了，可能有的人想說沒必要就沒必要唄，但是請記住，索引會降低cud這三
種操作的效能，因為這玩意需要實時維護，所以啥問題都要綜合考慮一下，這裡就把剛才建立的索引清空掉來演示一下:dropindexes的使用。
MongoDB 第四天 索引操作
好，今天分享下mongodb中關於索引的基本操作，我們日常做開發都避免不了要對程式進行效能優化，而程式的操作無非就是curd，通常我們 又會花費50 的時間在r上面，因為read操作對使用者來說是非常敏感的，處理不好就會被人唾棄，呵呵。從演算法上來說有5種經典的查詢，具體的可以參見我的演算法速成系列...
8天學通MongoDB 第四天 索引操作
這些天專案改版，時間比較緊，部落格也就沒跟得上，還望大家見諒。好，今天分享下mongodb中關於索引的基本操作，我們日常做開發都避免不了要對程式進行效能優化，而程式的操作無非就是curd，通常我們 又會花費50 的時間在r上面，因為read操作對使用者來說是非常敏感的，處理不好就會被人唾棄，呵呵。從...
8天學通MongoDB 第四天 索引操作
今天分享下mongodb中關於索引的基本操作，我們日常做開發都避免不了要對程式進行效能優化，而程式的操作無非就是curd，通常我們 又會花費50 的時間在r上面，因為read操作對使用者來說是非常敏感的，處理不好就會被人唾棄，呵呵。從演算法上來說有5種經典的查詢，具體的可以參見我的演算法速成系列，這...