不少开发者都会遇到一个常见问题：当向 MongoDB 写入一个超过 16MB 的文档时，会发生什么？答案很明确——系统会直接抛出异常。具体错误信息是 Payload document size is larger than maximum of 16MB 或 BsonMaximumSizeExceededException。这并非配置不当或驱动 Bug，而是 MongoDB 底层 BSON 协议在数据层面的硬性拦截。请求在网络层就被拒绝，根本无法进入存储引擎。因此，试图通过修改参数来绕过限制是行不通的。
GridFS 存储大 JSON 后为何不能直接执行聚合查询？
GridFS 作为 MongoDB 官方推荐的超大数据文件存储方案，其设计初衷侧重于“存储”而非“查询”。它将文件切割后分别存入 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 文件后，若试图直接在其内部执行业务查询，是行不通的。这条路被设计本身所阻断。
解决方案：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 并不支持跨文档数组展开后的统一排序。届时，你将发现虽然绕过了 16MB 的文档大小限制，却陷入了另一个更深的困境。
