一、分库分表概述

• 分库分表就是对数据库进行拆分以一种方式或策略。但是在实际场景中，分库和分表并不是要一起出现的。有可能只是需要分表，有可能只是需要分库，如果在大流量高并发的情况下，会出现分库分表同时出现的情况。

二、什么情况需要分库分表

• 比如我们负责所业务线是全新的而且非常有潜质的，那么我们设计系统的时候，通常并不会上来就做分库分表的设计，因为对于系统上线之后的发展，没有人可以预测出来。所以，都会中规中矩的按照单库单表的方式去设计。
• 随着系统的推广，用户量也慢慢的上来了，我们发现，每天新增的业务数据变成了20万条，那么我们可以推算出，如果按照当前的新增数据量，一个月就会产生将近600万条数据，如果一张表的数据到达了千万级别，查询效率就会大大降低。所以，这时候，我们就需要考虑分表了。通过把整块业务数据拆分到多张表里，保证每张表中的数据不会因为太多而造成查询效率低下。
• 随着系统的发展，用户量越来越大，对数据库的请求已经飙升到了1000QPS，我们知道，数据库的并发如果达到1500左右就会出现抗不住的情况了。那么解决办法就是，我们进行分库操作了。采用多个数据库来平摊请求压力，从而保证数据库不会被大流量压垮。

三、分库分表的方式

1、垂直拆分

• 对表字段很多的情况，我们根据字段访问程度或业务含义进行拆分。
  比如一张订单表如果设计得字段较多，是否可以拆分出订单明细表，或者订单商品明细表等等。同步拆分表的字段，把对表的请求分散到多张表，减小对单张表的查询压力。
• 另外，对于不同的业务域，可以拆分到不同的数据库中。
  例如：订单相关的就放到订单库，商品相关的就放到商品库，支付相关的放到支付库。这样，就可以减少对单库的请求压力。

2、水平拆分

• 水平拆分，我们可以理解为就是多同一张表或者库的横向赋值。字段和库表是不变的，而是通过将整份数据分片存储。
  比如一张表中数据有3000万，我们通过水平拆分，分成10分，那么每张表只需要存储300万数据即可。这样可以大大的提升查询速度。

四、关于水平拆分的查询操作

1、方案一：按时间段拆

• 还是以上面的场景为例，每天增量的业务数据为20万，那么一个月就会产生600万数据，那么可以采取每个月一张表的方式进行数据存储，这种方案的好处就是相对简单，不过弊端也是有的，就是针对热点数据，依然还会压在当月的这张表。

2、方案二：根据hash的方式

• 可以通过根据唯一id或者某个业务字段进行hash寻址，确定插入的表示哪一张。
  比如事先我们先创建30张相关的业务表，然后通过hash取余的方式，可以将数据较为平均的分布在这30张表中。那么，对于热点数据的压力，理论上也是由这30张表进行平摊的。
• 如果业务数据太大了，30张表也无法承载，那么就要涉及到扩展表了，从30张扩张到50张，那么面对的问题就会麻烦了，因为总表的个数变化了，那么hash出来的地址也会变化，所以会涉及到数据迁移。
• 综上所述：无论采用那种方式，前提都是根据业务场景来判断的，甚至我们可以采用TiDB或者NoSQL的方式对数据进行存储。还是那句话，没有完全的方案银弹，只有最适合的而已。