MongoDB运行批量迁移脚本时更新延迟、性能骤降问题咨询

AI 小北

2026-8-30

问题根因

两类异常本质是脚本逻辑缺陷+MongoDB存储引擎特性共同导致的，不存在所谓的“调度延迟延后执行更新”：

性能暴跌的核心原因
- 聚合管道顺序写反：当前逻辑每次拉取批次先执行全表$sort，再做_id范围匹配。_id字段自带升序唯一索引，先匹配范围的话索引直接返回有序结果，根本不需要排序；前期数据量小的时候WiredTiger缓存能扛住全表排序开销，随着更新量上涨，缓存脏页占比升高，每次拉取300条数据都要扫描大量无效数据，IO开销直接飙升。
- 逐条单文档更新效率极低：每条更新单独走网络往返、单独申请写锁、单独刷写WAL日志，随着写请求堆积，存储引擎的锁排队、刷盘队列越来越长，单条更新的响应时间会持续升高，性能自然出现量级下跌。
日志显示更新成功但count长时间不涨的原因
- 日志判断逻辑错误：绝大多数PHP MongoDB驱动的update()方法返回值代表更新请求被服务端接收确认，不是数据已经落盘、对查询可见。大量写请求堆在MongoDB写队列里的时候，驱动收到接收确认就会打成功日志，但实际数据还没完成提交。
- count统计不准：WiredTiger引擎下默认的count()读取的是存储引擎的统计快照，不是实时遍历数据的精确结果，写压力大的时候快照是批量提交的，就会出现数分钟数值不动、一次性跳涨数千条的现象。
额外的逻辑隐患：循环终止条件用的是脚本启动时计算的总文档数，迁移过程中如果有数据增删，会出现漏处理或者重复处理；$lastIdInBatch在整批文档拉取完成后才更新，如果批次中途报错，重启后会重复拉取已处理数据。

优化方案

按优先级从高到低调整：

修正批次拉取逻辑
去掉冗余的$sort阶段，把$match范围过滤放在管道最前面，直接命中_id索引拉取有序数据，拉取开销可以降到原来的1%以下。管道逻辑调整为：

$aggregation = [
    [
        '$match' => [
            '_id' => ['$gt' => new ObjectId($lastIdInBatch)]
        ]
    ],
    ['$limit' => $chunkSize]
];

替换逐条更新为批量写
不要逐文档发送更新请求，用bulkWrite做无序批量写，每批拉取的文档攒完更新条件后一次性发给MongoDB，合并网络往返、锁申请、日志刷盘的开销，写性能可以提升5-10倍。核心逻辑示例：

$bulk = new MongoDB\Driver\BulkWrite(['ordered' => false]);
$toUpdateCount = 0;
foreach ($documents as $document) {
    // 字段判断逻辑
    if (!empty($changes)) {
        $bulk->update(
            ['_id' => $document['_id']],
            ['$set' => $changes]
        );
        $toUpdateCount++;
    }
}
if ($toUpdateCount > 0) {
    // 一次性执行批量写，写关注设为w:1即可，不需要等多数节点确认
    $this->connection->collection('collection')->raw()->executeBulkWrite($bulk, new MongoDB\Driver\WriteConcern(1));
    Log::info("batch updated", ['count' => $toUpdateCount, 'last_id' => $lastIdInBatch]);
}

进一步简化更新逻辑（如果判断规则简单）
如果你的更新逻辑只是“字段不存在则设默认值”这类简单规则，完全不需要把文档拉到应用层判断，直接在更新语句里加过滤条件，在MongoDB侧完成匹配和更新，省掉文档传输的开销，性能还能再提一个量级。示例：

// 按_id范围直接更新，不需要拉取文档
$collection->updateMany(
    [
        '_id' => ['$gt' => new ObjectId($lastIdInBatch)],
        'deleted_at' => ['$exists' => false]
    ],
    ['$set' => ['deleted_at' => null]],
    ['upsert' => false]
);

配套参数调整

批次大小从300调整到1000-2000，只要单批请求不超过MongoDB 16MB的单请求限制即可，充分发挥批量写的优势。
不要在迁移过程中反复执行count()统计进度，直接记录当前处理到的最后一个_id，按_id范围估算进度即可，避免count操作额外占用IO资源。
如果是副本集部署，迁移脚本优先连接从节点读数据，把主节点资源全部留给写操作，避免读写争抢资源。
增加简单流控：如果单批写的响应时间超过200ms，主动sleep 100-500ms，不要无限制向MongoDB堆写请求，避免打满写队列导致全库性能雪崩。

内容的提问来源于stack exchange，提问作者Bogdan Dubyk