大数据表存储最佳实践：两种买家存储方案的选型与性能咨询

方案一：单表数组存储的优劣 #

• 空间特性：如果用数据库原生数组类型（如PostgreSQL的integer[]），确实能省点空间——毕竟不用重复存book_id。但要是用逗号拼接的字符串当伪数组，不仅空间优势没了，还要额外花时间解析字符串，纯纯赔本买卖。
• 性能硬伤：
  • 查询要命：想查某个买家有没有买过这本书？得遍历整个10万元素的数组，就算数据库支持数组查询，速度也远不如索引找数据；统计买家数同理，慢到离谱。
  • 更新坑爹：加个买家或者删个买家，得修改整个数组字段，锁行时间超长，并发场景下直接卡成狗。
• 扩展性拉胯：没法直接关联买家表查用户信息（比如用户名、注册时间），必须先把数组拆成单个ID再查，操作复杂还低效。

方案二：关联表存储的优势 #

• 空间实际表现：别看每条记录都存book_id，关系型数据库对整数存储有优化（比如紧凑存储、页压缩），再加上联合索引的高效结构，实际空间开销并没有你想的那么大，大规模数据下反而更稳定。
• 性能起飞：给buyer_id和book_id建个联合索引，不管是查某本书的买家列表、某个买家的购书记录，还是统计买家数，都是毫秒级响应；新增/删除单个买家关联时，只操作单条记录，锁粒度极小，并发性能拉满。
• 绝对符合最佳实践：这是关系型数据库处理多对多关联的标准玩法，扩展性极强，能轻松对接图书表、买家表做各种复杂查询和统计，后期维护成本极低。

最终结论 #

无脑选方案二。方案一只有在极端特殊场景下才有用——比如你永远只需要批量读取整组买家ID，从不做单个买家的查询、更新操作。否则方案一的性能瓶颈和扩展性问题，会让你后期维护时欲哭无泪。

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