MongoDB在执行复杂查询时，优化器会在多个可用索引之间做代价估算。故障码2490通常出现在查询计划生成阶段，表示系统原本可以尝试使用索引交集来服务查询，但因为统计信息或版本限制，最终没有采用预期的高效路径，甚至退化为集合扫描。要理清这个问题，必须先明白索引交集和复合索引在底层逻辑上的根本区别，以及优化器在什么情况下会放弃前者。
索引交集的底层机制与2490触发原因
索引交集是指MongoDB在查询包含多个独立过滤条件时，分别使用两个不同的单列索引查出对应的记录标识，然后在内存中做交集运算，从而缩小需要回表的文档范围。这种机制在理论上能让用户不必为每种组合都建复合索引，看似灵活。但在实际执行中，如果两个索引的选择性都不高，交集后的中间结果依然很大，MongoDB就需要消耗大量内存和CPU去做合并，此时优化器可能直接判定交集代价超过全表扫描，于是抛出类似2490的提示并选择其他计划。
从源码层面的代价模型来看，索引交集的预估开销等于两次索引扫描的IO成本加上交集运算的CPU成本。当集合文档数量在千万级，而两个字段的区分度都只有百分之十左右时，中间结果集可能达到百万级，这时候交集操作会触发内存排序和哈希表构建。某些MongoDB版本对交集的内存使用设有隐式阈值，一旦超过便不会生成交集计划，而是回退到单索引或全表扫描，错误日志中便可能标记2490。
另一个容易被忽视的原因是查询中包含了范围条件和等值条件的混合。例如一个字段是等值查询，另一个字段是范围查询，索引交集要求两个索引都能有效利用，但范围索引返回的乱序记录会让交集阶段无法使用简单的有序归并，只能借助内存哈希，进一步推高代价。很多线上事故都是在这种混合查询下，原本正常的计划突然因为数据分布偏移而触发2490。
复合索引的设计原则与覆盖能力
复合索引将多个字段按顺序组织在同一棵B树中，查询时从最左前缀开始匹配。如果查询条件恰好命中前缀，那么一次索引遍历就能定位到所有候选文档，不需要做内存交集。对比索引交集，复合索引把合并工作前置到了索引结构内部，通过有序存储直接避免后期计算。因此对于稳定出现的多字段查询，复合索引往往是根治2490的首选方案。
设计复合索引时要遵循等值字段在前、范围字段在后的规则。假设业务常按status等值过滤再按created_at范围排序，那么索引应为{status: 1, created_at: 1}。如果把范围字段放前面，等值字段就无法利用前缀优势，索引效率骤降。同时可以利用复合索引的覆盖查询特性，把需要返回的字段也加入索引尾部，这样MongoDB无需回表读取文档正文，进一步降低IO。
需要注意的是，复合索引并不是越多越好。每个额外索引都会增加写入时的维护成本和磁盘占用。当查询组合较多时，应当抽取出最高频的前缀模式建两到三个复合索引，而不是为所有排列都建索引。通过explain("executionStats")观察totalKeysExamined与totalDocsExamined的比值，可以验证复合索引是否真正减少了被检查文档数，从而避开2490所代表的低效执行。
利用hint与索引重建规避2490的实践
当优化器因为统计信息滞后而错误放弃交集或复合索引时，可以临时使用hint强制指定索引，让查询走预期计划。虽然hint不应作为长期方案，但在紧急止血时非常有效。例如明确知道{a:1,b:1}复合索引最优，可以在驱动中附加.hint({a:1,b:1})，绕过优化器的错误选择，消除2490相关的慢查询。
// 使用hint强制走复合索引，避免优化器误判导致2490
db.orders.find({
status: "paid",
created_at: { $gte: ISODate("2023-01-01") }
}).hint({ status: 1, created_at: 1 }).explain("executionStats");
从根因治理角度，应当定期重建或重新生成索引统计。在MongoDB中，虽然不像关系型数据库那样有显式的analyze table，但可以通过删除再创建索引、或升级到对直方图统计支持更好的版本，来刷新优化器的认知。对于频繁触发2490的集合，建议直接下线低效的单列索引，改为针对性的复合索引，并从应用层去掉对索引交集的隐式依赖。
最后要建立监控闭环。通过数据库分析器捕获planCache中频繁出现的退化解计划，结合慢查询日志中的错误码，定位到具体集合和字段组合。把这些组合固化进复合索引规范，写入项目的数据库变更评审清单，就能在开发阶段拦住大部分2490隐患，而不是等线上告警才被动处理。
执行计划解读与验证手段
要确认是否为2490相关的索引选择问题，最直观的方式是查看explain输出中的winningPlan。如果看到stage为COLLSCAN且伴随备注信息提及索引交集失败，基本可以锁定原因。而如果winningPlan里是IXSCAN且indexName指向复合索引，说明计划正常。
{
"winningPlan": {
"stage": "FETCH",
"inputStage": {
"stage": "IXSCAN",
"indexName": "status_1_created_at_1",
"direction": "forward"
}
},
"executionStats": {
"totalKeysExamined": 1200,
"totalDocsExamined": 1200,
"nReturned": 1200
}
}
通过对比totalKeysExamined和nReturned的接近程度，能判断索引是否完全覆盖过滤条件。若两者差距巨大，说明索引选择性差或查询未走前缀，此时即便没有2490报错，也埋下了性能地雷。把explain结果纳入CI流程，在每次索引变更后自动比对计划差异，是防止问题回流的好办法。
综合来看，MongoDB故障码2490暴露的是优化器在索引交集与复合索引之间的权衡失误。理解代价模型、合理设计复合索引、辅以hint和监控，才能从根本上解决这类索引选择异常，保障查询延迟稳定。