通配符索引在MongoDB 6.0中需FCV≥4.2才可创建，不支持字段不存在、文档/数组等值匹配及$text查询，仅加速子字段存在性查询，写入开销高且不可替代精准索引与投影优化。
通配符索引在 MongoDB 6.0 中确实能缓解“字段太多、索引难管”的问题，但它不是万能加速器——用错场景反而拖慢查询，甚至让某些常见查询完全失效。
创建通配符索引前必须确认 FCV 为 4.2+
通配符索引依赖 featureCompatibilityVersion ≥ 4.2。如果当前 FCV 是 4.0 或更低（比如刚从 4.0 升级上来但没手动升级 FCV），createIndex({"field.$**": 1}) 会直接报错："Wildcard indexes require featureCompatibilityVersion >= 4.2"。
- 先检查：运行
db.adminCommand({getCmdLineOpts: 1})或db.runCommand({getParameter: 1, featureCompatibilityVersion: 1}) - 升级 FCV 前必须确保所有节点已升级到 6.0，并且没有遗留的 4.0/4.2 特性在用（比如某些旧聚合阶段）
- 执行升级命令是
db.adminCommand({setFeatureCompatibilityVersion: "4.2"})，不是 "6.0" —— MongoDB 的 FCV 命名和版本号不一致，这是最容易卡住的第一步
哪些查询根本不会走通配符索引
通配符索引只对“字段存在且值匹配”的查询生效，它不索引空字段、不索引字段本身是否存在、也不支持文档/数组级别的等值判断。
-
db.col.find({"tags": {$exists: false}})→ 完全不命中，通配符索引是稀疏的，跳过缺失字段 -
db.col.find({"meta": {"type": "user", "active": true}})→ 不走索引，因为通配符索引展开的是meta.type和meta.active，但不存meta这个完整对象 -
db.col.find({"attrs.tags": ["a", "b"]})→ 不走索引，数组整体匹配被忽略；但{"attrs.tags": "a"}可以命中 - 任何含
$text的查询都和通配符索引无关，二者互斥
通配符索引 + 复合查询时的实际效果
如果你的查询同时带多个条件（比如 {status: "pending", "attrs.priority": 1}），单建一个 {"attrs.$**": 1} 并不能覆盖 status 字段——它只负责 attrs 下所有子字段。真正起效的方式往往是组合：
- 保留高频固定字段的单字段索引（如
{status: 1}） - 对动态属性字段建通配符索引（如
{"attrs.$**": 1}） - MongoDB 6.0 支持索引交集（index intersection），但仅限于简单
$and查询；聚合管道里不触发交集，$match阶段仍只能选一个索引 - 想让
status和attrs.priority同时走索引，更稳的方式是建复合索引{status: 1, "attrs.priority": 1}，而不是依赖通配符
性能与维护成本的真实权衡
通配符索引写入开销比普通索引高得多：每个嵌套层级、每个数组元素都会生成独立索引条目。一个 {"payload.$**": 1} 索引可能让写入延迟上升 3–5 倍，尤其当 payload 是深嵌套或含大数组时。
- 用
db.collection.stats()查看indexDetails中该索引的size和count，对比其他索引，往往高出一个数量级 - 不要在日志类、审计类集合上盲目加通配符索引——这些集合写多读少，索引反而成为瓶颈
- 如果业务中 80% 的动态查询只集中在 3–4 个子字段（如
attrs.category、attrs.score），不如明确建这几个字段的单索引或复合索引，更轻量可控
通配符索引最易被忽略的一点：它无法替代投影优化。即使查询走了索引，若 $project 或聚合返回了未索引的大字段（比如整个 payload 文档），网络传输和内存压力依然存在——这点和普通索引一样，但更容易被“已经建了通配符索引”的心理暗示绕过去。
