分片集群慢查询需交叉验证mongos日志、各shard的system.profile及explain执行计划：mongos日志记录总耗时与路由问题，shard的profile反映实际执行效率，explain确认真实执行路径，三者时间戳对齐才能准确定位瓶颈。
分片集群的慢查询日志不能只看 system.profile，必须结合 mongos 日志、各 shard 的 profile 数据和执行计划三者交叉验证——因为一条查询可能在 mongos 解析、路由、合并阶段就已拖慢，而 system.profile 只记录最终落到某个 shard 上的执行细节。
mongos 日志里找“第一眼慢点”
mongos 不写 system.profile，它的慢操作只打在自己的运行日志里（默认和 mongod 分开）。关键要看 command 行末尾的耗时，比如：
2026-07-21T14:22:05.123+0000 I COMMAND [conn123] query test.orders filter: { status: "pending", created_at: { $gt: ... } } planSummary: SHARDING_FILTER ... 482ms
这个 482ms 是 mongos 从收到请求到返回结果的总耗时，包含网络、路由、结果合并时间。如果它远大于后端 shard 的 millis，说明瓶颈在 mongos 层。
- 检查是否频繁触发
SHARDING_FILTER：这表示 mongos 必须收全所有 shard 的结果再过滤，无法下推； - 留意
numShardsVisited字段：查 10 个 shard 却只命中 1 个，说明分片键设计不合理或查询没带分片键； - 如果日志中反复出现
stale config或refreshing metadata，说明 config server 压力大或元数据缓存失效频繁。
每个 shard 上单独查 system.profile
连接到每个 shard 的 primary 节点（不是 mongos），再查自己的 system.profile。注意三点：
- 必须用
use切到对应数据库，system.profile是数据库级集合； - 查的时候加
{ ns: "db.collection" }过滤，避免被其他库的 profile 干扰； - 重点比对
docsExamined和nreturned：比如docsExamined: 12000但nreturned: 12，说明索引区分度差或查询条件未有效利用前缀。
示例命令：
use orders_shard0<br>db.system.profile.find({ ns: "orders_shard0.orders", millis: { $gt: 200 } }).sort({ ts: -1 }).limit(3)
用 explain("executionStats") 复现慢查询
光看日志不够，得在对应 shard 上对慢查询语句跑 explain，确认真实执行路径：
- 确保在目标 shard 的 primary 上执行，且使用跟慢日志里完全一致的查询条件（包括字段顺序、嵌套结构）；
- 如果查询带
$lookup，explain 结果里会出现stage: "LOOKUP"，且其executionTimeMillisEstimate会显著偏高——分片环境下$lookup默认不支持跨 shard 关联，容易退化为多次单点查询； - 注意
executionStages.stage是否出现"COLLSCAN"：哪怕日志里写了IXSCAN，也可能是 mongos 路由错误导致 fallback 到全表扫描。
容易忽略的坑：profile 级别在分片集群里不自动同步
你在 mongos 上执行 db.setProfilingLevel(1, { slowms: 100 })，只影响 mongos 自身日志开关，**不会**自动开启所有 shard 的 profiling。每个 shard 必须单独连上去设置：
- 逐个连接每个 shard 的 primary：
mongo --host shard01:27018； - 在每个 shard 的目标 db 下执行：
db.setProfilingLevel(1, { slowms: 100 })； -
system.profile是 capped 集合（默认 1MB），数据会覆盖，所以分析窗口要窄，建议配合时间范围查：{ ts: { $gt: ISODate("2026-07-21T14:00:00Z") } }。
真正卡住的往往不是单条语句，而是某类查询在多个 shard 上同时低效执行，再经 mongos 合并放大——所以必须把 mongos 日志、各 shard profile、explain 三者时间戳对齐，才能定位是路由策略、索引缺失，还是分片键倾斜。
