Wildcard索引仅适用于字段名不可预知的Schema-less场景，如爬虫动态字段、命名空间嵌套路径、用户自定义属性等；必须用"field.$**"语法声明路径模式，禁用模糊写法；其性能易受索引膨胀、低选择性及无法投影影响，需结合压测与替代方案谨慎使用。
Wildcard索引不是万能的“自动索引生成器”，它只对明确声明的字段路径生效，且无法加速所有查询模式——比如 $text 查询、未启用通配符匹配的嵌套数组展开，或字段名本身是运行时拼接的字符串。
Wildcard索引适用于哪些动态字段场景
当你有大量文档，结构不统一，但共性是某些嵌套层级下存在命名规律的字段（如 metadata.*.timestamp、tags.*.value），且查询经常按这些“任意键名下的固定子字段”过滤时，Wildcard索引才真正有用。它不解决“字段名完全随机+值类型混乱”的极端情况。
常见适用场景包括：
- 多租户系统中，每个租户自定义的扩展字段都存于
custom_fields对象内 - IoT设备上报数据中，传感器ID作为键名，值为带
value和unit的子对象 - 用户 profile 中的
preferences.*.enabled这类布尔开关配置
db.collection.createIndex() 中 wildcardProjection 的写法要点
必须显式指定通配符路径，不能只写 {"$**": 1} —— 那是全字段通配，开销大且不支持部分匹配优化。真正可控的方式是用 {"metadata.$**": 1} 或更细粒度的 {"metadata.*.timestamp": 1}。
关键约束：
-
metadata.*.timestamp中的*只匹配**一级**键名，不递归；要匹配两级需写metadata.*.*.timestamp - 不能在通配符路径后追加数组索引操作符，如
tags.*.items.0.name是非法的 - 如果目标字段可能为
null或缺失，索引仍会记录该文档，但查询时需配合{$exists: true, $ne: null}才能稳定命中
示例命令：
db.events.createIndex({"sensor_data.$**": 1}, {wildcardProjection: {"sensor_data.timestamp": 1, "sensor_data.value": 1}})
为什么 find({"sensor_data.temp": {"$gt": 25}}) 可能不走 Wildcard 索引
Wildcard 索引默认只加速对**通配路径中实际存在的字段**的等值或范围查询。若你创建的是 {"sensor_data.$**": 1}，但文档里实际存的是 {"sensor_data": {"temp_001": {"value": 26}}}，那么 temp 字段根本不存在，自然无法命中。
更隐蔽的问题：
- 查询字段名与索引路径中通配部分不一致：比如索引建在
data.*.v，但查的是data.foo.val（字段名是val而非v） - 使用了不被支持的操作符：
$regex在通配字段上基本不走索引；$elemMatch套在通配路径外层时也可能失效 - 查询条件含多个通配字段组合，而索引只覆盖其中一部分，MongoDB 可能放弃使用该索引
性能与维护成本的真实代价
Wildcard 索引会显著增加写入延迟和磁盘占用——每插入一个含 5 个 sensor 子对象的文档，就相当于隐式插入 5 条索引条目。在高吞吐写入场景下，这点比普通复合索引更敏感。
必须注意：
- 无法在分片集群中对通配字段执行
shardKey，即不能用sensor_data.*.timestamp作为片键 -
explain("executionStats")中看到wildcardProjection不等于索引被使用；要确认executionStages.stage === "IXSCAN"且indexName匹配 - 重建索引时，Wildcard 索引耗时远高于普通索引，且期间会阻塞写操作（除非用
background: true，但会延长总时间）
真正棘手的地方在于：字段动态性越强，索引覆盖率和查询可预测性就越低。你得在“写入变慢”和“查询超时”之间反复权衡，而不是幻想建一个索引就一劳永逸。
