一：出现的问题

数据库单库里面的数据量越来越大，查询数据出来的结果所花费的时间变得越来越长；

用户越来越多，写入的数据量也变得越来越多，有时会出现延迟，即使我们做了主从读写分离，这时候该怎么办？

毕竟单台服务器上的IO，CPU，硬盘等等都是有限的，单服务器上的资源是有限的。

单台服务器不行，我们可以用多台服务器，把请求分发到不同的服务器上，这时候就用到了“分”的思想了。

同理，数据库的库和表也是可以切分--分库分表。把大库大表变成多个库表，同时数据的读写也相应的进行了切分。

二：怎么分库分表

按大的分类，一般我们有水平切分和垂直切分。

数据表的数据量太巨大，可以进行水平切分表。我们按照某种规则(range, hash等)把数据切分到多张表中。

水平分表

把单张大数据的表按照一定的规则把数据分配到多张数据表中。所有表的结构字段是相同的。

这样不仅能控制表的大小，还能提升查询和写入的性能，分解请求的压力。

比如我们按照range切分表数据，1000W数据分一张表，如果有1500W数据，那么另外500W数据分到第二张表。

水平分库

当然我们也可以拆分到多个库中，比如一个库存1年的数据，每个库分12张表存数据等等方法。根据你的

实际情况进行选择。

比如我们有的系统中使用的冷热数据分离，将一些历史数据迁移到历史库中。

垂直切分我们一般按照表字段或业务进行切分。

在数据表上一般我们是按照字段进行切分，就是把一张表的字段拆分成多张表的字段。

或把业务分成不同的业务模块，建立不同的业务模块数据库。

比如电商，把用户，商品，订单独立建立数据库。分成多个库，我们也可以部署到多台服务器上，增强数据库

的处理能力。

垂直分表

按照表字段进行切分。

比如数据库表中的字段比较多，那么我们建立一张扩展表，将不经常使用或者长度较大的字段拆分到扩展表中。

当然还有其他的拆分方式。

垂直分库

在业务上，我们一般会把业务拆分成不同的业务模块，然后根据不同的业务模块创建不同的数据库，这个就是

垂直分库。

分库分表都可以用到上面的2种方式

有的切分规则上面有提到过

比如1-100000一张表， 100001-200000一张表，每10W数据一张表

比如取用户id，然后hash取模，分配到不同数据库

这种切割方式对于日志的切分一般用的比较多。

比如一张表存放一个月的数据，一年就是12张表了。

1、数据迁移问题

2、数据扩容问题

3、跨库join，group by，order等问题

4、事务问题

这部分问题待解决

Cobar	阿里巴巴B2B团队开发的，很少更新
MyCat	基于阿里开源的Cobar产品而研发，社区开发，现在社区比较活跃
Oneproxy	平民软件开发，不开源的商业中间件
Kingshard	原360开发团队的人开发的
Vitess	Youtube开发的中间件
Atlas	360团队基于mysql proxy开发的
MaxScale	maridb研发出的中间件
MySQL Route	MySQL官方推出的中间件