写放大主因是B-Tree索引的页分裂与键重排，而非索引数量本身；插入/更新时页满触发分裂，导致单次逻辑写引发多次物理写，高并发下IO放大可达3–5倍，复合索引和分片不匹配会进一步加剧该问题。
写放大不是索引本身造成的，而是B-Tree结构在写入时的物理行为
很多人把“写放大”直接归因于索引数量多，其实更准确的说法是：MongoDB 的 B-Tree 索引在插入/更新/删除过程中，会触发页分裂（page split）和键重排，导致单次逻辑写操作引发多次磁盘块写入。这不是配置错误，而是 B-Tree 数据结构的固有代价。
当一个索引页（默认 4KB）填满后，新键值无法插入，MongoDB 必须分裂该页——把约一半键值迁移到新页，并更新父节点指针。这个过程涉及至少 2 次随机写（原页 + 新页），如果父节点也满，则向上递归分裂，IO 放大倍数可能达 3–5 倍。
尤其在高并发写入场景下（如 ChatBot 的实时消息写入），多个线程竞争同一索引页，还会引发写锁等待和重试，进一步拉长写延迟。
复合索引让写放大更隐蔽但更严重
单字段索引写放大相对可预期，而复合索引（比如 { userId: 1, timestamp: -1 }）会让写放大变得不均匀且难监控。因为排序键（timestamp）天然具有时间局部性，新数据总往索引“尾部”追加；但 userId 分布离散，导致同一 userId 的多条记录在索引中物理分散，插入时频繁触发不同页的分裂。
常见错误现象：explain("executionStats") 显示 keysExamined 和 nReturned 接近，但写入吞吐骤降、wt_cache_overhead 持续升高——这往往说明索引页碎片化严重，WiredTiger 缓存被迫频繁刷脏页。
- 避免把高基数字段（如
_id）放在复合索引右侧，它会让范围查询失效，还加剧页分裂 - 若业务允许，用
hashed索引替代等值查询字段（如db.logs.createIndex({ traceId: "hashed" })），能打散写入热点 - 对写密集型集合，考虑关闭
journal（仅限非关键日志类数据），或调大wiredTiger.engineConfig.cacheSizeGB减少刷盘频次
分片环境下，写放大会被 mongos 层面二次放大
在分片集群中，一次 insert 或 update 请求，mongos 会根据分片键路由到目标 shard；但每个 shard 上的索引写入仍独立发生 B-Tree 分裂。更关键的是：如果索引字段与分片键不一致（例如分片键是 { userId: 1 }，但查询常用 { createdAt: -1, _id: 1 }），那么所有 shard 都要维护该索引，写流量被复制到每个 shard，物理写 IO 成倍增加。
典型表现：单个 shard 的 diskWriteOps 监控值远高于其他指标，且 sh.status() 显示 chunk 迁移频繁——说明索引写入压力正在反向影响分片均衡。
- 优先让高频查询字段与分片键对齐，减少跨 shard 索引维护
- 对只读历史集合，启用 TTL 索引（
{ expireAfterSeconds: ... }）比定期delete更轻量，因为 TTL 是后台线程异步清理，不参与主写路径 - 不要在分片集合上建全局唯一索引（如
{ username: 1, unique: true }），它强制所有写请求走mongos协调，写延迟陡增
如何判断你正被写放大拖慢
最直接的信号不是 CPU 或内存告警，而是 WiredTiger 存储引擎层的指标异常。登录 mongod 所在机器，执行：
db.serverStatus().wiredTiger.cache
重点关注这几个字段：
-
bytes currently in the cache接近maximum bytes configured→ 缓存不足，频繁刷盘 -
pages written from cache/pages read into cache比值持续 > 0.3 → 写入引发大量脏页写出 -
modified pages evicted非零且增长快 → 页面被强制踢出缓存前未及时刷盘，IO 延迟已堆积
这时候加索引或调参数都收效甚微，真正要做的，是砍掉低效索引（用 db.collection.getIndexes() + db.collection.stats() 查使用率），或把写负载拆到不同集合（如热消息进 messages_recent，冷归档进 messages_archive）。
写放大没有银弹解法，它本质是用磁盘空间和写 IO 换取查询效率的权衡结果。最容易被忽略的一点是：索引是否真的被查询用到了？别让没人在意的索引，在后台默默撕裂你的磁盘IO队列。
