<p>Wildcard indexes 不加速 $regex 查询，仅支持动态字段路径的精确匹配（如 $eq、$in、范围查询），且需配合 <strong>$ 或显式通配路径；$regex 必须依赖前缀正则 + 单字段索引。</p>
Wildcard indexes 不能加速 $regex 查询，也不能替代前缀正则的单字段索引。 它们只对动态字段路径（比如日志、嵌套配置、用户自定义属性）的 $eq、$in、范围查询等有效，且必须配合 $** 路径或显式通配路径使用。想让模糊查询快，得回到正则前缀 + 单字段索引的老路，别指望 wildcard index “自动覆盖” $regex。
为什么 $regex 不走 wildcard index
Wildcard index 的设计目标不是文本匹配，而是解决“字段名不确定”的场景。MongoDB 明确文档指出：$regex 操作符 永远不会 使用 wildcard index —— 即使你建了 { "$**": 1 }，查 { tags: { $regex: "^web" } } 依然全表扫。
- 它只索引字段值，不索引字段路径的字符串结构（比如
"tags.name"这种路径本身不可被正则匹配） -
$regex是在值上做模式扫描，wildcard index 存的是扁平化的键值对，没存原始 JSON 路径层级 - 官方测试用例和
explain()结果都验证：wildcard index 对$regex的stage是COLLSCAN，不是IXSCAN
$** 索引在什么模糊场景下真有用
它只在你明确知道要查“某个未知子字段等于某值”时才生效，本质是“字段路径模糊 + 值精确匹配”，不是“值模糊”。比如日志文档里字段名随 SDK 版本变：
db.logs.insert({ timestamp: ISODate(), "v2.metrics.cpu": 85, "v3.metrics.memory": "12GB" })
- 查所有含
"metrics"路径且值为85的文档：db.logs.find({ "v2.metrics.cpu": 85 })→ 走普通索引 - 但你想查“任意 metrics 子字段值为 85”：
db.logs.find({ "metrics.$**": 85 })→ 才可能走{ "metrics.$**": 1 }索引 - 注意：
"metrics.$**"是显式通配路径，不是"$**"全局通配；后者会极大膨胀索引体积，一般不推荐
真正能提速模糊查询的索引组合
别绕弯，回到最可控的路径：前缀正则 + 字段确定 + 索引对齐。三个条件缺一不可：
- 正则必须写成字符串形式：
{ name: { $regex: "^alice" } }，不能写/^alice/字面量 - 字段
name必须有单字段索引：db.users.createIndex({ name: 1 })；如果是复合索引，name得是第一个字段 - 禁用
options：去掉i、m等标志；真要忽略大小写，就提前建name_lower字段并索引它 - 如果字段是数组（如
tags: ["web", "api"]），$regex默认查数组元素值，这时索引仍有效 —— 但 wildcard index 对这种场景无额外收益
容易被忽略的性能陷阱
即使 explain() 显示 IXSCAN，也不代表快。关键看 nReturned 和 totalDocsExamined 是否接近：
- 如果
^A匹配了集合里 60% 的文档，索引只是帮你快速定位到这 60% 的 _id，后续还得反查完整文档做正则再过滤 —— I/O 和 CPU 成瓶颈 - wildcard index 的
keyPattern是{ "$**": 1 }，它会为每个嵌套字段都建索引项，导致索引体积爆炸，写入延迟上升，尤其当文档有深层嵌套或大量可选字段时 - 没有
$text索引时硬上 wildcard index 做关键词搜索，效果远不如建{ title: "text", content: "text" }并用$text
