通配符索引仅适用于字段名真正不确定的动态场景，如第三方JSON数据；它会显著增加写入开销、内存占用，并可能误导查询优化器，不能替代合理建模。
通配符索引在 MongoDB 4.4+ 中确实能缓解动态字段带来的建模压力，但它不是“自动加速查询”的银弹——用错场景或参数反而拖慢写入、浪费内存、掩盖真实的数据建模问题。
通配符索引只适用于字段名不确定的场景
比如你接收第三方 JSON 数据，字段名随设备型号、API 版本、用户配置而变：sensor_v2_temp、temp_reading_c、temperature_value。这种情况下，你无法提前预知所有字段名，也无法为每个字段单独建索引。
- ✅ 适合：文档结构高度不一致，且查询常针对任意嵌套路径（如
{"metadata.$**": "error"}或{"payload.device.*": {"$exists": true}}） - ❌ 不适合：字段名实际是固定的（只是你没统一命名），比如
user_name和userName并存——这时该做数据清洗或 schema 迁移，而不是依赖$** - ⚠️ 注意：
$**索引默认跳过_id，如果查询里带_id条件又想走索引覆盖，得显式加进wildcardProjection，但一般没必要
createIndex({ "$**": 1 }) 的实际开销比你想象的大
它不是“建一个索引”，而是对集合中每个文档的每个非空字段值（含嵌套路径）都生成一条索引条目。一个含 5 层嵌套、12 个字段、3 个数组的文档，可能生成上百个索引项。
- 写入放大明显：每次
insert或update都要同步更新所有匹配的通配符索引项，实测写吞吐可下降 30%~60% - 内存占用高：索引体积常达原始数据的 2~4 倍，尤其当字段值短但路径深（如
log.entries.0.meta.tags.0.name）时 - 查询计划器容易“误选”：即使存在更优的单字段索引，
explain("executionStats")可能显示它用了$**——因为通配符索引能“覆盖更多谓词”，但实际扫描量更大
真正有效的通配符索引用法是限定作用域
全字段通配（{"$**": 1}）应是最后手段。优先考虑带前缀的通配，把爆炸式索引控制在可预期范围内。
- 对嵌套对象字段建索引：
db.collection.createIndex({ "payload.$**": 1 })—— 只索引payload下所有子字段，忽略metadata、header等无关部分 - 组合等值条件缩小范围：
db.collection.find({ "type": "event", "payload.status": "failed" })中，type字段必须有独立索引，才能先快速过滤出event类型文档，再让payload.$**处理后续字段 - 避免在数组字段上无约束通配：
{"items.$**": 1}对items: [{a:1,b:2}, {a:3,c:4}]会为每个数组元素分别展开索引，极易膨胀；若只需查items.a，直接建{"items.a": 1}更高效
通配符索引无法替代合理的数据建模决策
很多团队用 $** 是为了回避重构——比如把用户属性全塞进 custom_fields 对象，字段名由前端传入。短期省事，长期代价是：查询难优化、聚合难编写、备份恢复慢、监控指标失真。
- 通配符索引不支持
$text查询——需要全文检索？必须另建{"$**": "text"}（通配符文本索引），但它和{"$**": 1}互斥，且写入延迟更高 - 它不解决“字段语义混乱”问题：两个文档都有
score字段，但一个是百分制整数，一个是小数评级，索引建了也难写出稳定查询 - 真正可持续的做法是：用
schema validation+change streams捕获新字段，定期评估是否提升为一级字段并建目标索引
通配符索引最易被忽略的一点：它无法加速涉及数组内容的多条件组合查询（例如 {"tags": "urgent", "items.price": {"$gt": 100}}），因为索引条目是扁平展开的，无法保证两个条件落在同一数组元素内——这时候必须靠应用层拆分查询，或改用聚合管道预计算。
