MongoDB慢查询性能分析

最近，长期运营后的港台服出现一个问题，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大小缩小到原来一半，成效卓著