目前分库分表的必要性：
由于在做消息中心，消息中心的量级又比较大，目前大概有9000W用户，差不多每天200W~500W消息的样子，数据达到千万级非常快，目前用的mysql存储消息发送记录以及消息发送详情，那么单张表存储的话及时数据索引建立合理也不可避免的会影响数据的查询和写入速度。这种情况下分库分表就特别必要了。
这里要明白一个概念，分库分表并不是绑定在一起的，我们需要根据自己的切实情况进行选择；
从我个人来看，分库是为了解决高并发问题,流量平均，分表是解决大数据量问题，数据平均；
零. 来自官方的数据库分库分表的必要性
传统的将数据集中存储至单一数据节点的解决方案，在性能、可用性和运维成本这三方面已经难于满足互联网的海量数据场景.
- 从性能方面来说，由于关系型数据库大多采用
B+树类型的索引，在数据量超过阈值的情况下，索引深度的增加也将使得磁盘访问的io次数增加，进而导致查询性能的下降；同时，高并发访问请求也使得集中式数据库成为系统的最大瓶颈. - 从可用性的方面来讲，
服务化的无状态型，能够达到较小成本的随意扩容，这必然导致系统的最终压力都落在数据库之上。而单一的数据节点，或者简单的主从架构，已经越来越难以承担。数据库的可用性，已成为整个系统的关键. - 从运维成本方面考虑，当一个数据库实例中的
数据达到阈值以上，对于DBA的运维压力就会增大。数据备份和恢复的时间成本都将随着数据量的大小而愈发不可控。一般来讲，单一数据库实例的数据的阈值在1TB之内，是比较合理的范围
一. 分库分表中间件的划分
分库分表中间件主要分为代理类，客户端类两种类型。
代理类中间件(eg:mycat)：
作为一个单独的服务，数据库和中间件做交换，中间件负责转发。客户端类中间件(eg:sharding jdbc)：
作为一个jar包在自己系统内使用
二. 有哪些分库分表中间件？不同的分库分表中间件都有什么优点和缺点？
2.1 常见分库分表中间件介绍
比较常见的包括：cobar、TDDL、atlas、sharding-jdbc、mycat
cobar：阿里b2b团队开发和开源的，属于proxy层方案。早些年还可以用，但是最近几年都没更新了，基本没啥人用，差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库join和分页等操作。
TDDL：淘宝团队开发的，属于client层方案。不支持join、多表查询等语法，就是基本的crud语法是ok，但是支持读写分离。目前使用的也不多，因为还依赖淘宝的diamond配置管理系统。问了我菜鸟供应链的同学，他们部门就是用的这个atlas：360开源的，属于proxy层方案，以前是有一些公司在用的，但是确实有一个很大的问题就是社区最新的维护都在5年前了。所以，现在用的公司基本也很少了。
sharding-jdbc：当当开源的，属于client层方案。确实之前用的还比较多一些，因为SQL语法支持也比较多，没有太多限制，而且目前推出到了2.0版本，支持分库分表、读写分离、分布式id生成、柔性事务（最大努力送达型事务、TCC事务）。
mycat：基于cobar改造的，属于proxy层方案·，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件社区很活跃`。·
所以综上所述，现在其实建议考量的，就是sharding-jdbc和mycat，这两个都可以去考虑使用。
2.2 常见分库分表中间件优缺点
sharding-jdbc： client层
- 优点：
client层方案的优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高. - 缺点：但是如果遇到升级啥的需要各个系统都重新升级版本再发布，
各个系统都需要耦合sharding-jdbc的依赖；
mycat： proxy层
- 缺点：这种
proxy层方案的缺点在于需要部署，自己及运维一套中间件，运维成本高 - 有点：
对于各个项目是透明的，如果遇到升级之类的都是自己中间件那里搞就行了。
通常来说，这两个方案其实都可以选用，但是我个人建议中小型公司选用sharding-jdbc，client层方案轻便，而且维护成本低，不需要额外增派人手，而且中小型公司系统复杂度会低一些，项目也没那么多；
但是中大型公司最好还是选用mycat这类proxy层方案，因为可能大公司系统和项目非常多，团队很大，人员充足，那么最好是专门弄个人来研究和维护mycat，然后大量项目直接透明使用即可。
三 .分库分表的方向
3.1 按照拆分的方向分为垂直拆分和水平拆分
垂直拆分：就是把一个有很多字段的表给拆分成多个表，或者是多个库上去。每个库
表的结构都不一样，每个库表都包含部分字段。一般来说，会将较少的访问频率很高的字段放到一个表里去，然后将较多的访问频率很低的字段放到另外一个表里去。因为数据库是有缓存的，你访问频率高的行字段越少，就可以在缓存里缓存更多的行，性能就越好。这个一般在表层面做的较多一些。垂直分片往往需要对架构和设计进行调整。通常来讲，是来不及应对互联网业务需求快速变化的；而且，它也并无法真正的解决单点瓶颈。垂直拆分可以缓解数据量和访问量带来的问题，但无法根治。如果垂直拆分之后，表中的数据量依然超过单节点所能承载的阈值，则需要水平分片来进一步处理。
eg: 用户表people拆成两张表：base_people，ext_people
base_people：存放 用户账户，姓名，uuid，openid，手机号
ext_people：存放 身高，学历，所属公司水平拆分的意思，就是把一个表的数据给弄到多个库的多个表里去，但是每个库的
表结构都一样，只不过每个库表放的数据是不同的，所有库表的数据加起来就是全部数据。水平拆分的意义，就是将数据均匀放更多的库里，然后用多个库来抗更高的并发，还有就是用多个库的存储容量来进行扩容。
eg：消息表按照id拆分，每50W数据分一个表；
3.2按数据划分方式
一般有有两种分库分表的方式
- 一种是按批来分，就是每个库一段连续的数据，这个一般是按比如时间范围来的，但是这种一般
较少用，因为很容易产生热点问题，大量的流量都打在最新的数据上了； - 另外一种是按照某个字段hash一下均匀分散，这个较为
常用。
以订单id表进行hash'拆分，预设要分几个库，几个表
range来分，好处在于说，
后面扩容的时候，就很容易，因为你只要预备好，给每个月都准备一个库就可以了，到了一个新的月份的时候，自然而然，就会写新的库了；缺点，但是大部分的请求，都是访问最新的数据。实际生产用range，要看场景，一般来说是只有下面这样的情况用range：你的用户不是仅仅访问最新的数据，而是均匀的访问现在的数据以及历史的数据hash分法，
好处在于说，可以平均分配没给库的数据量和请求压力；坏处在于说扩容起来比较麻烦，会有一个数据迁移的这么一个过程。比如上面的水平拆分，如果我们现在要分成五个表，那么每个id进行hash的位置都会变化，就设计到数据迁移了。
