生产与测试环境中MongoDB复合索引执行行为不一致问题排查

1. 核对索引的Collation配置一致性 #

直接在两个集群执行 db.users.getIndexes()，重点对比search_index的collation字段：

• 确认生产环境的索引是否确实包含{locale: 'en', strength: 2}配置，避免出现索引创建时未正确应用collation（比如早期创建索引时没指定，后续修改Schema但未重建索引的情况）。

2. 验证查询的Collation参数是否真实生效 #

生产环境中用db.currentOp()抓取该查询的实际执行请求，检查collation参数是否与测试环境完全一致：

• 排查应用层是否存在代码分支，导致生产环境的查询未正确携带collation参数（比如配置文件差异、代码逻辑遗漏）。

3. 对比数据分布差异对执行计划的影响 #

分别在两个环境执行以下统计：

// 统计符合查询条件的文档数量
db.users.countDocuments({deactivated: null, role: 'user'})

MongoDB查询优化器会根据数据分布选择执行计划：

• 如果生产环境中符合条件的文档占比远高于测试环境，优化器可能认为直接扫描筛选后的数据再内存排序，比走完整索引更高效（虽然limit=10，但优化器的成本计算可能存在差异）。

4. 确认MongoDB版本一致性 #

检查两个集群的MongoDB版本（执行db.version()）：

• 不同版本的查询优化器对带collation的复合索引选择逻辑可能存在差异，部分旧版本可能对collation索引的支持不完善。

5. 检查索引完整性并尝试重建 #

生产环境中执行索引验证：

db.users.validate({full: true})

若发现索引异常，在低峰期重建索引：

db.users.reIndex()

重建后再次执行查询并查看执行计划，排除索引损坏导致的问题。

6. 对比执行计划的详细输出 #

在两个环境分别执行explain("executionStats")：

db.getCollection('users')
  .find({deactivated: null, role: 'user'})
  .sort({score: -1})
  .limit(10)
  .collation({locale: 'en', strength: 2})
  .explain("executionStats")

重点关注：

• executionStats.executionStages：测试环境应显示完整的IXSCAN（包含deactivated、role、score三个字段），生产环境若仅扫描deactivated后加SORT阶段，说明优化器未选择完整索引。
• totalDocsExamined、executionTimeMillis等指标，分析优化器选择不同执行计划的成本依据。

7. 验证role字段的实际数据一致性 #

执行db.users.distinct('role')对比两个环境的role取值：

• 虽然Schema定义了enum，但需排查生产环境是否存在不符合enum的取值（比如大小写变体），即使collation strength=2忽略大小写，也可能影响索引的匹配效率。

内容的提问来源于stack exchange，提问作者Jurgen Jafet Padilla Romero