正则表达式仅以^开头的固定前缀匹配才可能走b-tree索引，如^alice；而alice、ice$、^ali.*e等均不走索引，因b-tree需推导确定字符串区间，通配符导致无法界定范围。
正则表达式只有^前缀匹配才可能走索引
绝大多数 $regex 查询根本不会用到普通 B-tree 索引，除非它严格满足「固定前缀」条件：以 ^ 开头、后面紧跟确定字符、中间没有 .* 或 .+ 等通配符。比如 ^Alice 可能走索引；Alice、ice$、^Ali.*e 全部不走。
原因在于 B-tree 索引只能做前缀范围扫描——MongoDB 需要能从正则推导出一个左闭右开的字符串区间（如 ["Alice", "Aliec")），一旦出现非确定性部分（如 .*），就无法划定边界，只能退化为 COLLSCAN。
- 确认是否走索引：用
explain("executionStats")查看stage字段，是IXSCAN还是COLLSCAN - 注意 collation 一致性：如果索引建了
{collation: {locale: "en", strength: 2}}，查询也必须显式带上相同collation，否则索引失效 - 避免混用
$options: "i"：它会触发大小写归一化，若索引没配 collation，MongoDB 无法对齐匹配逻辑，直接放弃索引
text 索引和 $regex 完全不兼容
别指望建了 text 索引就能加速 $regex 查询——它们底层机制完全不同：text 索引做分词、词干提取、权重计算，只响应 $text 操作符；而 $regex 是逐字符模式匹配，永远绕过 text 索引。
常见错误是看到 db.collection.createIndex({content: "text"}) 就以为模糊搜索变快了，结果 explain() 显示 stage: COLLSCAN，白白浪费写入开销。
- 需要关键词语义搜索（支持同义词、短语、排除项）→ 用
$text+text索引 - 需要精确字符串模式（如邮箱格式校验、路径前缀提取）→ 用
$regex+ 普通索引（且仅限 ^ 前缀） - 两者不能共存于同一查询：含
$text的查询里不能带$regex，反之亦然
前缀太短或数据倾斜时，索引实际无效
即使 ^A 语法合法且命中了索引，也可能慢得像全表扫描——因为索引选择性太低。例如 name 字段有 100 万条记录，其中 80 万条以 "Unknown_" 开头，db.users.find({name: {$regex: "^Unknown_"}}) 会先通过索引定位这 80 万条，再逐条做正则剩余部分匹配（即文档级过滤），totalDocsExamined 和 nReturned 差距极大。
- 用
explain("executionStats")对比这两个值：接近说明索引真过滤了；差 10 倍以上，说明只是“定位”而非“筛选” - 前缀长度建议 ≥3 字符（如
^abc），避免^a、^A这类低区分度模式 - 高频前缀字段（如 status="active" 占 95%）不适合建正则索引，改用等值查询 + 索引更稳
真正可靠的替代方案不是改正则，而是改数据结构
当业务需要「中间匹配」「大小写无关」「模糊容错」时，硬调 $regex 参数或堆索引只会让问题更糟。更有效的是预处理字段，把运行时计算转为写时计算。
- 需要大小写无关前缀查姓名？存一个
name_lower字段，建索引并查{name_lower: /^alice/} - 需要邮箱域名模糊匹配？额外存
domain字段（如 "gmail.com"），直接{domain: "gmail.com"} - 需要支持 typo 容错？用第三方库（如 fuse.js）在应用层做 fuzzy search，或引入 MongoDB Atlas Search（支持 fuzzy、phonetic、autocomplete）
- 函数索引（v4.4+）可封装逻辑：如
createIndex({$function: {body: "function(x) { return x.toLowerCase(); }", args: ["$name"], lang: "js"}}, {name: "name_lower_func_idx"})，但注意 JS 引擎性能开销
正则索引的适用场景非常窄：固定前缀、大小写敏感、前缀足够长且分布均匀。超出这个范围，优化方向不是调参，而是换思路——把模糊逻辑从数据库下推到写入端或应用层。
