MongoDB索引选择异常咨询：为何选错索引及键排序影响

一、MongoDB选错索引的原因及解决办法 #

MongoDB的查询优化器并不是永远能做出最优选择，它依赖实时的集合统计数据和执行计划缓存来决策，你遇到的选错索引情况，大概率是以下两个原因导致的：

• 统计信息过时：3500万条数据的集合，如果经历过批量写入、删除或者大量更新，MongoDB自动维护的统计信息（比如索引键的基数、文档分布）可能没有及时同步。优化器基于旧的统计数据，错误判断了rectype_1_data.time_-1索引的查询成本更低，而忽略了完全匹配查询条件的recType_1_tstamp_-1索引。
• 执行计划缓存“固化”：如果第一次执行这个查询时，优化器就选了错误的索引，后续查询会直接复用缓存的执行计划，不会重新评估所有可用索引——相当于“一条路走到黑”。

解决方法很直接：

• 强制刷新统计信息：执行db.objs.stats({refresh: true})，让MongoDB重新收集集合的统计数据，给优化器提供准确的评估依据。
• 清除执行计划缓存：运行db.runCommand({planCacheClear: "objs"})清空该集合的执行计划缓存，这样下次查询时，优化器会重新对比所有符合条件的索引。
• 重建索引（可选，谨慎操作）：如果前两种方法都无效，可以尝试db.objs.reIndex()重建所有索引，但这个操作对大集合来说耗时很长，务必在业务低峰期执行。

二、索引第二个键的排序是否会影响索引选择？ #

答案是会，在特定场景下确实会影响，你的案例正好印证了这一点，核心原因有两个：

1. 优化器的成本评估逻辑
   虽然MongoDB支持反向遍历索引（比如用降序tstamp索引处理$gte条件），但优化器在计算查询成本时，会把“索引扫描方向”纳入考量。你的查询是tstamp: {$gte: ...}，升序索引的扫描方向和查询条件的匹配度更高（直接从符合条件的起始位置往后扫），而降序索引需要反向遍历，优化器可能会判断这个操作的“隐性成本”略高——哪怕实际性能差异不大，统计数据的微小偏差都可能让它倾向于选择升序索引。

2. 新索引的统计信息更准确
   你新创建的recType_1_tstamp_1索引是刚建立的，它的统计数据是最新、最精准的；而旧的recType_1_tstamp_-1索引的统计信息可能已经过时，优化器基于新的统计数据，自然会认为新索引的查询成本更低，从而自动选中它。

另外，当存在多个前缀相同的复合索引时，优化器会综合索引的键基数、文档分布、排序方向等多个维度做评估，排序方向虽然不是决定性因素，但会成为影响最终选择的一个变量。

内容的提问来源于stack exchange，提问作者Erix