当MongoDB日志中出现故障码2370时，很多DBA的第一反应是疑惑：索引明明建好了，查询也在走索引，为什么统计信息会不准确？实际上，MongoDB的查询优化器依赖索引统计信息（如基数估算、区间分布等）来判断某个索引的选择性，一旦这些统计与实际数据脱节，优化器就可能选错索引或放弃索引扫描，性能问题随之而来。理解这个故障码的产生机制并掌握修复手段，是MongoDB运维中非常实用的一项技能。
一、索引统计信息的作用与2370错误的本质
MongoDB从3.2版本开始引入了基于代价的查询优化器（Cost-Based Optimizer雏形），此后索引统计信息的重要性不断提升。优化器在多索引候选场景下，会参考索引键值的分布情况估算需要扫描的文档数量，从而选择代价最低的执行计划。这些统计信息包括索引的基数、不同值的数量、区间内的文档密度估算等。
故障码2370的本质是：数据库检测到索引上缓存的统计信息与实际遍历结果存在显著偏差。这种偏差可能由多种原因引起，例如统计信息在大量写入后未及时刷新、非正常关闭数据库导致元数据未持久化、复制集成员间元数据同步异常，或者集合经历了大批量的删除与重新写入操作。
需要强调的是，2370通常不会直接阻断业务读写，它更像一个性能隐患的信号。如果忽视它，慢查询比例会逐渐上升，某些原本毫秒级的查询可能退化为全集合扫描。
二、常见触发场景与排查步骤
第一种常见场景是统计信息过期。当某个集合在短时间内经历海量写入（例如日志类业务每天写入千万级文档），而统计信息的采样更新滞后，就可能触发2370告警。第二种场景是元数据不一致，典型诱因包括非正常的kill -9终止进程、磁盘空间满导致的写入中断等。第三种场景出现在复制集环境中，从节点通过oplog回放数据，如果回放过程中出现异常，从节点的索引统计可能与主节点不一致。
排查时建议按以下步骤进行：
// 1. 查看集合的索引统计详情
db.collection.getIndexes()
// 2. 查看具体索引的统计信息
db.collection.stats({ indexDetails: true })
// 3. 检查索引键值分布
db.collection.aggregate([
{ $sample: { size: 1000 } },
{ $group: { _id: "$status", count: { $sum: 1 } } }
])
// 4. 查看服务端日志中的相关错误
db.adminCommand({ getLog: "global" })如果stats()输出中的索引基数与实际去重数量差距超过一个数量级，基本可以确认统计信息已经失真。此时还需要检查复制集各成员的rs.status()输出，确认同步状态是否正常，排除从节点数据漂移的可能。
三、修复方案与操作实践
针对不同的成因，修复手段也有所区别。最温和的方式是刷新统计信息，MongoDB提供了collMod命令来触发集合级别的元数据刷新：
// 刷新集合元数据与统计信息
db.runCommand({
collMod: "orders",
index: {
keyPattern: { userId: 1, createdAt: -1 }
}
})如果刷新无效，说明统计信息缓存已经损坏，此时可以考虑对索引执行reIndex操作。该操作会删除并重建索引，同时重新计算所有统计信息。但要注意，reIndex在旧版本中会持有排他锁，建议在业务低峰期执行，或在从节点优先操作后再切换：
// 重建单个索引（4.4及以上版本推荐的方式）
db.orders.dropIndex({ userId: 1, createdAt: -1 })
db.orders.createIndex(
{ userId: 1, createdAt: -1 },
{ background: true }
)对于版本较新的MongoDB（4.4以上），更推荐采用删除后重建的方式替代reIndex，因为新的索引构建机制不再阻塞读写操作，风险更低。重建完成后，务必使用explain验证查询计划是否恢复正常：
// 验证执行计划
db.orders.find({ userId: "u10086" })
.sort({ createdAt: -1 })
.limit(20)
.explain("executionStats")在explain输出中，重点观察totalKeysExamined与totalDocsExamined的比值。理想状态下二者接近1:1，如果totalDocsExamined远大于返回的nReturned，说明优化器仍然没有选中合适的索引，需要进一步排查。
四、预防措施与监控建议
故障码2370的出现往往不是孤立的，它反映了日常运维中的一些薄弱环节。首先是写入模式管理，对于大批量更新或删除操作，建议分批执行，避免统计信息在短时间内剧烈震荡。其次是保证数据库的正常关闭流程，使用db.shutdownServer()而非直接杀进程，确保元数据完整落盘。
在监控层面，建议将以下指标纳入日常巡检：索引扫描比例、查询平均耗时、集合基数增长趋势。可以编写定时脚本对比estimatedDocumentCount与countDocuments的结果，一旦偏差超过阈值就发出告警，提前发现统计信息失真的苗头。
最后，保持MongoDB版本更新也是重要的预防手段。新版本对统计信息的采样算法和刷新机制持续优化，触发2370的概率明显降低。对于核心业务集群，建议搭配Percona PMM或MongoDB Ops Manager建立完整的性能基线，这样即使出现统计信息异常，也能快速定位到偏差发生的时间点，大幅缩短故障处理时间。