为何按general.sid索引查询大尺寸MongoDB文档时读写耗时远高于小文档

所有差异本质都和两个文档16倍的体积差直接相关，和索引本身无关——你在general.sid上建的索引已经帮你跳过了全集合扫描的环节，两个查询走的索引路径是完全一样的。

读取环节的耗时差来源 #

• 你目前建立的general.sid单字段索引，仅存储字段值和对应文档的物理位置指针，不包含其他业务字段的内容，查询走索引定位到文档后，必须回表读取实际的文档内容，不存在索引层面的性能差。
• 序列化与网络传输的固定开销差：MongoDB服务端拿到索引定位到的目标文档后，会把所有命中的返回字段的BSON数据序列化，通过内网连接传给Node.js驱动，驱动端再把二进制反序列化成JS对象。小文档仅28KB、大文档450KB，哪怕内网传输延迟极低，序列化、拷贝、反序列化450KB数据的耗时本来就是28KB数据的10_{20倍，和你测出来的7}20ms vs 1~2ms的差异完全匹配。
• 存储层的读取开销差：你现在的读取操作没有加字段投影，会把文档里1000条消息的数组全部读出来——哪怕这些消息已经在内存缓存里，大文档跨了数十个WiredTiger存储页（默认单页16KB），从共享内存拷贝文档数据、解压块压缩数据的计算量也会远高于28KB的小文档。

写入环节的耗时差来源 #

• 如果你的写入逻辑是「把整个查出来的文档改完resources字段，再通过replaceOne全量替换回数据库」，那大文档写入慢是完全正常的——你要把450KB的序列化数据从Node.js传回MongoDB，服务端要把这么大的数据写入操作日志、落盘生成文档快照，耗时肯定比传28KB的小文档高2_{5倍，和实测的5}10ms vs 1~2ms的差异匹配。
• 就算你是用$set精准只更新general.resources一个小字段，大文档的写入也会比小文档慢：WiredTiger默认开启块级snappy压缩，要修改一个文档内的小字段，必须先把包含该字段的存储块解压到内存，修改完成后再重新压缩、生成新的文档快照，大文档需要解压、压缩的计算量远高于小文档，自然会产生可观测的耗时差。

• 读取时添加字段投影，完全不需要的messages字段不要从数据库拉回，修改后的读取代码如下：

db.get().collection('player_data').find(
  {"general.sid":UID},
  {projection: {general: 1, resources: 1, _id: 0}}
).limit(1).toArray(function (err, result){
  if(err){
    reject(null);
  }
  resolve(result);
});

加了投影之后，哪怕是大文档，实际传输的字段体积和小文档几乎没有差别，读取耗时可以直接降到和小文档一致的1~2ms水平。

• 写入时不要全量替换文档，直接在数据库端用$set完成resources字段的更新，不要把整个大文档拿到Node.js改完再传回去，减少不必要的450KB级别的网络传输开销。
• 如果messages数组的查询需求和玩家基础信息的查询需求完全不重合，可以把messages拆到独立的关联集合里，主文档只保留general、resources这些核心字段，从根源上把主文档的体积压回和小文档一致的水平，彻底消除体积带来的性能差。

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