線上某業務，頻繁出現iops 使用率100%的（每秒4000iops）現象，每次持續接近1個小時，從慢請求的日誌發現是乙個 getmore 請求耗時1個小時，導致iops高；深入調查之後，最終發現竟是乙個索引選擇的問題。
2017-11-01t15:04:17.498+0800 i command [conn5735095] command db.mycoll command: getmore cursorid:215174255789 keyupdates:0 writeconflicts:0 numyields:161127 nreturned:8419 reslen:4194961 locks: }, database: }, collection: } } protocol:op_command 3651743ms* created_at:
* sort:
整個執行路徑為
通過 created_at 索引，快速定位到符合條件的文件
讀出所有的滿足 created_at 查詢條件的文件
對所有的文件根據 _id 字段進行排序
如下是走這個索引的2條典型日誌，可以看出
整個執行路徑為
根據 _id 索引，掃瞄所有的記錄 （按_id索引的順序掃瞄，對應的文件的created_at是隨機的，無規律）
把滿足 created_at 條件的文件返回，第一次find，要找到101個符合條件的文件返回
如下是走這個索引的2條典型日誌，可以看出
iops高是因為選擇的索引不是最優，那為什麼mongodb沒有選擇最優的索引來執行這個任務呢？
mongodb 的索引是基於取樣代價模型，乙個索引對取樣的資料集更優，並不意味著其對整個資料集也最優
最懂資料的還是業務自身，對於查詢優化器搞不定的case，可以通過在查詢時加 hint，自己指定的索引來構建執行計畫。
論資料庫索引的重要性
開發人員一般對資料庫的研究都不是太深，很多情況下都會只關心業務層的邏輯跟 的效能優化，尤其是初學者，對資料庫的研究都比較有限。例如 做乙個簡單的查詢或者修改 功能時 本來是一段非常簡單的sql語句。update couponsinfodn set parentresvno fca77a15 771d...
論搜尋引擎solr與MongoDB的整合
環境 ubuntu 12.04 solr 5.1.0 mongodb db version v2.0.4 solr安裝配置到目前已經非常簡單，參考官方文件 官方文件中用的是cloud這個樣例 e 指定 最後，我採用的是techproducts，基本命令如下 ls solr solr 5.1.0.zi...
聚集索引的重要性和如何選擇聚集索引
聚集索引的重要性和如何選擇聚集索引 在上一節的標題中，筆者寫的是 實現小資料量和海量資料的通用分頁顯示儲存過程。這是因為在將本儲存過程應用於 辦公自動化 系統的實踐中時，筆者發現這第三種儲存過程在小資料量的情況下，有如下現象 1 分頁速度一般維持在1秒和3秒之間。2 在查詢最後一頁時，速度一般為5秒...