Mysql扩展之分库分表概述

数据库的复制能解决访问问题，并不能解决大规模的并发写入问题，要解决这个问题就要考虑mysql数据切分了

数据切分，顾名思义，就是数据分散，将一台主机上的数据分摊到多台，减轻单台主机的负载压力，有两种切分方式，一种是分库，即按照业务模块分多个库，每个库中的表不一样，还有一种就是分表，按照一定的业务规则或者逻辑将数据拆分到不同的主机上，每个主机上的表是一样的，这个有点类似于Oracle的表分区。

分库又叫垂直分区，这种方式实现起来比较简单，重要的是对业务要细化，分库时候要想清楚各个模块业务之间的交互情况，避免将来写程序时出现过多的跨库操作。

分表又叫水平分区，这种方式实现起来就比垂直分区复杂些，但是它能解决垂直分区所不能解决的问题，即单张表的访问及写入很频繁，这时候就可以根据一定的业务规则（PS:如互联网BBS论坛的会员等级概念：根据会员等级来分表）来分表，这样就能减轻单表压力，并且还能解决各个模块的之间的频繁交互问题。

分库的优点是：实现简单，库与库之间界限分明，便于维护，缺点是不利于频繁跨库操作，单表数据量大的问题解决不了。

分表的优点是：能解决分库的不足点，但是缺点却恰恰是分库的优点，分表实现起来比较复杂，特别是分表规则的划分，程序的编写，以及后期的数据库拆分移植维护。

实际应用中，一般互联网企业的路线都是先分库再分表，两者结合使用，取长补短，这样发挥了mysql扩展的最大优势，但是缺点是架构很大，很复杂，应用程序的编写也比较复杂。

以上是mysql的数据切分的一些概念，数据切完了，现在要做的是怎么样在整合起来以便于外界访问，因为程序访问的入口永远只有一个，现在比较常用的解决方案是通过中间代理层来统一管控所有数据源。

常用的代理层方案：

1.mysql proxy

类似于连接池，所有连接通过它进行转发。

2.Amoeba

是一个开发代理层的框架，有对应版本Amoeba for mysql,对于数据切分规则，连接数控制，以及读写分离路由支持较好。

3.HiveDB

仅支持水平切分，底层由hibernate shards实现。

4.其他

HSCALE,Spock Proxy(ROR),Pyshards(Python)

最后值得注意的是mysql分库分表的缺点：
缺少好的分布式事务解决方案，目前仅有Innodb提供解决方案，性能值得商榷。
缺少类似于DBLink的跨节点SQL解决方案，Federated提供支持了，但是还是简单的支持，对于表结构的变化就不能为力。

这些缺点只能通过应用程序层来解决，不过话说回来，如果所有缺点都解决了，Oracle也不会卖那么贵了。