存儲優化(3)-mongo大表加索引

摘要

在存儲優化(2)-排序引發的慢查詢優化中咱們提到過排序對查詢選擇索引的影響。可是的解決辦法就是增長一個索引。在線上給mongo的大表增長一個索引要慎重。在增長索引的過程當中也遇到了一些問題，這邊進行相關的記錄與分析。

問題描述

表結構

_id,
biz_Id,
version,
name
複製代碼

索引

1. 主鍵索引
2. biz_id,version聯合索引
複製代碼

查詢語句

"query":{"find":"historyRecord","filter":{"bizId":1234567},"sort":{"_id":-1},"limit":1}}
複製代碼

增長一個索引

bizId,_id
複製代碼

增長索引過程

對於大表（該表記錄數5億），創建索引過程涉及到鎖表，大量的讀寫操做、數據同步，確定會影響線上的操做。因此選擇在業務低谷期，創建一個background的index,這樣不會鎖表。 注：

mongo4.2之後優化了創建索引過程，不須要background參數了https://docs.mongodb.com/manual/reference/command/createIndexes/#dbcmd.createIndexes

建立完索引後，經過客戶端鏈接，查看執行計劃，始終掃描一行。完美，走到了新的索引。

"executionStats" : {
       "executionSuccess" : true,
       "nReturned" : 1,
       "executionTimeMillis" : 0,
       "totalKeysExamined" : 1,
       "totalDocsExamined" : 1
複製代碼

而後再觀察幾天慢sql，大吃一驚發現仍是存在慢查詢，可是相同的語句，放到客戶端查詢的時候，又是執行的新索引。查看system.profiles中慢日誌

當時這條慢查詢語句走的是cached_plan.

也就是說，走的是plan cache，已經緩存的執行計劃。

那是否是由於這個索引是後來加的，plan-cache尚未更新的。清理掉執行計劃緩存，執行操做

db.historyRecord.getPlanCache().clear()
複製代碼

繼續觀察，發現並無什麼用。百思不得其解，在深刻解析 MongoDB Plan Cache找到一些思路，MongoDB的執行計劃

其中掃描N次中N是10倍的執行計劃緩存的索引掃描次數。

看了下緩存計劃中的

db.getCollection('historyRecord').getPlanCache().listQueryShapes()
    {
        "query" : {
            "bizId" : "xxxxx"
        },
        "sort" : 0
            "_id" : -1.0
        },
        "projection" : {}
    },
複製代碼

而該查詢使用"bizId,version"索引，而bizId="xxxx"下面的索引值是100左右。咱們的數據分佈，bizId，version在100之內的多是95%,只有5%的在100以上，這會給索引判斷形成誤判。

總結

最後解決是經過強制索引來避免索引誤判，固然也能夠將排序改爲

sort({bizId:-1,_id:-1})
複製代碼

這樣也不會誤判

總結一下：

1. 大表加索引，須要確保不會block表的其餘操做，儘可能選擇閒時，background方式建立
2. 增長完索引後，須要check索引是否發揮做用，只是經過explain有可能誤判，仍是須要結合數據庫的slowlog來判斷
3. 同一個查詢數據庫也不老是使用一個索引，會根據查詢狀況進行調整。須要結合plan cache等狀況來分析
4. 修復數據庫索引判斷錯誤能夠經過強制索引，或者調整語句引導數據庫做出正確的判斷。

參考

mongoing.com/archives/56…