通配符索引适用于字段名动态、不可预知的嵌套结构查询，如用户自定义属性metadata.tags或sensor_001_temp；仅支持一级子字段（metadata.color）的$eq、$in等单字段查询，不支持$regex、多级嵌套（metadata.foo.bar）或数组内展开。
通配符索引适用于哪些查询场景
MongoDB 的通配符索引（wildcard index）专为文档中未知键名、动态字段名的查询设计，比如用户自定义属性、多语言字段（title_en、title_zh）、设备上报的传感器字段（sensor_001_temp、sensor_002_humid）等。它不加速固定字段（如 name、status）的查询，也不替代常规索引。
常见误用现象：给整个 metadata 对象建通配符索引后，仍对 metadata.foo.bar 使用点号嵌套路径查询——这不会命中通配符索引，因为通配符索引只匹配“一级子字段”，即 metadata.foo 可以，但 metadata.foo.bar 不行。
- 通配符索引仅覆盖
obj.key形式的一级字段（无论obj是根文档还是嵌入文档） - 支持
$eq、$in、$lt/$gt等单字段比较操作，不支持$regex全文扫描式匹配 - 查询必须显式指定字段路径模式，例如
{"metadata.$**": {"$eq": "active"}}，不能写成{"metadata": {"$eq": "active"}}
如何创建有效且可控的通配符索引
通配符索引开销比普通索引高：它会为每个匹配到的字段单独建立索引条目，字段越多、文档越深，索引体积越大、写入延迟越明显。因此必须限制范围。
- 使用
coll.createIndex({"metadata.$**": 1})是最简形式，但风险高：只要metadata下新增任意字段，就自动纳入索引 - 更安全的做法是配合
wildcardProjection选项白名单过滤，例如：db.items.createIndex( {"metadata.$**": 1}, {wildcardProjection: { "tags": 1, "flags": 1, "score_*": 1 }} )这样只有metadata.tags、metadata.flags和以score_开头的字段（如score_a、score_b）被索引，其余一律忽略 - 避免在根级别建
{"$**": 1}—— 它会索引所有字段（包括_id、__v等），极易拖垮性能
为什么查询没走通配符索引？常见漏点
即使索引存在，查询也可能退化为 COLLSCAN，原因往往很具体：
- 查询条件未使用
$<strong></strong>路径语法：{"metadata.color": "red"}不会触发通配符索引；必须写成{"metadata.$": "red"}或更精确地{"metadata.color": "red"}（前提是该字段名已知且已在wildcardProjection中声明） - 同时查询多个动态字段时用了
$and，但通配符索引无法联合优化多个$<strong></strong>条件，例如{$and: [{"metadata.$": "A"}, {"metadata.$**": "B"}]}会失效 - 字段值类型不一致：通配符索引对类型敏感，
"123"（字符串）和123（数字）被视为不同值，若业务混存，需统一写入格式或加类型检查 - 在分片集群中，通配符索引只能建在分片键上或作为局部索引（
background: true+partialFilterExpression配合），否则 mongos 可能忽略
通配符索引与聚合管道的配合边界
通配符索引可被 $match 阶段利用，但仅限于最前的、独立的 $match（即不嵌套在 $lookup 或 $facet 内）。一旦进入 $unwind 或 $group，索引即失效。
- 正确示例：
db.items.aggregate([{$match: {"metadata.$**": "draft"}}, {$project: {...}}])→ 能用索引 - 错误示例：
db.items.aggregate([{$unwind: "$events"}, {$match: {"events.data.$**": 42}}])→ 不会使用通配符索引，因为$match在$unwind后，且events.data是数组内嵌对象，通配符索引不展开数组元素
真正容易被忽略的是：通配符索引不降低内存压力。即便查询走了索引，如果匹配结果集大，后续的 $sort 或 $group 仍可能触发 Sort exceeded memory limit 错误——它只解决“找得快”，不解决“算得省”。
