通配符索引仅适用于字段名不可预知的schema-less场景，如爬虫动态字段、命名空间嵌套路径、用户自定义属性等；必须用"field.$**"语法声明路径模式，禁用模糊写法；其性能易受索引膨胀、低选择性及无法投影影响，需结合压测与替代方案谨慎使用。
通配符索引（wildcard index）是 MongoDB 5.0+ 引入的、专为 Schema-less 场景设计的索引类型，它能显著加速对动态字段、嵌套路径或未知键名的非结构化数据检索。但它的效果高度依赖字段访问模式和索引配置，盲目启用反而拖慢写入、浪费内存。
什么时候必须用 wildcardIndex？
当你遇到以下典型场景时，wildcardIndex 才是合理选择：
- 爬虫数据中字段名不固定（如不同网页解析出的
price_2026、price_usd、final_price），且需按“所有含price的字段”快速过滤 - 日志文档里存在大量带命名空间的嵌套字段（如
metrics.cpu.usage、metrics.memory.available），查询常以metrics.*为前缀 - 用户自定义属性集合（如
custom_fields对象）字段名完全由前端传入，后端无法预知键名 - 已有复合索引无法覆盖新增字段，又不想频繁重建索引（例如每上线一个新标签就加一个字段索引）
如果字段名稳定、查询条件明确（比如始终查 title 和 content），优先用普通文本索引或复合索引——更轻量、更可控。
createIndex 中通配符字段怎么写？
通配符索引不是“模糊匹配字段名”，而是声明一个**路径模式**，MongoDB 会自动为该路径下所有匹配的字段建索引。写法有严格限制：
- 只支持
$**（全文档）或"path.$**"（指定子路径），不能写成"*.price"或"price*" - 嵌套对象必须用点号分隔，如
"attributes.$**"，不能用"attributes.*" - 要排除某些子路径，得用
excludeFilters，例如：db.logs.createIndex( { "metadata.$**": 1 }, { excludeFilters: { "metadata.temp": 1 } }) - 不支持在通配符索引上设置权重（
weights），所以不适合做相关性排序
为什么 explain() 显示用了索引但查询还是慢？
这是通配符索引最常被忽略的陷阱：它确实能命中，但可能扫描大量无效索引条目。原因包括：
- 索引膨胀严重：一个
$**索引会对每个文档的每个字段都建索引项，10 万文档 × 平均 20 字段 = 200 万索引条目，内存占用激增 - 选择性差：如果
attributes.$**下 90% 的字段值都是null或空字符串，索引几乎不起过滤作用 - 无法覆盖查询：通配符索引不支持
projection，即使只查_id和url，仍需回表读完整文档 - 与 TTL 或文本索引冲突：MongoDB 不允许在同一集合上对同一路径同时建通配符索引和文本索引
验证方式：运行 db.collection.explain("executionStats").find({ "attributes.color": "red" })，重点看 nReturned 和 totalKeysExamined 是否接近——若后者远大于前者，说明索引效率低下。
替代方案比硬上 $** 更靠谱
多数非结构化场景下，更稳的解法是组合策略，而非依赖单一通配符索引：
- 对高频固定字段（如
url、crawl_time、status）建普通单字段或复合索引 - 对内容类字段（如
parse_data.text）单独建text索引，配合$text查询 - 用
schema validation+required字段约束，把“半结构化”往“弱结构化”拉一点，降低通配需求 - 对真正动态的字段，改用
array of embedded documents存储，例如：{ "custom_props": [ { "key": "shipping_method", "value": "express" } ] }然后对custom_props.key和custom_props.value建多键索引
通配符索引不是银弹，它是给“字段名真的不可控”留的最后出口。上线前务必用真实数据集压测索引大小和 insert 延迟——WiredTiger 在高基数通配索引下，写入吞吐可能下降 40% 以上。
