1.集群架构上进行读写分离。所有查询优先考虑在从库上读取，写操作在主库上执行。避免主库混合读写压力过大，也减少主库上读写记录的锁冲突。

connection string中readPreference 设置成secondarypreferred，C++ 驱动版本升级为3.1.3 mongo-cxx-driver（驱动升级，读写分离才生效） 。

2.热表msg_traces 索引优化

针对该慢查询创建联合索引 {"_id": 1, "account": 1, "app_key": 1, "s_pc": 1}。

3.mongodb 历史数据归档和删除

和开发同事沟通，根据实际业务需求，保留msgs、msg_traces 集合中一年左右的文档。在timestamp 字段上创建TTL索引。设置文档的过期时间为 3153600秒（365*24*3600）。

db.msgs.createIndex( { "timestamp ": 1 }, { expireAfterSeconds: 3153600 },{background: true} )

db.msg_traces.createIndex( { "timestamp ": 1 }, { expireAfterSeconds: 3153600 },{background: true} )

mongodb TTL索引将每隔60秒对过期数据执行一次删除操作。删除操作的持续实际取决于mongod 实例的负载。

4 .journal 日志的 commitIntervalMs 参数调整。

从默认的100ms调大到500ms。

目前通过读写分离和索引优化之后，原来分片1在业务高峰期间的cpu load 值由最高值250降低到5以内，优化效果非常明显。

mongodb 分片集群优化思路总结：

分片集群中出现某个分片负载特别高的情况。（往往是某个分片负载高，如果是多个分片节点负载都高，则需要逐个进行分析）

第一步：

首先通过top、iostat、vmstat、mongostat 等工具了解系统大致并发负载和读写比例，观察系统具体瓶颈所在。

第二步：

如果负载只是集中出现在某一个节点上，则通过 mongotop 工具先分析该mongodb实例的热点表是哪些并记录下来。

第三步：

通过 mlogfilter / mloginfo 工具分析业务高峰期间出现的TOP10 慢查询。

第四步：

定位需要优化的目标表,并进行查询优化。

通常第二步和第三步会出现很多相同的表。因为热点数据表和慢查询表往往存在相同的一些表。这些表就是我们需要优化的目标。

mongodb 分片表的优化大致从以下几方面着手：

1.查看表分片键、数据分布、数据总量、数据占用空间等信息。着重看数据分片键设置是否合理、数据分布是否均匀；

2.mloginfo 工具打印出来的慢查询信息中有每个慢查询的查询条件。确认慢查询表上是否有合适的索引满足查询条件执行。需要结合explain() 分析慢查询的具体执行计划。

3.选取业务高峰阶段的mongodb实例原始日志，搜索慢查询表相关的原始查询语句。记录这些原始查询语句，方便后续与开发同事沟通，看能否从业务场景上进行相应的优化。

4.对于日志、事件、会话信息等日志类型的表，可以按照业务需求，根据事件字段，只保留一定时间内的有效数据。通常这要与开发业务

沟通清楚。确认保留时间后，可以利用mongodb TTL索引特性，在特定时间字段上创建索引，设置记录过期时限。

第五步：

架构上做读写分离优化

如果在第三步找出来的 TOP10 慢查询不少是能有效利用索引的简单查询，正常情况下，执行应该很快（200ms之内）。

则需要考虑在架构上做读写分离的优化。因为热点表高并发的读写会让cpu 忙不过来，导致原本正常的查询都出现阻塞。

总之，mongodb 优化关键之处是找出系统瓶颈和问题根源。定位出需要优化的目标表后，简单地加个索引或者做个读写分离，性能问题往往就迎刃而解。

这个和医生看病颇为相似，通过望闻问切和各种医疗检验设备所反馈的数据和报告，再依据丰富的临床经验诊断出病因所在。找出病因后，开什么方子用什么药就是水到渠成的事了。当然，医生看病比给数据库做性能诊断复杂多了，误诊几率也不小。而且，数据库性能优化没找准原因还有不少试错的机会，但是医生试错成本就比较高了。所以当个好医生貌似比做个好DBA更难！

以上插了些题外话。优化上过程中，也需要和开发同事保持有效沟通。当我们理解慢查询产生的业务场景后，有时让开发同事配合做个简单的功能优化，头痛的性能问题也能随之解决。