共计 857 个字符，预计需要花费 3 分钟才能阅读完成。
     不论是分库还是分表，都有两种切分形式：程度切分和垂直切分。上面咱们别离看看如何切分。
1、分表
（1）垂直分表
     表中的字段较多，个别将不罕用的、数据较大、长度较长的拆分到“扩大表“。个别状况加表的字段可能有几百列，此时是依照字段进行数竖直切。留神垂直分是列多的状况。
（2）程度分表
     单表的数据量太大。依照某种规定（RANGE,HASH 取模等），切分到多张表外面去。然而这些表还是在同一个库中，所以库级别的数据库操作还是有 IO 瓶颈。这种状况是不倡议应用的，因为数据量是逐步减少的，当数据量减少到肯定的水平还须要再进行切分。比拟麻烦。
2、分库
（1）垂直分库
一个数据库的表太多。此时就会依照肯定业务逻辑进行垂直切，比方用户相干的表放在一个数据库里，订单相干的表放在一个数据库里。留神此时不同的数据库应该寄存在不同的服务器上，此时磁盘空间、内存、TPS 等等都会失去解决。
（2）程度分库
程度分库实践上切分起来是比拟麻烦的，它是指将单张表的数据切分到多个服务器下来，每个服务器具备相应的库与表，只是表中数据汇合不同。程度分库分表可能无效的缓解单机和单库的性能瓶颈和压力，冲破 IO、连接数、硬件资源等的瓶颈。
四、分库分表之后的问题
1、联结查问艰难
联结查问不仅艰难，而且能够说是不可能，因为两个相关联的表可能会散布在不同的数据库，不同的服务器中。
2、须要反对事务
分库分表后，就须要反对分布式事务了。数据库自身为咱们提供了事务管理性能，然而分库分表之后就不实用了。如果咱们本人编程协调事务，代码方面就又开始了麻烦。
3、跨库 join 艰难
分库分表后表之间的关联操作将受到限制，咱们无奈 join 位于不同分库的表，也无奈 join 分表粒度不同的表，后果本来一次查问可能实现的业务，可能须要屡次查问能力实现。咱们能够应用全局表，所有库都拷贝一份。
4、后果合并麻烦
比方咱们购买了商品，订单表可能进行了拆分等等，此时后果合并就比拟艰难。
