maxTimeMS对moveChunk无效，真正起作用的是Balancer的超时控制和chunkSize、migrationChunkSize、activeWindow等配置；需连具体shard查currentOp定位迁移压力。
☞☞☞☞点击夸克ai手把手教你，操作像呼吸一样简单！☜☜☜☜☜
maxTimeMS 对分片迁移没用，别往 moveChunk 里塞
很多人看到 maxTimeMS 就想当然地以为它能限制 moveChunk 操作耗时，实际完全无效。MongoDB 的分片迁移（moveChunk）是内部管理操作，不接受客户端传入的 maxTimeMS 参数——无论你在 mongosh、驱动或聚合管道里怎么设，它都不会生效。
真正起作用的是均衡器（Balancer）自身的超时控制和配置项，比如 chunkSize 和迁移窗口。如果你发现某次迁移卡住十几分钟，不是超时没设，而是迁移本身被阻塞了（比如目标 shard 磁盘满、网络抖动、源 shard 正在 compaction）。
调整 migrationChunkSize 控制并行迁移数
这是影响业务抖动最直接的开关。默认值是 1，即每次只迁移一个 chunk；调高后可并行迁移多个 chunk，加快整体进度，但会显著增加网络和磁盘 I/O 压力。
- 设为
1：最保守，对业务影响最小，但迁移周期拉得极长 - 设为
3~5：生产常用折中值，需配合监控config.changelog中单 chunk 迁移耗时 - 超过
8：容易触发 mongos 负载飙升，尤其当集群已有大量未完成迁移时
修改方式（通过 mongos 执行）：
db.getSiblingDB("config").settings.update(
{_id: "balancer"},
{$set: {migrationChunkSize: 3}},
{upsert: true}
)设置 activeWindow 避开业务高峰
均衡器默认全天候运行，但你完全可以把它关进“笼子”。activeWindow 是唯一能真正隔离业务时段的机制，它让 Balancer 只在指定时间窗口内启动迁移任务。
- 窗口必须用 24 小时制字符串，如
"start":"02:00","stop":"06:00" - 不能跨天（比如
"23:00"到"01:00"会报错），需拆成两个窗口或用凌晨时段 - 窗口外即使有数据倾斜，Balancer 也不会触发任何迁移，避免半夜把 CPU 打满
注意：activeWindow 不影响已开始的迁移，只控制新任务的调度时机。
块大小（chunkSize）才是迁移节奏的底层杠杆
chunkSize 默认 64MB，它决定了每个迁移单元的数据量。这个值直接影响三件事：迁移单次耗时、网络传输压力、config server 元数据膨胀程度。
- 写密集场景（如日志类集合）：建议调小到
32，缩短单次迁移时间，降低卡顿感知 - 读密集且文档大（如含 base64 图片）：保持
64或略增到96，减少跨 shard 查询次数 - 绝对不要低于
16：会导致 config server 元数据暴增，查询路由变慢
改完后不会立即生效，只影响后续新 chunk 的拆分；已有 chunk 仍按旧 size 迁移，除非手动 sh.splitAt() 强制拆分。
真正难的不是调参数，而是判断哪台 shard 正在扛着迁移压力——db.currentOp({secs_running: {$gt: 30}}) 在 mongos 上查不到迁移操作，必须连到具体 shard 节点上执行，这点很容易漏掉。
