线上MongoDB查询慢，如何通过索引优化直降响应时间？( 二 ) _MongoDB

这部分显示的是查询的执行统计信息。
索引分析通过explain的执行计划，可以看出索引的使用上存在问题。按理说company_id、create_time都已创建索引，为什么没有使用上？是什么原因导致它失效，没有用上create_time索引？
下面列举了失效的情况：

索引选择性不高：由于查询条件是一个范围查询，create_time 字段可能有许多不同的值满足条件。因此，单键索引 create_time_1 的选择性（即索引中不同值的比例）可能不高，这使得使用该索引无法有效地减少需要检索的文档数量。
查询需要跨越多个索引键值：查询涉及到了两个字段 company_id 和 create_time 。虽然索引 create_time_1 可以帮助过滤 create_time 符合条件的文档，但在执行查询时，还需要考虑 company_id 的匹配条件。因此，MongoDB 需要在两个索引之间进行查找和合并，而不是简单地使用单个索引来解决查询。
额外的查找和合并成本：在涉及多个条件的查询中， MongoDB 会尝试使用覆盖索引（Covered Index）来尽可能地减少在磁盘上的文档检索。然而，在这种情况下，create_time_1 索引不能单独满足查询条件，因此 MongoDB 还需要查找和合并从 company_id_1 索引中过滤出来的文档。这种额外的查找和合并过程会增加查询的成本，并且降低性能。
因此，针对给定的查询语句，MongoDB 不会使用 create_time_1 索引来优化查询，而是会选择其他更适合的索引，如 company_id_hashed 和 company_id_1 。

问题原因造成执行耗时过长的主要原因是索引失效的问题，在涉及多个条件的查询中，MongoDB 会尝试使用覆盖索引（Covered Index）来尽可能地减少在磁盘上的文档检索。然而，在这种情况下，create_time_1 索引不能单独满足查询条件，因此 MongoDB 还需要查找和合并从 company_id_1 索引中过滤出来的文档。这种额外的查找和合并过程会增加查询的成本，并且降低性能。
优化方案创建新的复合索引company_id_create_time，让其走company_id_hashed到company_id_create_time的链路。添加新的索引后，相同的语句执行时间只需要400ms，能满足业务的需求。

文章插图
结论要多关注索引在什么情况下会失效？复合索引的先后顺序，不是每个条件字段都建个单个普通索引，查询语句都会使用上，不要存在这种误区，有时候复合索引才是最完美的组合。
执行计划详解1、queryPlanner：包含了MongoDB查询的执行计划。

mongosPlannerVersion：MongoDB计划版本。
winningPlan：胜出的执行计划，即MongoDB选择的最佳执行计划。
shards: 分片的详细信息，包括分片名称、连接字符串、服务器信息等。2、winningPlan: 胜出的执行计划。
stage: 执行阶段，这里是SINGLE_SHARD ，表示单分片操作。
shardName: 执行操作的分片名称。
plannerVersion: 计划版本。
namespace: 查询的命名空间。
indexFilterSet: 是否设置了索引过滤器。
parsedQuery: 解析后的查询条件。
winningPlan: 胜出的执行计划的详细信息，这里是SHARDING_FILTER 。3、rejectedPlans: 被拒绝的执行计划列表，即非胜出的备选计划。
每个被拒绝的执行计划包含了其详细信息，包括执行阶段、过滤器、索引扫描等。
4、executionStats: 查询的执行统计信息。
nReturned: 返回的文档数量。
executionTimeMillis: 查询执行时间（毫秒）。
totalKeysExamined: 总共检查的键数量。
totalDocsExamined: 总共检查的文档数量。
executionStages: 执行阶段的详细统计信息。