频繁插入本身不直接产生索引碎片，但会加速wiredtiger索引页分裂和空间复用失衡；真正需监控的是page fill rate与available for reuse空间，现象为explain中totaldocsexamined远大于nreturned且available for reuse持续增长。
频繁插入本身不直接产生索引碎片，但会加速索引页分裂和空间复用失衡——真正要盯的是 WiredTiger 的 page fill rate 和 available for reuse 空间。
为什么 insert 多了索引就变慢？
WiredTiger 引擎在插入时按 B-tree 结构写入索引页。当字段基数低（如 status: "pending"）、或写入顺序与索引键不匹配（比如按时间戳建索引但插入乱序），就会触发频繁页分裂。分裂后旧页留下空洞，新页分散写入，物理上不连续，但逻辑上仍可查——这就叫“索引碎片”。
- 现象：查询
explain("executionStats")中totalDocsExamined远大于nReturned，且wiredTiger.block-manager.file bytes available for reuse持续增长 - 注意：不是所有高插入量都会碎片化，关键看索引字段分布是否集中、插入是否批量有序
- 复合索引里把高基数字段放前面（如
{userId: 1, createdAt: -1}）比反过来（{createdAt: -1, userId: 1}）更能缓解分裂
compact 能不能直接修 insert 导致的碎片？
能，但有硬限制：compact 会重写整个集合的数据文件和所有索引，释放 available for reuse 空间，让索引页物理连续。但它只解决“空间复用不均”，不修正设计缺陷。
- 必须在副本集 Primary 或分片集群的 shard 节点上执行：
db.runCommand({ compact: "mycollection", force: true }) - 执行期间该集合读写全阻塞（WiredTiger 集合级排他锁），只能在业务低峰期做
- 如果索引本身建在写密集字段（如自增计数器、毫秒级时间戳），compact 后几小时又会快速复现碎片——得先改索引设计
reIndex 和 background: true 建索引有什么区别？
reIndex 是阻塞式重建，createIndex({ ..., background: true }) 是后台构建，但两者对写入压力的影响逻辑不同。
-
db.mycollection.reIndex()：锁表，所有写入排队；适合小集合或维护窗口明确的场景 -
background: true：不锁表，但仍在内存中构建 B-tree，并争抢wiredTiger.cache和 journal 刷盘带宽；瞬时高并发写入下，反而可能加剧 IO 延迟 - 更稳妥的做法：先删旧索引（
dropIndex），再用collMod + indexBuildRetry控制建索引节奏，失败后自动续建，不重头来
日常怎么防住 insert 引发的碎片？
核心是控制索引更新频次和数据写入局部性。别等碎片大了才动手。
- 写密集字段（如
updatedAt,counter）尽量不单独建索引；必须查的话，走覆盖查询 + 复合索引前置过滤字段 - 批量插入前，用
db.runCommand({ setParameter: 1, wiredTigerEngineConfigString: "cache_size=8G" })临时调大 cache，减少刷盘竞争（需配合wiredTiger.cacheSizeGB配置） - 监控
wiredTiger.cache: bytes currently in the cache是否长期 >90% of max —— 超了说明索引节点频繁换出，碎片影响会被放大 - GridFS 场景下，永远用
GridFSBucket.delete()删除文件，避免只删fs.chunks留下孤儿块，这是fs.chunks.files_id_1_n_1索引碎片的主因
碎片不是“坏了”，而是索引结构和写入模式不匹配的自然结果。最常被忽略的一点：compact 和 reIndex 都治标，真正治本的是索引字段选择和写入节奏控制——尤其当插入来自消息队列或日志采集这类不可控源头时，得靠前置聚合或 TTL 来削峰。
