访问MongoDB单文档与同集合多文档的性能差异探讨

你的猜测核心是对的：MongoDB采用文档级锁（4.0及以上版本默认），当某个连接读写包含大列表的父文档时，其他针对该文档的读写请求会被阻塞，但同集合内的其他文档操作不受影响。除此之外，这种存储方式还有以下关键性能问题：

• 锁竞争加剧，吞吐量下降：所有对列表的增、删、改操作都要针对同一个父文档执行，高并发场景下大量请求会排队等待锁释放，直接拖垮处理能力。如果拆分到独立集合，每个列表项是单独文档，锁只会作用在单个小文档上，冲突概率极低。

• 文档膨胀与磁盘碎片：频繁修改列表（比如持续追加元素）会让父文档体积不断增长，超过MongoDB预分配的磁盘空间后，需要频繁重新分配空间，产生大量磁盘碎片。而且MongoDB单文档最大限制是16MB，列表持续增长迟早会触碰到这个上限，导致写入失败。

• 无效的资源消耗：哪怕你只需要列表里的某一个元素，读取时也必须拉取整个父文档，当列表很大时，网络传输和内存占用会大幅飙升。独立集合则可以精准查询单个项，资源利用率高得多。

• 索引效率低下：针对内嵌列表字段创建的是多键索引，查询时需要遍历整个列表的索引条目，效率远不如独立集合中针对单个字段的单键索引。同时，每次修改列表元素都要更新多键索引的对应条目，更新成本也更高。

• 原子操作的局限性：虽然MongoDB提供$push、$pull等内嵌数组的原子操作，但如果涉及复杂的列表元素修改（比如同时更新多个元素的不同字段），原子操作无法满足需求。这时要么引入事务（增加额外开销），要么只能先读取整个文档、修改后再写回，高并发下极易出现竞态条件，进一步加剧锁竞争。

总结来说，内嵌列表适合列表规模小、修改不频繁、需与父文档一同读写的场景；像你这种修改频繁的情况，将列表项独立为集合是更合理的选择。

内容的提问来源于stack exchange，提问作者ScottishTapWater