MongoDB在执行查询时，优化器会从众多索引中挑选代价最低的一个来完成任务。当出现故障码2260（部分索引未命中）时，意味着数据库在规划阶段发现某些满足部分条件的索引没有被成功选中或使用，查询被迫回退到全集合扫描或次优执行计划，性能随之急剧下降。这个故障码通常出现在使用部分索引、复合索引以及多条件查询混合的场景中，理解它的成因并掌握排查方法，对维护大规模MongoDB集群非常重要。
一、故障码2260的底层成因分析
部分索引是MongoDB提供的一项特性，通过partialFilterExpression只对集合中满足特定条件的文档建立索引，从而节省存储空间和写入开销。例如只对status字段等于active的文档建立索引。这种索引虽然轻量，但有一个硬性约束：只有当查询条件能够保证结果一定落在索引覆盖范围内时，优化器才允许使用它。
故障码2260触发的核心逻辑在于：优化器在索引候选阶段标记了某个部分索引为“潜在可用”，但在计划评估阶段发现查询条件与索引过滤条件无法完全匹配，最终放弃了该索引。常见诱因包括以下几类：查询条件中缺少部分索引的过滤字段、查询使用了$nin或$ne这类无法收敛范围的操作符、排序字段不在索引键中导致需要额外的内存排序、以及集合统计信息过期使优化器误判代价。
除了上述原因，还有一种容易被忽视的情况：如果查询是通过$expr或者聚合管道的$match阶段表达条件，早期版本中优化器对这类条件的重写能力有限，即使条件在语义上等价于索引过滤条件，也可能无法识别，从而判定索引未命中。因此遇到2260时，第一步要确认MongoDB版本，4.2之后的版本在计划缓存和表达式重写上有较大改进。
二、利用执行计划精准定位未命中的索引
排查的第一步永远是获取真实的执行计划。使用explain命令并指定executionStats模式，可以看到优化器评估过的所有候选计划以及最终胜出的计划：
db.orders.find({
status: "active",
amount: { $gt: 100 }
}).sort({ createdAt: -1 }).explain("executionStats");
在输出的executionStats字段中，重点关注三个指标：totalKeysExamined表示扫描的索引键数量，totalDocsExamined表示回表读取的文档数量，nReturned表示实际返回的文档数。如果totalDocsExamined远大于nReturned，且winningPlan中出现COLLSCAN或者不带IXSCAN的FETCH阶段，基本可以确认索引没有被有效命中。
接下来查看allPlansExecution数组，这里记录了所有候选计划的执行统计。对比被放弃的部分索引计划和胜出计划的关键指标，如果被放弃的计划在测试执行中扫描键数更少，却因为某些拒绝原因（rejection原因会记录在计划缓存日志中）没有被选中，就能定位到具体的判定逻辑问题。同时可以用db.collection.getIndexes()输出当前索引定义，逐字段核对partialFilterExpression与查询条件的匹配关系。
另一个实用技巧是清空计划缓存后重试。计划缓存中的旧计划可能在数据分布变化后失效，执行db.orders.getPlanCache().clear()再观察是否命中索引，可以排除缓存污染带来的干扰。
三、修复方案与最佳实践
修复部分索引未命中，最直接的方法是改写查询条件，让它显式包含索引的过滤条件。例如索引定义为只覆盖status为active的文档，查询中就应当显式加上status: "active"，而不是依赖业务层保证。改写后重新执行explain验证，IXSCAN阶段出现在winningPlan中即说明索引已生效。
如果查询条件多变且无法保证总是携带过滤字段，可以考虑用普通复合索引替代部分索引，牺牲存储换取稳定的命中率的提升。对于排序导致的未命中，建议把排序字段追加到索引键的末尾，使索引本身的顺序与排序方向一致，避免出现内存排序。需要注意索引的方向要与查询排序方向匹配，否则依然会触发SORT阶段：
// 重建复合索引，包含过滤字段、范围字段和排序字段
db.orders.createIndex(
{ status: 1, amount: 1, createdAt: -1 },
{
name: "idx_active_amount_time",
partialFilterExpression: {
status: { $eq: "active" }
},
background: true
}
);
// 查询显式携带过滤条件，确保可以命中部分索引
db.orders.find({
status: "active",
amount: { $gt: 100 }
}).sort({ createdAt: -1 });
建立监控与预防机制同样重要。可以在应用层封装一个开发环境自动断言，对关键查询执行explain并检查返回计划中是否包含IXSCAN，一旦出现全表扫描立即报警。运维侧则建议定期检查$indexStats聚合输出，识别长期未使用的索引并及时清理，因为冗余索引不仅拖慢写入，还会增加优化器评估候选计划的成本，间接提高2260这类故障的发生概率。对于关键业务表，还应保持统计信息的新鲜度，必要时对集合执行analyze或通过采样更新统计，让代价估算更贴近真实数据分布。
总结来看，故障码2260本质上是查询语义与索引定义之间的契约被打破。掌握从执行计划出发、逐层核对过滤条件与索引键的排查方法，配合合理的索引设计和查询规范，就能让部分索引真正发挥降低存储成本与加速查询的双重价值，避免性能问题在生产环境中反复出现。
MongoDB故障码2260索引未命中索引优化修改时间：2026-09-01 12:42:58