mongodb优化该从哪些方面入手？有哪些实用技巧

mongodb优化中的索引设计方法

给mongodb做优化，索引绝对是绕不开的坎，就像图书馆的目录，没有它找书得翻遍整个书架，有了它能直接定位到目标区域，我之前帮一个做生鲜电商的朋友调过mongodb，他们后台查用户最近订单时总卡壳，打开慢查询日志一看，发现查询条件里用了用户ID和订单时间，但这俩字段根本没建索引，每次都全表扫描，后来我给这俩字段建了个复合索引，查询耗时从原来的3秒多直接降到了0.2秒,朋友当时眼睛都亮了。

索引设计得好，性能能上天；设计得烂，还不如没有。常见的索引类型有单字段索引、复合索引、地理空间索引这些，单字段索引适合按单个条件查询，比如按用户ID查数据；复合索引则适合多条件组合查询，像刚才说的用户ID+订单时间就很合适，但要注意，复合索引的字段顺序有讲究，把过滤性强的字段放前面效果更好，别贪多建索引，索引会占存储空间，还会拖慢写入速度，就像给书贴太多标签,反而找不到重点了。

mongodb优化如何提升查询性能

查询性能是mongodb优化的重头戏，毕竟用户最直观的感受就是快不快，除了索引，查询语句本身也有很多优化空间，我之前见过一个团队写的查询，明明只需要查几个字段，却用了select *，结果返回的数据量超大，网络传输都慢半拍，后来改成只返回需要的字段，响应速度立马快了不少，这就像去超市买东西，列好清单只拿需要的,比把整个货架都搬回家效率高多了。

合理使用投影、限制返回条数、避免全表扫描，这些都是提升查询性能的基础操作。还有，聚合查询里的管道操作要注意顺序，先过滤再分组总比先分组再过滤效率高，比如统计每个分类下的商品数量，先match筛选出有效商品，再group分组统计，能少处理很多无效数据，用explain分析查询计划特别重要，能清楚看到查询走没走索引，有没有扫描过多文档，就像给查询做个CT,哪里有问题一目了然。

mongodb优化的配置参数调整

mongodb的配置文件里藏着不少性能开关，调好了能让数据库“跑”得更轻快，我之前帮一个做日志分析的公司优化时，发现他们用的还是默认配置，wiredTiger缓存大小设的是系统内存的50%，但他们服务器内存有64G，实际业务数据量没那么大，导致缓存浪费，后来把缓存调到30%，腾出来的内存给了操作系统缓存文件，读写速度反而提升了15%。

关键配置参数主要集中在存储引擎、连接池、日志这几块。比如wiredTiger的cache_size，建议设为系统可用内存的50%-70%，但别超过物理内存，不然容易内存溢出，连接池方面，maxIncomingConnections要根据业务并发量调整，设太小会导致连接排队，设太大又会消耗过多资源，一般建议根据服务器CPU核心数来定，比如8核CPU设个500-800连接就差不多，日志方面，开启journal日志能保证数据安全，但刷盘频率可以调，默认是每100ms刷一次，业务对实时性要求不高的话，可以设成300ms,减少磁盘IO压力。

mongodb优化中的内存管理策略

mongodb特别“吃”内存，内存管理没做好，性能就是空中楼阁，我之前遇到过一个客户，他们的mongodb实例经常卡顿，一查内存使用率快到100%了，原来是把大量冷数据也放内存里，导致热数据被挤出缓存，后来帮他们清理了半年前的历史数据，又配置了TTL索引自动删除过期数据，内存使用率降到了70%,卡顿问题立马解决了。

内存管理的核心是让热数据常驻内存，冷数据及时清理。除了手动清理和TTL索引，还可以用mongodb的内存映射机制，让操作系统帮忙管理部分内存，别让mongodb和其他耗内存的服务抢资源，比如把数据库和应用服务放同一台服务器，结果两边都吃不饱，不如分开部署，各用各的内存，还有，定期检查内存使用情况，用mongostat看一下faults数值，如果持续很高，说明内存不够用了,该加内存或者优化数据了。

mongodb优化与其他数据库对比优势

跟MySQL、PostgreSQL这些关系型数据库比，mongodb在优化方向上有自己的特色，我之前帮一个做内容管理系统的客户选型，他们的文章数据结构特别灵活，有的文章有视频，有的有音频，还有的有长评论，用MySQL存的话得建好多表，查询时还得关联，特别麻烦，后来换成mongodb，一篇文章直接存成一个文档，字段可多可少，查询时一次就能取出来，优化起来也简单,主要调索引和内存就行。

mongodb的文档模型让它在处理非结构化、半结构化数据时优势明显，优化起来更聚焦于查询和存储效率。比如在水平扩展方面，mongodb的分片集群能轻松把数据分到多个节点，而MySQL分库分表配置复杂，优化起来更费劲，mongodb支持地理空间索引，做LBS应用时，查询附近的人或店铺，性能比关系型数据库好得多，不过要说事务支持，mongodb虽然也有，但复杂事务场景下还是MySQL更成熟,优化时得根据业务需求选对数据库。

mongodb优化的监控与维护方法

优化不是一锤子买卖，得定期监控和维护，不然时间长了性能又会掉下来，我有个朋友开了家在线教育公司，mongodb用了两年没怎么管，有天突然崩了，一查才发现索引碎片太多，查询效率暴跌，后来我教他用mongotop看实时读写情况，用db.stats()看数据量和索引大小，每周做一次索引重建,现在系统稳得很。

监控工具主要有mongostat、mongotop、MongoDB Compass，维护则包括索引重建、数据备份、日志清理。mongostat能看每秒的读写次数、连接数、缓存命中率这些关键指标，发现异常立马处理；mongotop能定位到哪些集合读写最频繁，方便针对性优化，备份的话，建议用mongodump定期全量备份，结合oplog做增量备份，万一数据丢了还能恢复，日志方面，别让日志文件无限增长，配置logRotate按大小或时间切割,既节省空间又方便排查问题。

mongodb优化的常见误区及解决

做mongodb优化时，新手很容易踩坑，我刚接触时也犯过不少错，有次帮一个电商平台优化，觉得索引越多查询越快，就给每个字段都建了索引，结果写入数据时慢得要死，订单都提交不上去，后来才知道，每个索引在写入时都要更新，索引太多会严重拖慢写入性能，最后只保留了常用查询的几个索引,写入速度才恢复正常。

常见误区主要有过度建索引、忽略分片策略、不重视数据类型优化。除了刚才说的过度建索引，分片策略也很容易被忽略，数据量大了不分片，单节点扛不住压力，优化到天也没用，正确的做法是提前规划分片键，比如按用户ID范围分片，让数据均匀分布到各个节点，数据类型优化也很重要，比如用int存数字就别用string，用date存时间就别用字符串，类型不对不仅占空间，查询时还可能走不了索引,白白浪费性能。