db.collection.update()默认只更新第一条匹配文档是设计使然，并非bug；需用updatemany()批量更新，或结合sort()+limit()+$in确保有序批量修改。
db.collection.update() 默认只改一条，不是 bug 是设计
MongoDB 的 update() 命令（非 updateMany()）默认行为就是只修改第一个匹配文档。这不是遗漏或错误，而是早期 Shell API 的历史约定。即使你传了 { status: "pending" } 这种明显能匹配多条的条件，它也只动第一条。
所以别急着查网络连接或驱动版本——先确认你调用的是哪个方法。老式写法 db.users.update({age: {$gt: 30}}, {$set: {flag: 1}}) 永远只生效一次；而 db.users.updateMany(...) 才是批量更新的正解。
用 find().limit(N).forEach() 更新前 N 条，但要注意原子性缺失
这种模式常见于需要“取一批、改一批、不锁全表”的场景，比如分批修复数据、灰度发布字段变更。它本质是两阶段操作：先 find() 拿 ID 列表，再对每个 _id 单独发 updateOne()。
示例（Shell）：
db.user.find({status: 0, country: "CN", group: "default"}).limit(50).forEach(function(doc) {
db.user.updateOne({_id: doc._id}, {$set: {group: "free"}});
});
- ✅ 能精确控制数量（
limit(50)真的只处理 50 条） - ❌ 不是原子操作：中间如果有新文档插入/删除，或其它进程并发修改，
find结果和后续updateOne执行时的状态可能不一致 - ❌ 性能差：50 次 round-trip，比单次
updateMany()慢一个数量级 - ⚠️ 注意：不要在
forEach里用save()，它会覆盖整个文档，丢失未读取字段
updateMany + $in 是更稳的“前 N 条”替代方案，但需先查 ID
如果业务允许“先查 ID、再批量更新”，这是比 forEach 更可靠的选择。关键点在于：用 find().limit(N).map() 提前拿到目标 _id 数组，再喂给 $in。
Shell 示例：
var ids = db.user.find({status: 0, country: "CN", group: "default"}, {_id: 1})
.limit(50)
.map(function(doc) { return doc._id });
db.user.updateMany(
{ _id: { $in: ids } },
{ $set: { group: "free" } }
);
- ✅ 只有两次请求：一次 fetch ID，一次 bulk update
- ✅
updateMany是原子操作（对每条匹配文档独立原子，但整体不跨文档事务） - ⚠️
$in数组长度有上限（BSON 16MB 限制），超 10 万 ID 就得拆批次 - ⚠️ 如果原始查询条件本身不稳定（如时间范围动态变化），两次操作间可能漏掉或重复
真正想“按顺序更新前 N 条”，必须靠 sort + limit + updateMany 组合
上面所有方法都隐含一个前提：你没指定顺序。MongoDB 的 find().limit() 不保证顺序，除非显式加 sort()。否则“前 50 条”每次执行结果都可能不同。
正确姿势（例如按注册时间升序取最早 50 个）：
db.user.find({status: 0, country: "CN", group: "default"})
.sort({createdAt: 1})
.limit(50)
.map(function(doc) { return doc._id });
// 然后同上用 $in + updateMany
- ✅ 显式
sort()是可控性的底线，否则“前 N 条”毫无意义 - ⚠️
sort()字段必须有索引，否则全表扫描，limit 失效且极慢 - ⚠️ 复合查询 + sort + limit 的组合，索引设计要覆盖全部字段（如
{status: 1, country: 1, group: 1, createdAt: 1}）
最易被忽略的一点：没有 sort 的 limit 在分布式分片集群中行为更不可控——不同 shard 返回的“前 N 条”完全独立，最终结果是随机拼凑的。真要批量限流更新，顺序和索引不是可选项，是必选项。
