Mongoose文档存储ID集合的最优高性能方案：Array还是Map？

优先选择数组存储ids字段的方案，整体性能、工程适配性全面优于存id为键、固定值为value的对象结构，你最初预想的直接在文档里存JavaScript Set 结构的写法不可行——MongoDB的BSON格式没有原生Set类型，插入时会被驱动解析为普通对象，要么报错要么存错数据，不要这么写。

分维度性能对比 #

数据库侧性能 #

• 存储开销：纯字符串数组的存储体积远小于键值对对象。同样存N个字符串id，数组只需要存储N个字符串值，键值对对象需要额外存储每个id对应的布尔值字段，单文档体积会高出15%~40%，id数量越多差距越明显，对应的磁盘IO、网络传输开销也更高。
• 查询&索引效率：MongoDB对数组字段做了原生优化，给ids数组建多键索引之后，查持有某个指定id的文档只需要写{ ids: "目标id" }就能直接命中索引，查询延迟比查动态键对象低30%以上。如果存成键值对对象，要判断某个id是否存在需要用$exists操作符匹配动态键，不仅写法繁琐，也没法给动态变化的键建通用索引，查询性能会差很多。

前端侧性能 #

• 转换为Set的耗时几乎没有可感知差异：数组转Set直接调用new Set(idsArray)即可，这是JS引擎底层做过优化的原生方法，哪怕单条文档带1000个id，转换耗时也在微秒级；键值对对象转Set需要先取所有键new Set(Object.keys(idsMap))，多了一步遍历对象取键的操作，实际转换速度反而比数组转Set稍慢。
• 运行时过滤性能：两种方案最终转换得到的Set结构完全一致，后续调用Set.has()做id存在性判断、过滤列表渲染React表格的性能没有任何区别。

特殊场景例外 #

只有一种情况可以考虑存键值对对象：你完全不需要在数据库层做任何id维度的过滤查询，所有筛选逻辑全在前端执行，且单条文档关联的id数量超过1万条——不过这个量级在普通业务列表场景里几乎碰不到，这种场景下两种方案的性能差异依然很小，数组方案的存储优势还是存在。

不要为了省前端转Set的一步操作选对象存储方案，这一步的性能损耗在所有业务场景下都可以忽略，反而会给数据库层的查询、索引带来不必要的麻烦。

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