应使用$lookup+$merge而非forEach+updateOne，因后者性能差、无原子性、无法利用索引和聚合优化；$merge支持upsert且需on字段为唯一索引，跨库需配合getSiblingDB或分步处理，并注意$unwind空数组问题。
不能直接用 SQL 那种 UPDATE ... JOIN 语法，但有可靠、可批量、可原子化的做法——核心是 $lookup + $merge，不是遍历 + updateOne。
为什么不用 forEach + updateOne？
这类脚本（比如 db.A.find().forEach(...)）在数据量稍大时会明显变慢、容易超时，且无法保证原子性：中间失败会导致部分更新、部分没更新。更麻烦的是，它绕过了聚合管道的优化能力，也无法利用索引高效匹配。
- 每次循环都要单独查一次集合 B，网络往返开销翻倍
- 没有事务保障（即使开启 multi-document transaction，也要手动 wrap）
- 无法利用
localField/foreignField上已有的索引加速关联 - 写法冗长，出错难定位（比如
merchant.hasNext()拼错成hasNext就静默失败）
$merge 是跨集合更新的正确入口
$merge 是 MongoDB 4.2+ 引入的聚合阶段，专为“把聚合结果写回目标集合”设计。它天然支持 upsert 行为，且整个 pipeline 可以被优化执行。
典型场景：用 orders 关联 users，把用户等级写入订单文档：
db.orders.aggregate([
{ $lookup: {
from: "users",
localField: "user_id",
foreignField: "_id",
as: "user_doc"
}
},
{ $unwind: "$user_doc" },
{ $addFields: { "user_level": "$user_doc.level" } },
{ $project: { user_doc: 0 } },
{ $merge: {
into: "orders",
on: "_id",
whenMatched: "replace",
whenNotMatched: "discard"
}
}
])
-
whenMatched: "replace"替换整条文档（慎用）；"merge"则只合并字段（推荐） -
on: "_id"必须是目标集合的主键或唯一索引字段，否则报错 - 如果目标集合不存在，
$merge不会自动创建，需提前建好
跨数据库更新要用 db.getSiblingDB()
当两个集合不在同一数据库时（比如 system_logging.woplus_tservice 和 base_data.mobile_segment），不能直接写 from: "mobile_segment"。
必须用 db.getSiblingDB("base_data").mobile_segment 构造集合引用，但注意：$lookup 的 from 参数不接受这种表达式 —— 所以得换路子：
- 先切到源库：
use base_data，再运行聚合，把结果$out到临时集合 - 切回目标库：
use system_logging，再用$lookup关联那个临时集合 - 或者，用 application 层做两次查询 + 批量
updateMany（适合中小数据量，逻辑可控）
硬要在 shell 里单次完成？只能靠 db.getSiblingDB("base_data").mobile_segment.find() 全量拉数据进内存，再用 bulkWrite 更新 —— 这就又回到内存和性能权衡的老问题了。
容易忽略的坑：$unwind 和空数组
$lookup 总是返回数组（哪怕只匹配一条），所以后续想取字段必须 $unwind。但一旦某条记录没关联上，user_doc 就是空数组，$unwind 会丢弃整条文档。
解决办法是加 preserveNullAndEmptyArrays: true：
{ $unwind: { path: "$user_doc", preserveNullAndEmptyArrays: true } }
- 这样没匹配上的记录会保留，
user_doc为null，后续可用$ifNull设默认值 - 别漏掉这个参数，否则你以为“全量更新”，其实悄悄过滤掉了无关联数据
真正复杂的跨集合更新，往往卡在数据一致性判断和空值处理上，而不是语法本身。
