Meteor应用搭配MongoDB运行缓慢求助：慢查询、多查询、单用户多连接

看来你碰到MongoDB的性能瓶颈了，结合你日志里发现的三个现象，我给你梳理一套落地性强的排查思路和解决建议：

• 先确认索引是否真的在生效：用db.collection.explain("executionStats").find(你的查询条件)执行查询，重点看executionStats里的executionTimeMillis（实际耗时）、totalDocsExamined（扫描文档数）和totalKeysExamined（扫描索引键数）。如果totalDocsExamined远大于返回结果数，说明索引没被正确使用——可能是查询条件里有隐式类型转换、索引选择性太差，或者复合索引的顺序不对。
• 检查索引碎片：长期增删改会导致索引碎片化，拖慢查询速度。小集合可以直接用db.collection.reIndex()重建索引；大集合建议选低峰期，用db.collection.createIndex(..., {background: true})后台重建。也可以用db.collection.stats().indexDetails查看碎片率，超过30%就建议重建了。
• 验证内存是否足够：MongoDB严重依赖内存缓存热数据，如果工作集（经常访问的数据）超过了wiredTigerCacheSizeGB设置的缓存大小，会频繁触发磁盘IO，导致查询变慢。可以用db.serverStatus().wiredTiger.cache查看缓存命中率，命中率低于95%的话，建议调整缓存大小（不要超过物理内存的60%）。
• 精简查询逻辑：比如是否拉取了不需要的字段，尽量用find({...}, {field1:1, field2:1})只返回必要字段；或者是否有不必要的排序/聚合，尽量让排序在索引层面完成，避免内存排序。

• 检查后台定时任务：比如统计脚本、数据同步任务、缓存刷新任务，这些可能在后台持续发起查询。用db.currentOp()查看当前正在运行的操作，能定位到发起查询的客户端IP和操作类型。
• 排查隐式请求：比如前端的轮询接口（心跳检测、实时数据更新）、ORM框架的懒加载（关联对象自动触发查询），甚至是后端的监控工具、日志采集中间件，都可能偷偷发起查询。
• 检查MongoDB内部操作：分片集群的chunk迁移、后台索引构建、数据压缩任务等内部操作，也会产生查询负载。可以用db.currentOp({"op": "command", "command.createIndexes": {$exists: true}})排查是否有后台索引在构建。

• 调整连接池配置：后端应用的数据库连接池如果设置了过大的最大连接数，单个用户的高并发请求会创建多条连接。建议根据服务器性能调整，一般设置为CPU核心数的2-4倍就足够了。
• 排查连接泄漏：应用程序是否存在未正确释放连接的情况？比如查询后没有关闭游标，或者异常情况下连接没有归还到池里。可以用db.serverStatus().connections查看当前连接数，对比应用的连接池配置，看是否有异常增长。
• 设置连接超时：在连接字符串里加上maxIdleTimeMS=300000（5分钟）和connectTimeoutMS=10000（10秒），让空闲连接自动释放，避免无效连接占用资源。

按照这个顺序排查，一般能定位到大部分性能问题。如果还是找不到根源，可以开启MongoDB的慢查询日志（把slowms设置为50ms），更细致地记录慢查询的详细信息，方便进一步分析。

内容的提问来源于stack exchange，提问作者Little Brain