MongoDB文本检索未前置利用FName过滤条件缩减检索范围引发性能异常

• MongoDB 查询优化器在处理包含 $text 条件的多条件查询时，默认会优先将文本倒排索引作为主导执行路径，不会自动优先选择FName字段的B树索引做前置范围过滤。这种选择在MongoDB 4.4及之前的版本中尤为明显，新版本虽然做了优化，但只要文本索引的估算成本低于B树范围查询的成本，还是会优先选择文本索引作为主路径，属于机制性的设计特性，不是数据库bug。
• 产生这个选择偏差的本质是优化器的成本估算逻辑存在局限性：优化器会预先统计文本索引的匹配命中率，当文本搜索的结果集规模较大时，会误判走文本索引的整体成本低于先做FName前缀过滤的成本，因此不会生成“先走FName索引缩小扫描范围、再匹配文本条件”的可选执行计划。实际执行时会先遍历整个文本索引，匹配所有含"average rainfall"的文档（通常是几千甚至几万条），再逐文档回表校验FName的正则条件，自然会产生十几秒的耗时。
• 单条FName前缀正则查询之所以快，是因为没有$text条件干扰时，优化器可以正常选择FName字段的B树索引——毕竟以^开头的前缀正则是完全可以利用B树索引做精准范围扫描的，仅需定位300条目标文档，毫秒级返回完全符合索引的执行特性。
• 客户端先拉取300条文档再做文本筛选的流程更快，本质是绕开了优化器的误判，直接通过FName索引把扫描范围压缩到最小，哪怕加上300条文档的网络传输和本地匹配耗时，也远低于数据库端扫描几万条文本匹配文档再逐一过滤的成本。

• 直接在原慢查询上附加explain("executionStats")执行，重点查看两个指标：
  • 观察winningPlan的主导索引：如果执行计划的最外层节点是$text索引扫描，FName的正则匹配仅作为FETCH阶段的后置过滤条件，即可验证优化器没有优先应用FName的过滤能力。
  • 查看totalDocsExamined数值：如果扫描文档量远大于最终返回结果量（比如扫描了几万条仅返回几十条），就能量化看到这种执行计划的成本浪费程度。
• 可直接通过索引提示做对照验证：在查询中附加hint({FName:1})强制走FName字段的索引，如果查询耗时降到毫秒/百毫秒级，就完全坐实了优化器选错执行计划的判断。

• 方案1：用索引提示规避优化器误判
  对于这类明确知道FName前缀能将结果压缩到极小范围的查询，直接在查询语句中加入hint({FName:1})指定走FName的B树索引，让执行流程变为：先通过FName索引定位全部300条匹配文档，再在该结果集范围内匹配文本检索条件。这种方式的服务端执行效率会比客户端筛选更高，因为省去了300条文档的跨网络传输开销。
• 方案2：创建适配场景的复合索引
  如果这类“FName前缀过滤+文本检索”的查询是高频业务场景，可以创建以前导字段为FName的复合文本索引，结构参考{FName:1, "$**": "text"}。这种索引结构下，优化器会优先利用FName的B树索引锁定文档范围，再在锁定范围内执行文本匹配，从索引设计层面从根本上解决执行计划错选的问题。
• 注意认知误区：MongoDB的查询条件书写顺序本身不会影响执行计划，哪怕把FName条件写在查询语句的最前面，优化器也不会自动优先执行该条件，所有执行路径的选择都是基于索引结构和成本估算逻辑决定的。

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