wiredtiger索引前缀压缩仅对具有重复前缀的复合索引生效，单字段索引或字段离散/顺序不当的复合索引不触发压缩；需重建索引并确保字段按低基数→高基数排序才能生效。
为什么 prefixCompression: true 没生效？
WiredTiger 的索引前缀压缩默认开启，但实际不生效往往不是配置写错了，而是它只对「复合索引」中具有公共前缀的字段起作用。单字段索引、或字段顺序混乱/值分布高度离散的复合索引，WiredTiger 会跳过前缀压缩——因为压不了，或者压了反而更占空间。
验证是否启用：连接 mongosh 执行 db.serverStatus().storageEngine.wiredTiger，检查 indexConfig.prefixCompression 是否为 true；再查 db.getCollectionInfos({name: "your_collection"}) 中的 options.indexOptions 字段，确认索引创建时未显式禁用（如含 "prefixCompression": false）。
哪些索引能真正受益于前缀压缩？
前缀压缩本质是利用索引键中重复前缀（比如 {"status": "active", "region": "us-east", "user_id": 123} 这类结构）做字典式去重。它对以下场景效果明显：
- 复合索引中前 1–2 个字段取值有限且高度重复（如
status、tenant_id、category） - 字段顺序严格按“高基数→低基数”排列不合理，应改为“低基数→高基数”（例如
{tenant_id: 1, created_at: -1}比{created_at: -1, tenant_id: 1}更易压缩） - 索引键整体长度较长（> 20 字节），且前缀部分有稳定字符串/枚举值
反例：索引含 _id（唯一）、timestamp（毫秒级精度）、或大量随机字符串字段，前缀压缩基本无效，甚至可能略微增加开销。
如何强制让前缀压缩在新建索引中生效？
配置文件里设 prefixCompression: true 只影响后续新建索引，已有索引不会自动重写。必须重建索引才能应用新策略：
- 删除旧索引：
db.collection.dropIndex("old_index_name") - 重建时显式指定（可选，但推荐）：
db.collection.createIndex({"tenant_id": 1, "event_type": 1, "ts": -1}, {"prefixCompression": true}) - 注意：重建期间索引不可用，生产环境建议配合
background: true
不要依赖 collMod 修改已有索引的压缩选项——WiredTiger 不支持运行时变更索引压缩行为。
容易被忽略的关键点
前缀压缩只压缩索引 B-tree 的内部节点（inner nodes），不影响叶子节点（leaf pages）的数据布局；它也不压缩索引对应的文档数据本身——那是 blockCompressor 干的事。很多人混淆这两者，结果调了半天 prefixCompression 却发现磁盘空间没变，其实是该看 collectionConfig.blockCompressor。
另外，MongoDB 4.4+ 对短字符串（≤ 8 字节）做了特殊优化，此时前缀压缩收益极小；如果你的索引字段多为 ObjectId 或短哈希，别强求压缩效果。
