存儲優化(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. 修復數據庫索引判斷錯誤可以通過強制索引，或者調整語句引導數據庫作出正確的判斷。

參考

https://mongoing.com/archives/5624