MongoDB中仅修改特定字段却替换整个文档是否存在性能损耗？

性能损耗对比 #

• 数据传输量差异：替换整个文档时，客户端得把完整的文档数据发给MongoDB服务端，而用$set这类更新操作符只需要传输要修改的字段和对应值。要是文档体积较大（比如包含大文本、复杂嵌套结构），替换操作会产生多得多的网络IO，直接拖慢操作速度。
• 磁盘写入开销：MongoDB的WiredTiger存储引擎会对写入操作做快照和日志记录，替换整个文档相当于写入完整的新文档，磁盘写入量远大于仅更新单个字段的情况。尤其是当文档尺寸超过默认16KB页大小时，还可能触发更多页拆分和写入放大，进一步增加开销。
• 文档重建代价：替换操作会销毁原文档再创建新文档，过程中需要重新处理所有字段的校验、BSON序列化/反序列化；而局部更新只处理目标字段，CPU开销低很多。

索引更新的耗时差异 #

• 索引更新范围：如果替换的文档里只有部分字段是索引字段，那替换操作和局部更新的索引耗时差异不大——MongoDB只会更新有变化的索引字段。但要是替换操作修改了更多索引字段，或者原文档的索引字段全被替换，索引更新的工作量就会变大，耗时自然更长。
• 极端场景影响：如果文档有多个复合索引或包含大字段的索引，替换整个文档时，哪怕只有一个索引字段变化，理论上和局部更新的索引操作一致，但如果替换导致文档物理存储位置变化（比如文档变大触发迁移），会额外增加索引维护开销，因为索引条目得指向新的存储位置。

实际开发建议 #

• 除非要替换文档的大部分字段，或者必须重置整个文档结构，否则优先使用$set、$inc这类局部更新操作符，能显著降低IO和CPU负载。
• 对于频繁更新的小字段，局部更新的性能优势特别明显，能有效减轻数据库压力。
• 如果必须替换整个文档，尽量保证文档尺寸变化不大，避免触发文档迁移和大量页写入操作。

内容的提问来源于stack exchange，提问作者Bear Bile Farming is Torture