MongoDB 逐条与批量更新的性能记录

ailx10说：这篇是我2024年4月写的。项目里的 start_time 原先用 datetime，后来要换成整数时间戳，数据库里已有的数据也得跟着刷。事情本来很日常，真正跑起来才发现，逐条 update_one 和一次 bulk_write，耗时差得挺明显：几千条、几万条我都记了对应时间。顺着这次迁移，我又补了索引的例子，于是写成一篇小性能记录。它没有复杂测试框架，就是从一次必须完成的数据更新里顺手多问了一句“换个写法会怎样”，再把当时机器上测到的结果留下。

---

一次历史测试将文档中的 start_time 从日期时间转换为毫秒时间戳，比较逐条 update_one 与批量 bulk_write。在该次环境中，7,000 条数据分别约需 267 秒和 7 秒；30,000 条分别约需 1,214 秒和 33 秒。结果反映该次实验条件，不能作为所有 MongoDB 部署的性能保证。

为什么批量操作可能更快

逐条更新通常产生更多往返；批量写入可合并多个操作。但吞吐量也取决于网络延迟、索引、写关注、文档大小、服务器负载和批次大小。原测试没有完整记录这些参数，也没有测量索引带来的影响。

迁移时要考虑的细节

• 先备份，在隔离副本上验证转换结果和应用兼容性；时间字段类型的变化可能影响已有查询和索引。
• 明确时间戳单位、UTC 与时区处理方式。对没有时区信息的 Python datetime，不要在未确认其含义时直接假定本地时区或 UTC。
• 分批构造并提交更新，避免把整张表的写操作无限累积在内存中；记录失败项和进度，考虑重试与并发更新。
• 验证数据库中整数类型及取值范围，并针对实际查询使用执行计划评估索引，而不是认为创建任意索引都会提高所有查询性能。

原文代码使用本地 MongoDB 示例连接，但未给出可复现实验数据；本文保留测量结果和方法边界，不把该代码作为未经验证的生产迁移脚本。

那次测量说明批量写入在原环境里明显省时，却不能直接变成所有项目的倍数。把批大小、时间戳和测试条件一起留下，后来遇到慢更新时，才知道从哪里重新量起。

本文摘要与文字整理有 AI 参与。