MongoDB创建索引突增几十GB磁盘占用，因B-tree结构含键值、指针、元数据及填充空间，长文本/数组字段索引体积常超原始数据；默认索引不压缩（compressor="none"），需在createIndex()中显式通过storageEngine.wiredTiger.configString指定zstd等压缩器并调小leaf_page_max/internal_page_max至16k，旧索引须删除重建，压缩效果取决于数据重复性，且会增加CPU解压开销。
创建索引为什么突然吃掉几十GB磁盘
MongoDB 创建索引时，不是“复制字段值”那么简单——它会为每个索引项构建完整的 B-tree 结构，包含键值、文档位置指针（recordId）、内部元数据和填充空间。尤其当字段含长文本、嵌套对象或数组时，索引体积可能远超原始数据本身。例如对一个 content 字段建普通索引，若平均文档该字段 2KB，1000 万条文档就可能生成 >30GB 的索引文件（WiredTiger 默认不压缩索引）。
默认不压缩索引：wiredTigerEngineConfig 不生效的常见误区
很多人尝试在启动参数里加 wiredTigerEngineConfig.configString="block_compressor=zstd"，却发现新建索引依然没变小——这是因为该配置**只影响新创建的数据文件（.wt 文件）的块级压缩，不自动应用到索引文件**。索引文件（如 index-12345.wt）默认使用 none 压缩器，即使你改了全局 configString。
- 验证方式：连接后执行
db.runCommand({collStats: "mycollection"})，检查indexDetails下各索引的compressor字段，多数显示"none" - 真正生效的方式是建索引时显式指定压缩器，且仅限 WiredTiger 存储引擎（4.2+）
- 注意：zstd 压缩需 MongoDB ≥ 4.2 + WiredTiger ≥ 3.2.1，旧版本只能用
snappy
建索引时强制启用 zstd 压缩的正确写法
必须在 createIndex() 的 storageEngine 选项里单独声明，不能靠全局配置：
db.mycollection.createIndex(
{ "content": "text" },
{
"name": "content_text_zstd",
"storageEngine": {
"wiredTiger": {
"configString": "block_compressor=zstd,leaf_page_max=16k,internal_page_max=16k"
}
}
}
)
-
leaf_page_max和internal_page_max建议设为 16k（而非默认 64k），小页能提升 zstd 压缩率，尤其对重复前缀的文本索引 - 对已有索引无法“在线改压缩”，只能删掉重建（
db.mycollection.dropIndex("old_index_name")） - 重建期间会锁表（WiredTiger 3.2.1+ 支持部分后台重建，但压缩参数仍需显式传入）
压缩后空间节省多少？别盲目期待 50%
实际压缩效果高度依赖数据特征：
- 纯数字/短字符串索引（如
{status: 1}）压缩收益极低，zstd 可能只省 5–10%，甚至因元数据开销反而略大 - 长文本、日志、JSON blob 类字段（如
message,payload）通常能压到原体积 30–60%，前提是内容有重复模式 - 复合索引中混入高基数字段（如
{ts: 1, user_id: 1, content: "text"}）会显著削弱压缩率，建议拆分为独立索引 - 务必用
db.collection.stats().totalIndexSize对比前后值，而不是只看dataSize—— 后者不含索引
最易被忽略的一点：压缩索引虽省磁盘，但查询时 CPU 解压开销会上升，高并发全文检索场景要实测延迟变化。
