如何用System.profile快速定位MongoDB分片集群中慢查询的具体分片

MongoDB分片集群慢查询节点快速定位实战

在MongoDB分片集群中排查慢查询时，一个常见困惑是：在mongos节点上无法查询到system.profile数据。请不要急于怀疑配置错误——这并非缺陷，而是架构设计使然。接下来我们将逐步解析，如何精确锁定导致整个集群性能下降的具体shard节点。

首先明确一点：在分片集群中，system.profile仅存在于各个mongod shard节点上。mongos并不执行任何查询逻辑，它只负责查询路由与结果聚合。因此，当你在mongos上执行db.setProfilingLevel()并收到{"ok": 0, "errmsg": "no profiling information a vailable"}时，无需担心——这是正常行为，因为mongos本身不执行查询，自然不会生成profile日志。

为什么在mongos上执行db.setProfilingLevel()无效？

简而言之：mongos并不执行查询操作，因此不会产生profile数据写入。

• 所有实际查询均在后台mongod实例上执行，profile日志仅写入对应shard节点的system.profile集合
• config server与mongos上的system.profile为空或不可用，即使连接也无法查询到业务查询记录
• 不要在mongos上耗费时间创建索引或调整阈值——因为它根本不会写入profile数据

如何快速定位需要排查的shard节点？

首先需要明确查询具体发送到了哪些shard，然后逐一排查。不能仅凭猜测或仅根据节点负载高低直接连接。

• 在mongos上执行sh.status()，密切关注目标集合的chunks分布与shards列表，记录host字符串（例如shard02/10.0.1.20:27018,10.0.1.21:27018格式）
• 通过db.getSiblingDB("config").shards.find()获取每个shard的完整地址列表，筛选出可疑节点——若日志中频繁出现"planSummary":"SHARD_MERGE"，则该shard应作为重点排查对象
• 直连时优先选择secondary节点：mongo --host 10.0.1.21:27018 -u user -p pwd --authenticationDatabase admin，以避免给primary增加额外负载

连接shard后必须执行的三项操作

刚建立连接后不要急于执行find。若不完成以下三项操作，查询可能速度缓慢、数据遗漏或根本无法获取结果。

• 立即创建索引：db.system.profile.createIndex({ ts: -1 })。否则，find({millis: {$gte: 50}}).sort({ts: -1})会触发全表扫描，原本几秒钟的操作可能延长至几十秒
• 调低slowms阈值：db.setProfilingLevel(1, {slowms: 50})。在分片环境中，单个shard的执行时间可能仅为10–20ms，但经过网络传输和结果合并后，总耗时可能超过300ms。若不降低阈值，这些“看似正常”的查询将无法被记录
• 配置完成后立即验证是否生效：db.getProfilingStatus()应返回"was": 1且"slowms": 50，才表示已正确启用

如何解读查询结果以避免误判

不要仅关注millis数值。例如，一个耗时320ms的请求在mongos日志中可见，但在shard的system.profile中可能只显示几个millis: 7的记录——这属于正常现象，因为每个shard仅记录自身执行的部分。

• 重点筛选docsExamined > nreturned * 10的记录。例如docsExamined: 50000, nreturned: 25表明索引未生效或已失效
• 检查planSummary：若出现"COLLSCAN"，或"IXSCAN"但keysExamined: 0，基本可判断为缺少索引
• 对疑似慢查询执行explain("executionStats")复现，重点关注shards字段下列出的节点数量。如果列出多个节点，说明触发了广播查询——很可能是因为缺少分片键

一个常被忽视的细节：profile数据默认仅保留最近1MB或30分钟（取决于capped size）。等到问题出现再临时启用profiler，数据可能已被覆盖。最佳实践是在关键shard上持续启用profiling，并定期检查索引是否仍然存在。