SQL单表存储海量投票数据的最佳实践咨询

首先先算总数据规模：10亿帖子 × 单帖平均1000次投票 = 总计1万亿条投票记录，这个量级下单表存储完全不是最佳实践，按用户维度拆分为数千张表也算不上更优方案。

单表存储的核心问题 #

• 无论使用哪种传统关系型数据库，单表数据量超过1亿条之后，增删改查性能都会出现明显下降，万亿级数据的场景下，索引维护、查询延迟、数据备份恢复的成本都会高到完全不可控。
• 业务要求user_id + post_id唯一，单表场景下每次投票都需要走全局唯一索引做重复校验，万亿级数据下这个校验的耗时根本无法承接正常的线上流量。

按用户维度拆分数千张表的优劣 #

优势 #

• 确实可以解决单表过大的问题，拆分后单表数据量降到1~10亿级，用户维度的查询（比如查询单个用户的所有投票记录）性能很高。

劣势 #

• 投票业务的高频查询大多是帖子维度：比如查询单帖的总投票数、查询某用户是否给某帖子投过票、拉取单帖的投票用户列表，这类查询需要遍历所有数千张分表才能拿到结果，哪怕单表查询只需要1ms，总耗时也会到秒级，完全不符合线上接口的性能要求。
• 如果后续用户量级突破数千，分表规则需要整体重构，扩展性极差。

更推荐的存储方案 #

优先按post_id做哈希分表，分表数量按单表承载1000万_{1亿条记录计算，1万亿条数据拆1024}2048张表即可：

• 所有帖子维度的高频查询，只要按post_id路由到单张表就能完成，性能极高。
• 判断特定用户是否给某帖子投票的场景，也只要带post_id路由到对应表，查询user_id是否存在即可，不需要遍历多表。
• user_id + post_id的联合唯一约束可以直接在分表内创建，校验成本极低。
• 如果不想手动维护分表逻辑，也可以直接用分布式NewSQL数据库自动处理分片，维护成本更低。

如果你业务的高频查询确实90%以上都是用户维度的，可以额外做一套用户维度的异构索引表，满足用户侧的查询需求即可。

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