大Key无法被分片自动拆分，必须Schema层主动优化：拆分为子集合或外存引用。因分片以完整文档为单位迁移，超16MB文档会导致moveChunk失败、均衡器阻塞、查询性能骤降。
大Key（如单文档超16MB、嵌套过深、数组超万级）在分片集群中不会被自动拆分，反而会卡死块迁移、拖慢均衡器、阻塞查询路由——必须靠Schema层主动拆分，不能依赖分片机制。
为什么分片不解决大Key问题
分片按shard key切分数据，但每个chunk仍以完整文档为单位存储和迁移。MongoDB对单文档有16MB硬限制，且WiredTiger引擎在处理超大文档时：内存拷贝开销剧增、journal写入变慢、压缩率下降、索引更新延迟升高。更关键的是，moveChunk操作要求整个文档能被序列化传输，一旦文档过大，迁移直接失败并报错Failed to serialize document for migration。
- 分片键再合理，也无法把一个15MB的
log_entries数组“切开”存到不同分片 - 均衡器看到这个chunk长期无法迁移，会反复重试，占用
config.shards锁 - mongos路由该查询时，必须拉取整份大文档再做投影，网络和CPU双吃紧
Schema优化：用子集合替代嵌套大数组
把高频增长、体积不可控的字段（如用户行为日志、设备上报点位、评论列表）抽离成独立集合，用user_id或device_id作为关联字段，同时复用原分片键保证局部性。
- 原结构（危险）：
{_id: ..., user_id: "U1001", logs: [{ts: ..., data: ...}, ...] /* 5000+项 */} - 优化后结构：
users集合只存轻量元数据；user_logs集合按{user_id: 1, ts: -1}分片，单文档严格控制在100KB内 - 查询时用应用层join或聚合管道
$lookup（注意let/pipeline写法避免全表扫描）
示例迁移脚本（一次性拆分）：
db.users.find({logs: {$exists: true, $ne: []}}).forEach(function(u) {
db.user_logs.insertMany(
u.logs.map(function(log) {
return {user_id: u.user_id, ts: log.ts, data: log.data};
})
);
db.users.updateOne({_id: u._id}, {$unset: {logs: ""}});
});
大文档字段的替代方案：二进制外存 + 引用
对真正无法拆解的超大字段（如原始图片、音视频metadata、PDF解析文本），放弃存入MongoDB，改用对象存储（OSS/S3），MongoDB只存引用信息和摘要。
- 存：
{_id: ..., media_ref: "oss://bucket/uuid.jpg", md5: "a1b2c3...", size: 12489024} - 查：应用先读MongoDB获取
media_ref，再直连OSS下载；必要时用text索引加速摘要搜索 - 优势：规避16MB限制、降低WiredTiger缓存压力、避免因单文档过大导致
cacheSizeGB配置失效
容易被忽略的细节
即使做了Schema拆分，仍需同步调整分片策略：子集合的分片键必须与主集合强关联（如都含user_id），否则跨分片$lookup会退化为scatter-gather；另外，user_logs这类写多读少的集合，建议启用zstd压缩和关闭journal（若可接受秒级丢失）。
