浅谈数据库分表

垂直分表

把⼀个有很多字段的表给拆分成多个表，或者是多个库上去。每个库表的结构都不⼀样，每个库表都包含部分字段。这个⼀般在表层⾯做的较多⼀些。比如⼤表拆开，订单表、 订单⽀付表、订单商品表。

分表依据：⼀般来说，访问频率⾼的字段放到⼀个表里去，访问频率低的字段放到另外⼀个表⾥去。因为数据库是有缓存的，访问频率高的行字段越少，就可以在缓存里缓存更多的行，性能就越好。

优点：字段分开，没有跨表join的问题
缺点：数据量大的时候热点数据列的行数没少，还是要查询，最终还是避免不了水平分表

水平分表

把⼀个表的数据给弄到多个库或者同库的多个表⾥去，但是每个表结构都⼀ 样，只不过数据不同，所有库表的数据加起来就是全部数据。⽔平拆分的意义，就是将数据均匀放更多的表或者库⾥，最好是分库，然后⽤多个库来扛更⾼的并发，还有就是⽤多个库的存储容量来进⾏扩容。

分表依据:时间（年，月，日），hash

优点: 动态扩容方便，数据归档方便， 缺点：分表的规则要考虑好，要避免跨表查询导致的情况性能下降

推荐中间件

Sharding-jdbc

当当开源的，属于 client 层⽅案，⽬前已经更名为 ShardingSphere （后⽂所提到的 Sharding-jdbc ，等同于 ShardingSphere ）。确实之前⽤的还⽐较多⼀些，因为 SQL 语法 ⽀持也⽐较多，没有太多限制，已经推出，⽀持分库 分表、读写分离、分布式 id ⽣成、柔性事务（最⼤努⼒送达型事务、TCC 事务）。⽽且确实之 前使⽤的公司会⽐较多⼀些（这个在官⽹有登记使⽤的公司，可以看到从 2017 年⼀直到现在，
是有不少公司在⽤的），⽬前社区也还⼀直在开发和维护，还算是⽐较活跃，个⼈认为算是⼀ 个现在也可以选择的方案。

Sharding-jdbc 这种 client 层⽅案的优点在于不用部署，运维成本低，不需要代理层的⼆次转发 请求，性能很高，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需 要耦合 Sharding-jdbc 的依赖；

Mycat

基于 Cobar 改造的，属于 proxy 层⽅案，⽀持的功能⾮常完善，⽽且⽬前应该是⾮常⽕的⽽且 不断流⾏的数据库中间件，社区很活跃，也有⼀些公司开始在⽤了。
Mycat 这种 proxy 层⽅案的缺点在于需要部署，⾃⼰运维⼀套中间件，运维成本⾼，但是好处在于对于各个项目是透明的，如果遇到升级之类的都是⾃⼰中间件那⾥搞就⾏了

对比

通常来说，这两个⽅案其实都可以选⽤，建议中⼩型公司选⽤ Sharding-jdbc，client 层⽅案轻便，⽽且维护成本低，不需要额外增派⼈⼿，⽽且中⼩型公司系统复杂度会低⼀些， 项⽬也没那么多；
但是中⼤型公司最好还是选⽤ Mycat 这类 proxy 层⽅案，因为可能⼤公司系统和项⽬⾮常多，团队很⼤，有相应的DBA和运维组，来专门研究和维护 Mycat，然后⼤量项⽬直接透明使⽤即可。

总结

表设计的时候，尽量字段少，表多，业务热点列数据集中于一个表，设计阶段达到垂直分表的目的，数据上升阶段，对热点表进行水平分表