最近，長期運營后的港台服出現一個問題，web充值很慢，用gm指令查詢玩家信息也很慢。最后定位到MongoDB查詢也很慢。
剛開始定位的時候，運營SA直接查指定的玩家，並反映很慢，就猜測是索引的問題。有可能是索引太大，沒法全部放進內存，導致讀索引需要多次讀取磁盤，最后整個查詢要4-5s才能完成。后來閱讀了一下MongoDB的文檔，發現其也是用B-Tree放索引的，也盡量將索引加載在內存里了。當然，索引有沒有在內存里這個指標，還是沒有日志或者查詢結果暴露的……
后來，對面運營客服提醒，只有指定角色比較慢，也讓運營的DBA做了分析，發現是有命中唯一索引的。優化只能去查詢部分字段，避免全量查詢來解決了。但是我讓對方SA導出了指定查詢慢的玩家數據，這個文檔只有不到4MB，ssd讀取這么小的數據不應該這么慢
於是繼續翻文檔，將explain、loglevel調整增加性能日志項、mongotop、mongostat等工具都玩了一遍，全部都提示查詢時間在毫秒級別，命中索引，沒看到哪個指標反映到現在秒級查詢時間的狀況
后來猜應該是字段太多，做了個小工具做分析，打印一個document里嵌套最深的字段，以及下級元素最多的字段。發現由於web充值慢的問題，台方客服一直往玩家身上發訂單，數據沒有及時清理，所以訂單字段掛了2000張訂單的信息……還有一處回收系統的設計缺陷，導致回收數據膨脹，一個數組有上萬大小。這可能導致了MongoDB將數據序列化成bson時產生性能問題，不過所有統計工具都不會分析bson化所需時間，好郁悶
於是按生效快慢程度排了優先級，分別針對幾個問題做處理。首先是將查詢接口做特化處理，去掉這次分析出的龐大字段，該方法生效最快，影響較小，但是由於歷史原因，具體用到的字段沒有明確列出，沒法做的太細和精准了。然后針對訂單問題，做了玩家上線后清理訂單的操作。最后，回收系統的bug做了修復，上線時做好數據清理
為了進一步壓縮玩家文檔大小，還緊急上線了一個orm方面的優化，如果一個結構體里都是默認字段，而該結構體也不在一個數組里，則整個結構體都不做存儲，減少默認字段對空間的占用問題。優化后，原來查詢慢的玩家，document大小縮小到原來一半，成效卓著