又到一年春招时，准备找工作或者是准备换工作的小伙伴，肯定都忙着看面经、刷题等各种操作作为一个出现频率超高的面试题，今天总结一波主要是对分库分表的原理进行解析不涉及具体操作，下面我们就来说一说关于到底什么时候要分库分表?我们一起去了解并探讨一下这个问题吧!
到底什么时候要分库分表
又到一年春招时，准备找工作或者是准备换工作的小伙伴，肯定都忙着看面经、刷题等各种操作。作为一个出现频率超高的面试题，今天总结一波。主要是对分库分表的原理进行解析。不涉及具体操作。
这篇文章的脉络如下：
1、分库分表之前出现的问题
2、怎么分库分表？
3、分库分表的规则是什么？
下面按照这个脉络给出今天的文章。
一、单库单表存在的问题
假设你要设计一个电商网站，在一开始，User表、Order表、Product表等等各种表都在同一个数据库中，每个表都包含了大量的字段。在用户量比较少，访问量也比较少的时候，单库单表不存在问题。
但是公司可能发展的比较好，用户量开始大量增加，业务也越来越繁杂。一张表的字段可能有几十个甚至上百个，而且一张表存储的数据还很多，高达几千万数据，更难受的是这样的表还挺多。于是一个数据库的压力就太大了，一张表的压力也比较大。试想一下，我们在一张几千万数据的表中查询数据，压力本来就大，如果这张表还需要关联查询，那时间等等各个方面的压力就更大了。
（1）单库太大：数据库里面的表太多，所在服务器磁盘空间装不下，IO次数多CPU忙不过来。
（2）单表太大：一张表的字段太多，数据太多。查询起来困难。
此时就开始考虑如何解决问题了。
二、主从复制架构
单库单表下越来越不满足需求，此时我们先考虑进行读写分离。我们将数据库的写操作和读操作进行分离， 使用多个从库副本（Slaver）负责读，使用主库（Master）负责写， 从库从主库同步更新数据，保持数据一致。
这在一定程度上可以解决问题，但是用户超级多的时候，比如几个亿用户，此时写操作会越来越多，一个主库（Master）不能满足要求了，那就把主库拆分，这时候为了保证数据的一致性就要开始进行同步，此时会带来一系列问题：
（1）写操作拓展起来比较困难，因为要保证多个主库的数据一致性。
（2）复制延时：意思是同步带来的时间消耗。
（3）锁表率上升：读写分离，命中率少，锁表的概率提升。
（4）表变大，缓存率下降：此时缓存率一旦下降，带来的就是时间上的消耗。
注意，此时主从复制还是单库单表，只不过复制了很多份并进行同步。
主从复制架构随着用户量的增加、访问量的增加、数据量的增加依然会带来大量的问题，那就要考虑换一种解决思路。就是今天所讲的主题，分库分表。
三、分库分表
不管是分库还是分表，都有两种切分方式：水平切分和垂直切分。下面我们分别看看如何切分。
1、分表
（1）垂直分表
表中的字段较多，一般将不常用的、 数据较大、长度较长的拆分到“扩展表“。一般情况加表的字段可能有几百列，此时是按照字段进行数竖直切。注意垂直分是列多的情况。
（2）水平分表
单表的数据量太大。按照某种规则（RANGE,HASH取模等），切分到多张表里面去。 但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈。这种情况是不建议使用的，因为数据量是逐渐增加的，当数据量增加到一定的程度还需要再进行切分。比较麻烦。
2、分库
（1）垂直分库
一个数据库的表太多。此时就会按照一定业务逻辑进行垂直切，比如用户相关的表放在一个数据库里，订单相关的表放在一个数据库里。注意此时不同的数据库应该存放在不同的服务器上，此时磁盘空间、内存、TPS等等都会得到解决。
（2）水平分库
水平分库理论上切分起来是比较麻烦的，它是指将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同。 水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈。
四、分库分表之后的问题
1、联合查询困难
联合查询不仅困难，而且可以说是不可能，因为两个相关联的表可能会分布在不同的数据库，不同的服务器中。
2、需要支持事务
分库分表后，就需要支持分布式事务了。数据库本身为我们提供了事务管理功能，但是分库分表之后就不适用了。如果我们自己编程协调事务，代码方面就又开始了麻烦。
3、跨库join困难
分库分表后表之间的关联操作将受到限制，我们无法join位于不同分库的表，也无法join分表粒度不同的表， 结果原本一次查询能够完成的业务，可能需要多次查询才能完成。 我们可以使用全局表，所有库都拷贝一份。
4、结果合并麻烦
比如我们购买了商品，订单表可能进行了拆分等等，此时结果合并就比较困难。
OK，这篇文章写完之后感觉还会做大量的补充和修改。因此本篇文章主要针对面试，足够。
,
