什么是分库分表？
顾名思义，分库分表就是对数据库进行拆分以一种方式或策略。但是在实际场景中，分库和分表并不是要一起出现的。有可能只是需要分表，有可能只是需要分库，如果在大流量高并发的情况下，会出现分库分表同时出现的情况。那么什么时候需要分库分表呢？
我们可以考虑一个问题，比如我们所负责的业务线是全新的而且非常有潜质的，那么我们设计系统的时候，通常并不会上来就做分库分表的设计，因为对于系统上线之后的发展，没有人可以预测出来。所以，都会中规中矩的按照单库单表的方式去设计。忙碌了好几个月，系统上线了，最初每天业务数据1000条，每秒到达数据库的d并发请求20个左右。那么我们设计的单库单表是完全可以应对的。但是随着系统的推广，大家发现这个系统真的很有吸引力，那么用户量也慢慢的上来了，我们发现，每天新增的业务数据变成了20万条，那么我们可以推算出，如果按照当前的新增数据量，一个月就会产生将近600万条数据，如果一张表的数据到达了千万级别，查询效率就会大大降低。所以，这时候，我们就需要考虑分表了。通过把整块业务数据拆分到多张表里，保证每张表中的数据不会因为太多而造成查询效率低下。那么，随着系统的发展，用户量越来越大，我们发现，对数据库的请求已经飙升到了1000QPS，那么这个时候，就已经为我们敲响了警钟！我们知道，数据库的并发如果达到1500左右就会出现抗不住的情况了。那么解决办法就是，我们进行分库操作了。采用多个数据库来平摊请求压力，从而保证数据库不会被大流量压垮。那么怎么去分库和分表呢？我们如何去做方案设计呢？
分库分表的方式有哪些？
关于分库分表我们可以从两个维度来说，分表是垂直拆分和水平拆分。
垂直拆分
对表字段很多的情况，我们根据字段访问程度或业务含义进行拆分。比如一张订单表如果设计得字段较多，是否可以拆分出订单明细表，或者订单商品明细表等等。同步拆分表的字段，把对表的请求分散到多张表，减小对单张表的查询压力。另外，对于不同的业务域，可以拆分到不同的数据库中，例如：订单相关的就放到订单库，商品相关的就放到商品库，支付相关的放到支付库。这样，就可以减少对单库的请求压力。
水平拆分
水平拆分，我们可以理解为就是多同一张表或者库的横向赋值。字段和库表是不变的，而是通过将整份数据分片存储。比如一张表中数据有3000万，我们通过水平拆分，分成10分，那么每张表只需要存储300万数据即可。这样可以大大的提升查询速度。
关于水平拆分的查询操作，常见的是两种方式。
方案一：按时间段拆
还是以上面的场景为例，每天增量的业务数据为20万，那么一个月就会产生600万数据，那么可以采取每个月一张表的方式进行数据存储，这种方案的好处就是相对简单，不过弊端也是有的，就是针对热点数据，依然还会压在当月的这张表。
方案二：根据hash的方式
可以通过根据唯一id或者某个业务字段进行hash寻址，确定插入的表示哪一张。比如事先我们先创建30张相关的业务表，然后通过hash取余的方式，可以将数据较为平均的分布在这30张表中。那么，对于热点数据的压力，理论上也是由这30张表进行平摊的。但是，如果业务数据太大了，30张表也无法承载，那么就要涉及到扩展表了，从30张扩张到50张，那么面对的问题就会麻烦了，因为总表的个数变化了，那么hash出来的地址也会变化，所以会涉及到数据迁移。
综上所述：无论采用那种方式，前提都是根据业务场景来判断的，甚至我们可以采用TiDB或者NoSQL的方式对数据进行存储。还是那句话，没有完全的方案银弹，只有最适合的而已。
今天的文章内容就这些了：
写作不易，笔者几个小时甚至数天完成的一篇文章，只愿换来您几秒钟的 点赞 & 分享 。
更多技术干货，欢迎大家关注公众号“爪哇缪斯” ~ (^o^)/ ~ 「干货分享，每天更新」
