垂直切分
将不同业务模块所使用的表切分到不同的数据库（主机）之上，这样的切能够称之为数据的垂直（纵向）切分
在架构设计中，各个功能模块相互之间的交互点越统一越少，系统的耦合度就越低，系统各个模块的维护性以及扩展性也就越好，实现数据的垂直切分也就越简单
垂直切分的长处
◆ 数据库的拆分简单明了，拆分规则明白；
◆ 应用程序模块清晰明白，整合easy；
◆ 数据维护方便易行，easy定位；
垂直切分的缺点
◆ 部分表的关联无法在数据库级别完毕，须要在程序中完毕；
◆ 对于訪问极其频繁且数据量超大的表仍然存在性能平静，不一定能满足要求；
◆ 事务处理相对更为复杂；
◆ 切分达到一定程度之后，扩展性会遇到限制；
◆ 过读切分可能会带来系统过渡复杂而难以维护；
水平切分
依据表中的数据的逻辑关系，将同一个表中的数据依照某种条件拆分到多台数据库（主机）上面
就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其它的数据库中。为了能够判定各行数据被切分到哪个数据库中了，切分总是要依照某种特定的规则来进行的，如依据某个数字类型字段基于特定数目取模、某个时间类型字段的范围、或者是某个字符类型字段的hash值
水平切分的长处
◆ 表的关联基本能够在数据库端全部完毕；
◆ 不会存在某些超大型数据量和高负载的表遇到瓶颈的问题；
◆ 应用程序端总体架构修改相对较少；
◆ 事务处理相对简单；
◆ 仅仅要切分规则能够定义好，基本上较难遇到扩展性限制；
水平切分的缺点
◆ 切分规则相对更为复杂，非常难抽象出一个能够满足整个数据库的切分规则；
◆ 后期数据的维护难度有所添加，人为手工定位数据更困难；
◆ 应用系统各模块耦合度较高，可能会对后面数据的迁移拆分造成一定的困难；
联合使用
在非常多大型的应用系统中，垂直切分和水平切这两种数据的切分方法基本上都是并存的。并且经常在不断的交替进行，以不断的添加系统的扩展能力。我们在应对不同的应用场景的时候，也须要充分考虑到这两种切分方法各自的局限，以及各自的优势。在不同的时期（负载压力）使用不同的结合方式。
联合切分的长处
◆ 能够充分利用垂直切分和水平切分各自的优势而避免各自的缺陷；
◆ 让系统扩展性得到最大化提升。
联合切分的缺点
◆ 数据库系统架构比較复杂，维护难度更大。
◆ 应用程序架构也相对更复杂；
数据切分及整合方案
数据库中的数据在经过垂直和（或）水平切分被存放在不同的数据库主机之后，应用系统面临的最大问题就是怎样来让这些数据源得到较好的整合
方案
总的来说，存在两种解决思路：
1、在每一个应用程序模块中配置管理自己须要的一个（或者多个）数据源，直接訪问各个数据库，在模块内完毕数据的整合；
2、通过中间代理层来统一管理全部的数据源，后端数据库集群对前端应用程序透明；
数据切分与整合可能存在的问题
引入分布式事务的问题
数据切分之后，可能造成之前的某些事务所涉及到的数据已经不在同一个MySQLServer中了
MySQL5.0之后Innodb提供分布式事务支持，不过对于系统资源的消耗是非常大的
最好能够结合数据库以及应用程序两者来共同解决。各个数据库解决自己身上的事务。然后通过应用程序来控制多个数据库上面的事务
跨节点Join的问题
数据切分之后，可能会造成有些老的Join语句无法继续使用。由于Join使用的数据源可能被切分到多个MySQLServer中了
非得在数据库端来直接解决的话，恐怕仅仅能通过MySQL一种特殊的存储引擎Federated来解决
Federated会保存一份远端表结构的定义信息在本地，不过本地的表定义信息是不会跟着远端的表结构发生对应变化的，所以如果在更新远端表结构的时候并没有更新本地的表定义信息，就可能造成Query执行出错
推荐通过应用程序来进行处理，先在驱动表所在的MySQLServer中取出对应的驱动结果集。然后依据驱动结果集再到被驱动表所在的MySQLServer中取出对应的数据