如何避免MongoDB文档大小超过16MB限制的设计建议

直接写入超16MB文档会报错“Payload document size is larger than maximum of 16MB”或BsonMaximumSizeExceededException，这是MongoDB底层BSON协议的硬性拦截，请求在网络层即被拒绝；GridFS虽可存储大文件，但fs.files和fs.chunks结构固定、不可索引且不支持聚合操作，必须通过独立元数据集合（含file_id关联fs.files._id）承载可查询字段并建索引，才能实现聚合、排序等业务查询。

直接写入超16MB文档会报什么错

遇到 Payload document size is larger than maximum of 16MB 或 BsonMaximumSizeExceededException，说明你正试图插入或更新一个超限文档——这不是配置问题，也不是驱动 bug，而是 MongoDB 底层 BSON 协议的硬性拦截。它会在网络层就拒绝请求，根本不会进入存储引擎。

GridFS 存完大 JSON 后为什么聚合查不了内容

GridFS 把文件切进 fs.files（元信息）和 fs.chunks（二进制块），这两个集合结构固定、字段不可索引：

• fs.files.filename 是字符串，但默认没建索引；uploadDate 是 ISODate，也不含业务语义字段（如 deviceId、status）
• fs.chunks.data 是 BinData 类型，聚合管道里连 $match 都不支持，更别说 $group 或 $sort
• 对 fs.chunks 执行聚合会直接报错：errmsg: "cannot use $group in fs.chunks" —— 这是设计限制，不是权限或语法问题

真正能跑聚合的方案：GridFS + 元数据集合

核心是把“存”和“查”拆开：用 GridFS 存原始大 JSON，用独立集合存可索引、可聚合的业务字段，并通过 file_id 关联。

• 元数据文档里必须含 file_id: ObjectId("")，且值要与 fs.files._id 完全一致，否则 $lookup 关联失败
• 只存摘要字段：比如 errorCount、durationMs、deviceId、timestamp，别把整个 JSON 结构复制进去
• 所有需查询/排序的字段都要单独建索引，例如：db.large_docs_meta.createIndex({ deviceId: 1, timestamp: -1 })
• 上传时必须同步写元数据，不能靠事后补 —— 应用层要保证原子性（可用事务包裹 GridFS 写入 + 元数据插入）

分表（子文档拆分）适合哪些场景

拆成多个子文档不是万能解，只适用于逻辑上可分割、且查询模式固定的场景：

• 子文档彼此独立（如用户评论列表），无跨文档统计需求
• 查询总是先取主文档，再按 ID 批量拉子文档（比如 db.comments.find({ postId: "abc" })）
• 子文档数量可控（几百条以内），否则应用层合并成本高
• 更新单条子文档时，能接受统计字段（如 totalCommentCount）不同步 —— 或者自己加双写逻辑

如果业务需要按时间范围对“十年日志”统一排序、分页跳转到第 10001 条，或者要实时计算 errorRate = errorCount / totalCount，那拆文档反而让问题更重：MongoDB 不支持跨文档数组展开后统一排序。