MongoDB选择非最优索引源于其查询计划竞争机制和缓存行为，而非静态规则；explain显示低效索引常因历史胜出计划被复用、$in/$elemMatch导致候选索引误判或基数变化未触发重优化。
MongoDB 选择非最优索引，不是“选错了”，而是它在特定时刻、基于当前统计和历史执行表现，认为那个索引“看起来更快”——但实际未必。根本原因在于它的查询计划竞争机制（Query Plan Competition）和缓存行为，而非静态规则匹配。
为什么 explain("executionStats") 显示用了低效索引？
这通常发生在以下几种真实场景中：
- 该索引是上一次“试用期竞赛”的胜出者，被缓存进
queryPlanner.winningPlan，后续同形状查询直接复用，哪怕数据分布已变（比如某字段基数突然升高或降低） - 多个候选索引的
stage都是IXSCAN，但 MongoDB 在试用期内只比了前几条结果的返回速度，没跑完全部扫描——尤其当$in值较多、$elemMatch涉及数组时，不同索引的“预热成本”差异大，容易误判 -
resourceId: "xxx"是等值条件，但写成resourceId: { $in: ["xxx"] }后，查询形状变了，触发了另一组候选索引，而原有最优复合索引（如{ resourceId: 1, creator: 1, publicStatus: 1 }）可能因字段顺序或缺失publicObject.classId而未被纳入候选
$in 字段过多会干扰索引选择
当 publicObject.classId 的 $in 列表含 8 个值（如 [1540,10726,...]），MongoDB 会尝试对每个值做独立索引查找再合并，此时：
- 若索引里
publicObject.classId不在最右端（比如放在中间或开头），B-tree 无法高效跳转，退化为范围扫描甚至全索引扫描 - 若该字段基数低（比如只有几十个 classId 被反复使用），索引区分度差，优化器可能判定“不如全表扫”
- 更隐蔽的问题：
$elemMatch+$in组合会让 MongoDB 优先考虑多键索引（multikey），而你的复合索引若未显式声明publicObject.classId为多键字段，即使底层是数组，也可能被排除在候选之外
如何验证并强制切换到更优索引？
不能靠删索引硬逼，而要让优化器“重新比赛”并看清真实代价：
- 用
db.public_setting_detail.find(...).explain("allPlansExecution")查看所有候选计划的executionStats.nReturned和executionTimeMillis，对比各IXSCAN的keysExamined与docsExamined比值——比值越接近 1 越好 - 执行
db.public_setting_detail.dropIndex("your_composite_index_name")再重建，可清空该索引相关的计划缓存；或者直接运行db.runCommand({ clearQueryCache: "public_setting_detail" })（4.2+） - 如果确认
{ resourceId: 1, creator: 1, publicStatus: 1, isdir: 1, status: 1, "publicObject.classId": 1 }是理想顺序，建索引时加{ background: true }避免阻塞，并确保publicObject是数组字段（否则 multikey 标识不会自动生效）
真正难处理的不是“怎么建索引”，而是“怎么让 MongoDB 相信这个索引更好”。它依赖试用期表现，而试用期又受数据倾斜、内存压力、并发查询干扰——这些都不会出现在 explain 输出里，却决定最终选谁。
