大文档不触发分片迁移但加剧跨机房带宽压力，因snappy仅压缩shard间流量且对长字符串/二进制压缩率低，mongos聚合时反复搬运整文档而非按需投影，oplog和config同步也受拖累；拆分须匹配访问模式，优先分离高频更新字段或采用主-明细模型，并通过应用层停写迁移、强制投影、就近mongos等手段优化。
大文档本身不触发分片迁移，但会显著放大跨机房带宽压力——尤其在 chunk 迁移、oplog 同步和 mongos 聚合合并阶段。
为什么大文档会让网络传输变卡
MongoDB 6.0 的 snappy 压缩只对 shard-to-shard 流量生效，且对长字符串、二进制字段（如 Base64 图片、日志文本）压缩率极低；一个 8MB 的文档迁移时实际传输可能达 6～7MB，远高于小文档的压缩收益。更关键的是：mongos 在聚合结果合并、$lookup 跨分片关联、甚至某些广播查询中，会把整份大文档反复搬运，而不是按需投影。
- 单文档超过 128KB 时，
db.collection.stats().avgObjSize输出值已预警潜在风险 - oplog 备份回档场景下，大文档导致 oplog.wt 文件体积暴涨（某游戏实例 oplog 占比达 70%），间接推高跨机房同步流量
- 分片键若含大字段（如嵌套 JSON 日志），会导致 chunk 路由元数据膨胀，config server 同步延迟上升
拆分策略必须匹配访问模式，不能只按大小切
盲目按字段拆成多个 collection 容易破坏事务边界和应用语义。优先判断读写热点：
- 若大文档中只有少数字段高频更新（如
status、lastModified），把它们保留在主 collection，其余归档到collection_name_archive，用 ObjectId 关联 - 若存在固定子结构（如电商订单中的
items数组），改用「主-明细」模型：主 doc 存订单头，明细存独立 collection，分片键设为{orderId: 1, itemId: 1}实现局部性 - 若文档含大量只读历史数据（如用户操作日志），提取为
user_logs并启用 TTL 索引自动过期，避免长期占用 chunk 空间
实操时绕开 MongoDB 6.0 的两个硬限制
MongoDB 6.0 不支持在运行中修改分片键，也不允许对已分片集合执行 reShardCollection（该命令 5.0 引入但 6.0.3+ 已废弃）。所以拆分必须是应用层行为：
- 停写窗口内，用
mongoexport+mongoimport拆分存量数据，注意保留_id和分片键一致性 - 新写入路径切到新 schema，通过应用双写或 CDC 工具（如 Debezium）同步旧数据，避免直接操作 config 数据库
- 禁用自动 split：
sh.disableAutoSplit()在 6.0.3+ 无效果，但可防止 balancer 因大文档导致的误判迁移——改用sh.splitAt()手动控制 chunk 边界 - 验证拆分效果：对比拆分前后
db.serverStatus().metrics.operation.moveChunk.bytesSent，下降应 >40%
容易被忽略的压缩盲区
即使你把文档从 10MB 拆成 10 个 1MB，snappy 仍不会压缩客户端到 mongos 的流量。如果应用直连 mongos 查询并返回完整文档，带宽瓶颈仍在原地。真正要做的不是“让传输变小”，而是“让传输变少”：
- 所有查询强制加
.project()，只取必要字段，避免{}全量返回 - 聚合管道前置
$limit和$skip，防止mongos合并时搬运冗余数据 - 对含大字段的 collection，单独部署就近
mongos实例（同机房），减少跨机房往返
