MongoDB查询性能的瓶颈往往隐藏在查询执行计划中。通过explain()获取的executionStats提供了查询执行的完整剖析是诊断性能问题的X光片。本文将系统阐述执行计划的核心指标提供可落地的诊断方法帮助您快速定位查询瓶颈将慢查询优化30%以上。一、查询执行计划基础为什么必须关注executionStats1.1 查询优化器的工作原理MongoDB查询优化器执行三步决策候选计划生成为查询生成多个可能的执行计划计划评估在测试集上运行各计划评估成本计划选择选择成本最低的计划作为最终执行方案关键洞察优化器可能选择次优计划尤其当索引统计信息过期时。1.2 executionStats vs queryPlanner指标queryPlannerexecutionStatsallPlansExecution数据范围仅计划信息计划执行统计计划所有执行路径统计执行开销低不执行查询高执行查询最高核心用途分析索引选择性能问题诊断深度调优适用场景开发环境预检生产问题排查复杂查询优化为什么必须用executionStats仅看queryPlanner会遗漏关键问题如索引碎片、数据分布不均执行统计是唯一能反映真实性能的指标。二、获取执行计划正确使用explain()方法2.1 基本语法// 获取执行统计推荐db.collection.explain(executionStats).find({...});// 获取所有执行路径统计高级诊断db.collection.explain(allPlansExecution).find({...});2.2 重要参数说明参数效果推荐场景maxTimeMS限制查询执行时间防止慢查询阻塞诊断verbosity指定返回级别默认queryPlanner必须设为executionStatscomment添加注释用于监控识别生产环境调优2.3 避坑指南错误1仅用db.collection.find().explain()→ 返回queryPlanner无执行统计正确做法db.collection.explain(executionStats).find({status:active});错误2在高负载生产环境直接执行→ 添加maxTimeMS保护db.collection.explain(executionStats).find({...}).maxTimeMS(500);三、executionStats核心指标深度解析3.1 概览层关键指标{executionTimeMillis:28,nReturned:15,executionStages:{...},allPlansExecution:[...]}指标含义健康值问题信号executionTimeMillis总执行时间ms 100ms 500msnReturned返回的文档数匹配业务预期远小于扫描数totalKeysExamined检查的索引条目总数≈ nReturned nReturnedtotalDocsExamined检查的文档总数≈ nReturned nReturnedexecutionStages执行阶段树核心诊断数据无COLLSCAN出现COLLSCAN黄金法则totalKeysExamined / nReturned 5且totalDocsExamined / nReturned 2否则必然存在性能问题。3.2 执行阶段树分析executionStages执行计划以树状结构呈现每个节点代表一个操作。关键节点类型Stage类型含义性能信号优化方向COLLSCAN全表扫描严重问题必须创建索引IXSCAN索引扫描健康状态检查索引选择性FETCH通过索引获取文档正常步骤优化为覆盖索引SORT内存排序可接受添加排序索引SORT stage by index索引排序理想状态无需优化SHARD_MERGE分片合并分片集群特有检查分片键设计典型执行计划示例executionStages:{stage:FETCH,nReturned:15,executionTimeMillisEstimate:25,docsExamined:15,inputStage:{stage:IXSCAN,indexName:status_1_user_id_1,keysExamined:15,indexBounds:{...}}}健康信号keysExamined nReturned 15无COLLSCAN或SORT3.3 索引边界分析indexBoundsindexBounds:{status:[[\active\, \active\]],user_id:[[1000, 1000]]}等值查询[[value, value]]范围查询[[min, max]]问题信号空边界索引未使用[[MinKey, MaxKey]]索引前缀未命中诊断技巧若user_id边界为[[MinKey, MaxKey]]说明查询条件未使用user_id可能索引顺序错误。四、性能问题诊断4大类常见问题与解决方案4.1 全表扫描问题COLLSCAN症状executionStages:{stage:COLLSCAN,filter:{status:active},docsExamined:120000}根本原因缺少必要索引查询条件未匹配索引前缀索引被拒绝统计信息过期解决方案创建缺失索引db.collection.createIndex({status:1});验证索引选择db.collection.getIndexes();刷新统计信息db.collection.aggregate([{$indexStats:{}}]);4.2 索引效率低下问题症状executionStages:{stage:FETCH,nReturned:25,keysExamined:120000,docsExamined:120000}指标分析keysExamined / nReturned 4,800→ 极低的索引选择性解决方案创建复合索引// 将 {status:1} 改为 {status:1, created_at:-1}db.collection.createIndex({status:1,created_at:-1});使用hint()强制索引临时方案db.collection.find({status:active}).hint(status_1_created_at_-1);4.3 内存排序问题SORT症状executionStages:{stage:SORT,sortPattern:{created_at:-1},memUsage:150000,// 字节数memLimit:104857600// 100MB}问题判定memUsage 0且 未出现SORT stage by index解决方案添加排序索引db.collection.createIndex({status:1,created_at:-1});限制排序数据量db.collection.find({status:active}).sort({created_at:-1}).limit(1000);// 避免大数据排序4.4 分片集群特殊问题症状executionStages:{stage:SHARD_MERGE,nReturned:15,totalChildMillis:1200}关键指标totalChildMillis子分片执行总时间高值表示分片数据分布不均解决方案检查分片键选择sh.status();// 查看chunk分布重新均衡数据sh.enableAutoSplit();sh.splitAt(collection,{shardKey:new_split_point});五、高级诊断技巧快速定位瓶颈5.1 索引选择性计算functioncalculateSelectivity(indexName){conststatsdb.collection.aggregate([{$indexStats:{}},{$match:{name:indexName}}]).next();consttotalDocsdb.collection.countDocuments();returnstats.accesses.ops/totalDocs;}// 选择性0.1为有效索引calculateSelectivity(status_1_user_id_1);健康值0.1每10个查询命中1次无效索引0.01 → 应删除5.2 多计划对比分析// 获取所有候选计划constplansdb.collection.explain(allPlansExecution).find({status:active});// 分析各计划性能plans.allPlansExecution.forEach(plan{print(Plan${plan.queryPlan.planId}:);print(Execution time:${plan.executionTimeMillis}ms);print(Docs examined:${plan.totalDocsExamined});});诊断价值对比被拒绝计划与最终计划的指标确定优化方向。5.3 内存使用监控// 检查排序内存使用db.serverStatus().metrics.queryExecutor.sorts;关键指标sorts总排序次数sorts.memoryUse内存排序次数sorts.time排序总耗时危险信号sorts.memoryUse / sorts 0.5→ 超50%排序使用内存需优化六、优化验证确保改进有效6.1 优化前/后对比// 优化前constbeforedb.collection.explain(executionStats).find({status:active});// 创建索引...db.collection.createIndex({status:1,created_at:-1});// 优化后constafterdb.collection.explain(executionStats).find({status:active});// 关键指标对比print(Execution time:${before.executionTimeMillis}ms →${after.executionTimeMillis}ms);print(Keys examined:${before.totalKeysExamined}→${after.totalKeysExamined});6.2 持续监控// 设置监控脚本每小时运行db.setProfilingLevel(1,{slowms:50});// 记录50ms查询// 分析profile数据db.system.profile.find({command.explain:{$exists:true}});告警阈值executionTimeMillis 500mstotalKeysExamined / nReturned 10memUsage 50MB七、避坑指南5大致命错误错误1仅看executionTimeMillis后果忽略资源消耗掩盖潜在问题解决方案结合keysExamined和docsExamined综合判断错误2优化后未验证执行计划后果索引未被使用性能无提升解决方案每次优化后必须重新运行explain()错误3盲目添加索引后果索引膨胀写入性能下降解决方案用calculateSelectivity()评估索引价值错误4分片集群忽略SHARD_MERGE后果误判单分片性能忽略全局瓶颈解决方案始终检查totalChildMillis错误5未处理索引碎片后果索引选择性下降性能逐步恶化解决方案定期重建索引db.collection.reIndex();八、终极诊断流程从问题到解决8.1 问题确认通过system.profile定位慢查询提取查询语句和参数8.2 执行计划获取db.collection.explain(executionStats).find(query).maxTimeMS(500);8.3 瓶颈分析检查stage类型是否存在COLLSCAN计算比值keysExamined / nReturned验证索引indexBounds是否合理8.4 优化实施创建/调整索引重写查询语句调整分片策略分片集群8.5 效果验证对比优化前后的executionStats监控生产环境指标7天九、总结执行计划分析的黄金法则“nReturned必须接近keysExamined排序必须由索引完成”核心原则索引效率keysExamined / nReturned ≤ 5无内存排序确保SORT stage by index出现无全表扫描杜绝COLLSCAN持续监控定期检查执行计划变化性能目标指标健康值问题值executionTimeMillis 100ms 500mskeysExamined / nReturned≤ 5 10docsExamined / nReturned≤ 2 5内存排序比例 5% 20%立即行动运行db.currentOp({ secs_running: { $gt: 1 } })查找慢查询对每个慢查询执行explain(executionStats)按本文方法优化90%的查询可在1小时内提升性能50%通过系统化的执行计划分析您将从猜索引进入精准优化时代。记住最好的索引是能完全覆盖查询的索引而executionStats是验证这一点的唯一标准。