MongoDB的正则查询用起来非常顺手，db.users.find({name: /^张/})一句话就能实现模糊搜索。但不少团队在生产环境吃过亏：一条看起来无害的正则查询，让整个副本集的CPU飙到100%，慢查询日志里堆积了大量超时记录。正则查询本身没有问题，问题在于正则表达式的写法直接决定了MongoDB能否走索引。理解这背后的机制，是避开性能陷阱的第一步。
正则查询为什么可能不走索引：从B-tree原理说起
MongoDB的普通索引基于B-tree结构，本质上是一个有序的键值集合。数据库利用索引的前提，是查询条件能够定位到一个连续的键区间。比如{name: {$gte: "a", $lt: "b"}}可以定位到以a开头的区间，引擎只需要遍历这个区间内的条目，速度非常快。
正则查询是否能走索引，取决于正则表达式能否被转换为一个确定的区间。判断规则其实很简单：当正则表达式以确定的字符串前缀开头且区分大小写时，MongoDB可以将它转换为区间查询，从而使用索引。例如/^abc/等价于区间["abc", "abd")，引擎可以从"abc"这个位置开始扫描，效率极高。
反过来，如果正则以通配符或可选字符开头，比如/^.*abc/、/a.c/、/(a|b)c/，索引就完全无法定位起点，MongoDB只能执行全集合扫描（COLLSCAN），把每一条文档取出来逐一做正则匹配。数据量达到千万级时，一次这样的查询可能要扫描几十秒，还会把工作集挤出内存，连带影响其他正常查询。
有一个细节特别容易被忽视：大小写修饰符。写成/^abc/i时，即使有前缀，MongoDB也无法确定到底是"abc"还是"ABC"还是"Abc"，区间推导失败，索引照样用不上。这是生产环境中最常见的隐形陷阱之一。
用explain看清执行计划：三个关键指标
排查正则查询性能问题，第一步永远是看执行计划。在mongosh里执行db.collection.find({name: /abc/}).explain("executionStats")，重点关注以下几个字段。
第一个是stage字段。如果看到COLLSCAN，说明发生了全集合扫描；如果看到IXSCAN，恭喜你，索引生效了。第二个是totalKeysExamined和totalDocsExamined，分别代表扫描的索引条目数和文档数。第三个是executionTimeMillis，即实际执行耗时。
// 查看正则查询的执行计划
db.users.find({name: /张三/}).explain("executionStats")
// 健康的输出大致长这样：
// winningPlan.stage: "FETCH"
// inputStage.stage: "IXSCAN"
// indexName: "name_1"
// 不健康的输出：
// winningPlan.stage: "COLLSCAN" -- 全表扫描，需要优化
// totalDocsExamined: 10000000 -- 扫描了一千万条文档
// nReturned: 12 -- 只返回12条一个实用的判断标准是对比totalDocsExamined和nReturned。如果扫描了一千万条文档却只返回12条，扫描比接近百万比一，这个查询的写法一定有问题。理想的比值应该接近1:1，即扫描多少就返回多少。
常见性能陷阱与对应的优化方案
陷阱一：模糊匹配直接上正则
需求是"用户输入关键字搜索名称"，很多开发者直接写/关键字/，两个字的开销就是一次全表扫描。如果业务允许，把查询改成前缀匹配/^关键字/并确保区分大小写，索引立刻就能用上。实测中，前缀锚定的正则在千万级集合上通常毫秒级返回，而未锚定的版本可能需要数十秒。
陷阱二：大小写不敏感的前缀搜索
想实现"忽略大小写的前缀搜索"又想走索引，标准做法是冗余一个规范化的字段。写入时额外保存一个小写字段，查询时把输入也转成小写，对这个字段做区分大小写的前缀正则查询。
// 写入时冗余小写字段
db.users.insertOne({
name: "ZhangSan",
name_lower: "zhangsan" // 应用层写入时统一转小写
})
// 在name_lower上建索引
db.users.createIndex({name_lower: 1})
// 查询：忽略大小写的前缀搜索，索引生效
db.users.find({name_lower: /^zhang/})陷阱三：把正则当成全文检索用
如果需求本质上是多关键词、任意位置的全文搜索，正则从一开始就不是合适的工具。MongoDB内置的Text Index支持分词和相关性排序，配合$text操作符，性能和体验都远好于拼接多个正则条件。数据规模更大或需要中文分词时，考虑接入Elasticsearch或OpenSearch这类专门的搜索引擎，MongoDB只存业务数据。
// 创建文本索引
db.articles.createIndex({title: "text", content: "text"})
// 全文检索，支持多词OR匹配
db.articles.find({$text: {$search: "mongodb 性能"}})陷阱四：正则与其他条件组合时排序失效
当正则查询无法走索引，而查询又带有sort时，MongoDB不仅要全表扫描，还要对结果做内存排序，数据量超过100MB会直接报错。优化思路是调整查询结构：先用能走索引的范围条件过滤出小结果集，再在小结果集上应用正则。或者干脆利用复合索引同时满足过滤和排序需求，让sort阶段消失。
总结：写正则查询前的自查清单
归根结底，MongoDB正则查询的性能取决于一个核心问题：这条正则能否被转换为索引区间。每次写正则查询前，建议按这个清单过一遍：第一，正则是否以确定的前缀开头；第二，是否避免了i修饰符，或已用冗余小写字段绕开；第三，是否用explain确认了IXSCAN而非COLLSCAN；第四，扫描比是否在合理范围内；第五，搜索需求是否已经超出正则的能力边界，需要文本索引或搜索引擎接手。
养成上线前跑一遍执行计划的习惯，成本只有几秒钟，却能避免一次足以让整库抖动的慢查询。正则不是不能用，而是要用在它能走索引的场景里。
MongoDB正则查询索引优化性能调优修改时间：2026-09-04 15:04:49