(6)MySQL Sharding
像oracle这种基于rac基于共享存储的方式，不需要sharding只需要扩从rac存储就能实现了。但是这种代价相对会比较高一些，共享存储一般都比较贵，随着业务的扩展数据的爆炸式增长，你会不停累计你的成本，甚至达到一个天文数字。
目前这种share disk的方式，除了oracle的业务逻辑层做的非常完善之外其他的解决方案都还不是很完美。
Mysql的sharding也有其局限性，sharding之后的数据查询访问以及统计都会有很大的问题，mysql的sharding是解决share nothing的存储的一种分布式的方法，大体上分为垂直拆分和水平拆分。
(6.1)垂直拆分
可以横向拆分，可以纵向拆分，可以横向纵向拆分，还可以按照业务拆分。
6.1.1横向拆分
Mysql库里面的横向拆分是指，每一个数据库实例里面都有很多个db库，每一个db库里面都有A表B表，比如db1库有A表B表，db2库里也有A表和B表，那么我们把db1、db2库的A表B表拆分出来，把一个库分成2个，就拆分成db1、db2、db3、db4，其中db1库和db2库放A表数据，db3库和 db4库放B表的数据，db1、db2库里面只有A表数据，db3、db4库里面只有B表的数据。
打个比方，作为电商来说，每个库里面都有日志表和订单表，假如A表是日志表log表，B表是订单表Order表，一般说来写日志和写订单没有强关联性，我们可以讲A表日志表和B表订单表拆分出来。那么这个时候就做了一次横向的拆分工作，将A表日志表和B表订单表拆分开来放在不同的库，当然A表和B表所在的数据库名也可以保持一致(PS：在不同的实例里面)，如下图所示：
PS：这种拆分主要针对于不同的业务对表的影响不大，表之间的业务关联很弱或者基本上没有业务关联。拆分的好处是不相关的数据表拆分到不同的实例里面，对数据库的容量扩展和性能提高的均衡来说，都是蛮有好处的。
6.1.2纵向拆分
把同一个实例上的不同的db库拆分出来，放入单独的不同实例中。这种拆分的适应场景和要求是db1和db2是没有多少业务联系的，类似6.1.2里面的A表和B表那样。如果你用到了跨库业务同时使用db1和db2的话，个人建议要重新考虑下业务，重新梳理下尽量把一个模块的表放在一个库里面，不要垮库操作。
这种库纵向拆分里面，单独的库db1，表A和表B是强关联的。如下图所示：
PS：看到很多使用mysql的人，总是把很多没有业务关联性的表放在一个库里面，或者总是把很多个的db库放在同一个实例里面，就像使用oracle那样就一个 instance的概念而已。Mysql的使用一大原则就是简单，尽量单一，简单的去使用mysql，库要严格的分开;表没有关系的，要严格拆分成库。这样的话扩展我们的业务就非常方便简单了，只需要把业务模块所在的db拆分出来，放入新的数据库服务器上即可。
6.1.3 横向纵向拆分
有些刚起步的，开始为了快速出产品，就把所以的库所有的表都放在一个实例上，等业务发展后，就面临着数据拆分，这里就会把横向纵向拆分结合起来，一起实现，如下图所示：
6.1.4 业务拆分
跟水平拆分有点类似，但是有不同的地方。比如一个供应商，可能整个网站上有10个供应商，一个网站上面每一个供应商都有一定的量，而且供应商之间的数据量规模都差不多的规模，那么这个时候就可以使用供应商的纬度来做拆分。
比如usern库中，a、b、c表都是强关联的，都有完整的业务逻辑存在，这里只有用户(供应商)纬度是没有关联的，那这个时候就可以把数据以用户的纬度来进行拆分。
就是用户1和用户2各自都有一套完整的业务逻辑，而且彼此之间不关联，所以就可以把用户1和用户2数据拆分到不同的数据库实例上面。目前很多互联网公司或者游戏公司有很多业务都是以用户纬度进行拆分的，比如qunaer、sohu game、sina等。
(6.2) 水平拆分
水平拆分相对要简单一些，但是难度偏大，会导致分布式的情况、跨数据的情况、跨事务的情况可以分为大概三类，1是历史数据和实时数据拆分，2是单库多表拆分，3是多库多表拆分。
