数据库拆分原则：
1.优先考虑缓存降低对数据库的读操作。
2.再考虑读写分离，降低数据库写操作。
3.最后开始数据拆分,切分模式： 首先垂直（纵向）拆分、再次水平拆分。
4.首先考虑按照业务垂直拆分。
5.再考虑水平拆分：先分库(设置数据路由规则，把数据分配到不同的库中)
6.最后再考虑分表，单表拆分到数据1000万以内。
垂直拆分：
专库专用：一个数据库由很多表的构成，每个表对应不同的业务，垂直拆分是指按照业务将表进行分类，分布到不同的数据库上面，这样也就将数据或者说压力分担到不同的库上面；
优点：
1.拆分后业务清晰，拆分规则明确。
2.系统之间整合或者扩展容易。
3.数据维护简单。
缺点：
1.部分业务表无法join。只能通过接口方式解决，提高了系统复杂度。
2.受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高。
3.事务处理复杂。
水平拆分:
垂直拆分后遇到单机瓶颈，相对于垂直拆分的区别是：
垂直拆分是把不同的表拆到不同的数据库中，而水平拆分是把同一张表拆到不同的数据库中。
我们可以将数据的水平切分理解为：我们将数据的水平切分理解为按照数据行的切分，
就是讲表中的某些行切分到一个数据库，而另外的某些行后切分到其他的数据库中，主要有
分表，分库两种模式；
优点：
1.不存在单库大数据，高并发的性能瓶颈；
2.对应用透明，应用端改造较少。
3.按照合理拆分规则拆分，join操作基本避免跨库。
4.提高了系统的稳定性跟负载能力。
缺点：
1.拆分规则难以抽象。
2.分片事务一致性难以解决。
3.数据多次扩展难度跟维护量极大。
4.跨库join性能较差。
拆分的处理难点：
两种方式的共同缺点：
1.引入分布式事物的问题。
2.跨节点join的问题。
3.跨节点合并排序分页问题。
针对数据源管理，目前主要有两种思路：
A：客户端模式，在每个应用程序模块中配置管理自己需要的一个（或者多个）数据源，
直接访问各个数据库，在模块内完成数据的整合。
优点：相对简单，无性能损耗。
缺点：不够通用，数据库连接的处理复杂，对业务不够透明，处理复杂。
B：通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明；
优点：通用，对应用透明，改造少。
缺点：:实现难度大，有二次转发性能损失：
拆分原则：
1.尽量不拆分 ，架构师进化而来，不是一蹴而就。（SOA）
2.最大可能的找到合适的切分维度。
3.由于数据库中间件对数据join实现的优劣难以把握，而且实现高性能难度极大，
业务读取尽量少使用多表的Join-尽量通过数据冗余，分组避免数据跨库多表Join。
4.尽量避免分布式事物。
5.单表拆分到数据1000万以内。
切分方案
范围，枚举，时间，取模，哈希，制定等。