查询与更新性能：选择高效的写操作

MongoDB 的写性能不仅关乎服务器接受数据的速度。它还涉及写入的形状、必须维护的索引、所触及的文档、客户端等待的确认，以及同一记录是否同时被大量请求冲击。

读取和写入的失败方式不同。糟糕的读取通常扫描过多数据。糟糕的更新可能先扫描，然后重写一个不断增长的文档，更新多个索引，等待复制，并阻塞其他对同一热点记录的操作。这就是为什么选择正确的写操作至关重要。

核心权衡：读取速度 vs. 写入持久性

在任何数据库系统中，确保数据安全（持久性）和实现高事务速度（吞吐量）之间都存在固有的矛盾。MongoDB 通过两种与写性能相关的主要机制来管理这一点：写关注 和写操作本身的类型（例如，简单插入与复杂更新）。

理解写关注

写关注定义了应用程序在认为写操作成功之前，需要 MongoDB 提供的确认级别。更严格的写关注会增加持久性，但通常会降低写入吞吐量，因为客户端必须等待更长时间的确认。

写关注级别	描述	持久性	延迟/吞吐量影响
`0`（即发即忘）	无需确认。	最低	最高吞吐量，最低延迟
`majority`	写入被副本集大多数成员确认。	高	中等延迟，良好吞吐量
`w: 'all'`	写入被副本集所有成员确认。	最高	最高延迟，最低吞吐量

实际示例：设置写关注

插入文档时，在驱动程序级别设置写关注：

const options = { writeConcern: { w: 'majority', wtimeout: 5000 } };

db.collection('logs').insertOne({ message: "Critical Event" }, options, (err, result) => {
  // 操作仅在大多数成员确认后完成
});

最佳实践： 对于高容量日志或非关键数据（偶尔丢失可容忍），使用 w: 0 可以减少确认延迟，但存在非正常关闭时数据丢失的风险。

查询性能特征

读取（查询）通常不会影响持久性，只专注于检索速度。查询性能主要受以下因素影响：

索引： 适当的索引是最重要的因素。命中索引的查询几乎总是优于集合扫描。
数据检索大小： 获取更少的字段或更小的文档可以加快网络传输和内存使用。
查询复杂度： 聚合管道，尤其是涉及 $lookup（连接）或大量 $group 操作的管道，需要大量的 CPU 时间和内存，影响服务器的整体响应能力。

示例：高效的查询结构

始终优先使用查询谓词中的索引字段：

// 假设 'status' 字段已索引
db.items.find({ status: 'active', lastUpdated: { $gt: yesterday } }).limit(100);

更新性能影响

更新本质上是写操作，并且与插入一样受到持久性考虑的影响。然而，更新根据是否修改文档结构或大小而引入了复杂性。

原地更新 vs. 重写

MongoDB 尽可能尝试原地执行更新。原地更新更快，因为文档在磁盘上的位置不会改变。这可能在以下情况下实现：

更新的字段不会导致文档超过其当前分配的存储空间。
更新操作不会以需要内部重组的方式更改文档大小。

如果更新导致文档增长超过其当前分配的空间，MongoDB 必须将文档重写到磁盘上的新位置。此重写操作会产生大量的 I/O 开销，并长时间锁定文档，从而严重降低性能，尤其是在高并发场景中。

最小化重写

为了优化更新：

预分配空间： 如果你知道某些字段会显著增长（例如，向数组添加元素），考虑用占位数据初始化这些字段，以保留足够的初始空间。
避免过度更新： 如果文档频繁调整大小，考虑重构模式，使用通过引用链接的独立、更小的文档。

更新修饰符与速度

不同的更新操作符具有不同的性能成本：

原子操作（$set, $inc）： 如果导致原地更新，这些通常很快。
数组操作（$push, $addToSet）： 如果由于数组增长而反复导致文档重写，这些可能特别慢。
文档替换（replaceOne）： 替换整个文档（replaceOne 或使用 { upsert: true, multi: false } 配合覆盖整个文档的 findAndModify）会强制重写，应谨慎使用，因为它会使指向旧位置且可能需要更新的现有索引失效。

比较查询与写入性能

虽然查询通常比写入快，因为它们避免了持久性开销，但比较是微妙的：

操作类型	主要性能驱动因素	持久性开销	最坏情况
查询（读取）	索引效率，网络延迟。	无（除非从过时的副本读取）。	由于缺少索引而进行全集合扫描。
更新（写入）	写关注确认，原地 vs. 重写。	高（取决于 `w` 设置）。	跨集群频繁的文档重写。

可操作的见解： 如果你的应用程序受写入限制，首先检查更新过滤器、热点文档、文档增长和索引维护。写关注是一个有用的杠杆，但降低持久性应该是一个产品决策，而不是本能反应。

选择写入形状，而不仅仅是写关注

写关注控制 MongoDB 何时告知客户端写入已被确认。它不能修复低效的更新模式。两个写入可以使用相同的 w: "majority" 设置，但成本可能非常不同，因为一个触及小字段，而另一个不断增长热点文档中的大数组。

一个常见的例子是用户文档中不断增长的 events 数组：

db.users.updateOne(
  { _id: userId },
  { $push: { events: { type: "login", at: new Date() } } }
)

起初这很方便。后来，用户文档变得很大，每次登录都会更改同一个文档，更新开始与用户配置文件的读取竞争。更好的模型通常是单独的 user_events 集合：

db.user_events.insertOne({
  userId,
  type: "login",
  at: new Date()
})

现在配置文件文档保持较小，事件写入追加新文档，而不是反复修改一个不断增长的文档。你可以为最近活动屏幕索引 { userId: 1, at: -1 }，如果数据不是永久性的，可以使用 TTL 索引过期旧事件。

另一种模式是计数器。如果每个请求递增一个全局文档，该文档就会成为写入热点：

db.metrics.updateOne(
  { _id: "page_views" },
  { $inc: { count: 1 } },
  { upsert: true }
)

对于低流量，这没问题。在高流量下，使用分桶计数器，例如每分钟、每个租户、每个路由或每个分片键一个文档。你牺牲一点读取时的聚合，换取更好的写入分布。

db.metrics.updateOne(
  { metric: "page_views", minute: "2026-05-24T10:31Z" },
  { $inc: { count: 1 } },
  { upsert: true }
)

Upsert 需要特别小心。Upsert 必须首先找到匹配的文档。如果过滤器没有索引，写入路径就会变成读取扫描加上写入。例如，对于幂等的支付回调，你需要一个唯一索引键：

db.payment_events.createIndex({ providerEventId: 1 }, { unique: true })

db.payment_events.updateOne(
  { providerEventId },
  { $setOnInsert: { providerEventId, receivedAt: new Date(), payload } },
  { upsert: true }
)

这使得重试安全，无需扫描集合或创建重复记录。它还提供了一种干净的方式来处理重复键竞争。

批量写入是另一个有用的杠杆。如果你要导入 10,000 个状态更改，每次更新一次网络往返通常是浪费的。bulkWrite 允许你发送一个批次，无序批次可以在单个失败后继续，如果这对任务可接受的话。

db.orders.bulkWrite(
  updates.map(({ id, status }) => ({
    updateOne: {
      filter: { _id: id },
      update: { $set: { status, updatedAt: new Date() } }
    }
  })),
  { ordered: false }
)

不要盲目放松写关注以追求速度。从 majority 切换到 w: 1 可能会减少延迟，但也会改变故障转移期间可能发生的情况。切换到 w: 0 意味着客户端可能根本不知道写入是否失败。这对于一次性遥测数据可能是可以接受的。但对于订单、账户更改或用户期望看到确认的任何内容来说，这是一个糟糕的选择。

更好的问题是：你能让写入更小、更有针对性、更少争用、更容易重试吗？当只有一个字段更改时，使用 $set, $inc, $unset 和 $setOnInsert 而不是替换整个文档。将无界数组排除在频繁更新的文档之外。为更新过滤器添加索引，而不仅仅是为读取过滤器。围绕唯一键设计重试，以便重复请求不会产生重复效果。

测量写入性能而不自欺欺人

将小文档插入空本地数据库的基准测试并不能告诉你太多关于生产写入性能的信息。真实的写入与索引、复制、日志记录、后台工作和其他客户端竞争。如果你正在测试更新密集型路径，请针对看起来像真实文档的文档和与生产匹配的索引运行测试。

至少跟踪四个指标：应用程序延迟、MongoDB 命令持续时间、复制延迟以及写入错误或超时。一个改善平均延迟但产生复制延迟的更改可能只是将问题转移到了从节点。一个使用 w: 1 看起来很快的更改可能无法满足产品实际需要的持久性要求。

索引是写入成本的一部分。每次更改索引字段的插入或更新都必须更新相关的索引条目。这并不意味着索引不好；这意味着未使用的索引不是免费的。如果一个集合在多年的功能开发中创建了许多索引，请检查它们是否仍然支持真实的查询。删除未使用的索引可以提高写入速度并减少存储，但在检查查询日志并测试回滚计划后，请谨慎操作。

为常见应用程序任务选择操作

对于配置文件编辑表单，使用 $set 更新用户更改的字段。不要用过时的客户端副本替换整个用户文档，因为这可能会意外擦除由另一个进程添加的字段。

对于库存预留，使用条件更新，以便检查和更改同时进行：

db.inventory.updateOne(
  { sku, available: { $gte: quantity } },
  { $inc: { available: -quantity, reserved: quantity } }
)

然后检查 matchedCount 和 modifiedCount。这避免了两个客户端读取相同的可用数量并都决定可以预留的竞争。

对于软删除，使用 $set 设置 deletedAt 字段，并确保正常读取过滤掉它。如果你经常查询活动记录，请将该字段包含在相关索引中。对于批量硬删除，分批删除，以免创建长时间运行的操作干扰其他工作负载。

对于后台迁移，优先选择带有检查点的小批次。单个大规模的 updateMany 可能很简单，但它可能会产生复制压力并使回滚更加困难。一次更新 1,000 或 5,000 个文档、记录进度并在复制延迟上升时休眠的迁移不那么引人注目，通常也更安全。

这些案例的模式是相同的：让数据库执行一个精确的原子更改，使重试安全，并避免永远增长热点文档。

实用的结束语：性能调优策略

在 MongoDB 中选择高效的写操作取决于将应用程序需求与数据库能力对齐。高持久性要求（使用 w: 'all'）本质上比高吞吐量要求（使用 w: 0）慢。同时，开发人员必须防止由于更新超出分配存储而导致文档在磁盘上重写而造成的性能下降。

通过根据数据关键性仔细选择写关注，并构建更新以支持原地修改，你可以有效地平衡稳健的数据持久性与现代应用程序的高并发需求。