说说用户数据分库分表方案

1 背景

当时公司"背后的靠山"决定将亿级用户数据交给我们自己维护， 这样很多跟用户身份校验相关联的API就不用再调"靠山"啦！但随之而来的问题就是这亿级数据该怎么处理呢？ 数据库线上使用的MySQL， 直接单表存吗？据了解MySQL单表查询最优在五百万数据左右， 超过五百万后单表查询性能会严重下降。当时头赶紧组织了个小会， 商讨数据处理方案， 最后采用分表分表。

2 技术选型

关于分表分表的中间件主要讨论了开源的sharding-jdbc和mycat中间件， 最终选择了sharding-jdbc，为什么呢？ 官网文档十分完备， 社区活跃啊！ 虽然需要与应用耦合在一起， 但应用集成也非常方便简单。 sharding-jdbc与mycat的优缺点：

1. sharding-jdbc官网文档十分详细完备，对开发者来说非常友好； mycat的文档不太友好，从网上看口碑不行。
2. sharding-jdbc对应用有侵入， 而mycat无侵入
3. sharding-jdbc无需考虑高可用， 而mycat需要考虑。

3 分库分表方案

3.1 分几个库、几张表？

为了支持查询的效率以及后续用户量的增长，将用户数据拆分到2个库， 每个库64张表， 每张表大约200百万的数据， 这大概能支持未来5年乃至10年的用户增长了吧， 不会全国用户都用吧， 不至于吧，不敢想啊！！为保证高可用࿰