通配符索引不支持建在分片键字段上，mongodb会拒绝创建并报错；要求fcv≥4.2；不兼容唯一、ttl、哈希等索引类型；不支持sparse和partialfilterexpression；易导致索引膨胀与查询优化器误选。
通配符索引不支持分片键字段
在分片集群中，userMetadata.$** 这类通配符索引不能建在分片键字段上。MongoDB 会直接拒绝创建请求，并返回类似 Cannot create wildcard index on a shard key field 的错误。即使分片键是复合的，只要通配符路径覆盖了任意一个分片键字段（比如 {"shardKeyA": 1, "userMetadata.$**": 1}），整个索引创建都会失败。
原因在于分片逻辑依赖确定的、静态的字段路径做路由和数据分布，而通配符索引的动态展开与之冲突。如果你需要对分片键下的嵌套结构做查询加速，只能手动为已知子字段建普通索引，比如 {"userMetadata.likes": 1}、{"userMetadata.age": 1}。
FCV 必须设为 4.2 或更高
通配符索引要求 featureCompatibilityVersion（FCV）至少为 "4.2"。如果当前 FCV 是 "4.0" 或更低，db.userData.createIndex({"userMetadata.$**": 1}) 会报错：Wildcard indexes require featureCompatibilityVersion 4.2 or greater。
升级 FCV 不是单纯执行命令就能完成的事：必须先确保所有节点都运行 MongoDB 4.2+，再逐个执行 db.adminCommand({setFeatureCompatibilityVersion: "4.2"})。6.0 部署默认 FCV 是 "6.0"，但若从旧版本升级未手动设置，FCV 可能仍卡在旧值。
- 检查当前值：
db.adminCommand({getParameter: 1, featureCompatibilityVersion: 1}) - FCV 升级不可逆，且会影响某些旧版驱动行为，需提前验证应用兼容性
无法与唯一约束、TTL、哈希索引共存
$** 通配符索引只支持 1、-1、text 和 2dsphere 类型的排序方向，明确禁止以下组合：
-
{"userMetadata.$**": "hashed"}→ 报错：Hashed indexes do not support wildcard projections -
{"userMetadata.$**": 1, expireAfterSeconds: 3600}→ TTL 索引不支持通配符路径 -
{"userMetadata.$**": 1, unique: true}→ 唯一约束在动态字段上无实际意义，MongoDB 直接拒绝
另外，通配符索引不支持稀疏选项（sparse: true），也不支持部分索引（partialFilterExpression）。这些限制源于其底层设计——它本质上是对任意嵌套结构做“全量展开索引”，无法预判哪些路径该被跳过或约束。
索引大小和查询选择性容易失控
一个 {"meta.$**": 1} 索引可能比预期大得多：它会对 meta 下每个嵌套文档、数组元素、甚至字符串内部的每个单词（如果是 text 索引）都建立条目。例如，{"meta": {"tags": ["a", "b", "c"], "props": {"x": 1, "y": 2}}} 会被展开为至少 5 个独立索引项。
更隐蔽的问题是查询优化器行为：当存在通配符索引时，db.collection.find({"meta.tags": "a"}) 可能优先选它，哪怕你同时有更精准的 {"meta.tags": 1} 普通索引。可通过 explain("executionStats") 观察 winningPlan 中是否用了 IXSCAN 对应 $** 索引。如果性能不如预期，得用 hint() 强制走具体字段索引。
真正该用通配符索引的场景很窄：仅限 schema 完全不可控、字段名纯由用户输入决定、且查询模式高度分散的元数据场景。多数业务系统里，宁可多建几个明确字段索引，也别轻易上 $**。
