分库分表要怎么做？

分库分表解决了什么？

分库：db连接数有上限，分库可以增加并发量。

分表：表数据太多，查询效率太低，分表可以提高查询速度。

分库分表有几种类型？

水平拆分：表结构不变，只是有原来的一张表切分成了很多张表。

垂直拆分：1、冷热数据拆分，将冷数据拆到其他表中，然后可以将不变的冷数据同步到缓存，减少主表查询的io量。

2、微服务业务拆分，现在需要成立新的业务用到主表中的部分字段，那就直接把这部分字段拆出去。

怎么做分库分表？

1、如何选择分库分表字段？

答案是根据你的业务来，举个例子，你最重要的查询是根据用户id来查询，那你就用userID作为分库分表的sharding key。

2、分库分表之后，非sharding key字段的查询怎么做？

因为不知道sharding key，所以无法的到目标的库信息，表信息，这时候就要全部库全部表都查一遍，才能得到结果，这显然是无法接受的，有以下几种方案：

    1、最常见的场景就是通过主键查询，比如在电商中就是通过orderID来查找订单，但是假如这个时候你的sharding key是userID，那就不能得到分库分表信息。对于这种，业内最常见的做法就是把userID的一部分取出来，加到orderID的末尾，你可以查看下你的淘宝订单，淘宝订单的后六位就是打乱后的userID，你每一个订单的后六位都不会变的。

    2、如果你的查询条件是商家id，你原来的sharding key是userID，那就再同步一份数据，存储介质可以和原来一样用db，那就以商家id作为新的sharding key。也可以选用一些不同的存储介质，比如es、clickhouse，这样甚至可以满足多种查询条件。

    2、映射表，建立需要查询字段到userID的映射表，根据隐射表先找到userID，这样就可以确定在哪个库哪个表。

3、如何选用分库分表算法

这里只讲各大电商公司最常用的分库算法：比如现在有4个库，每个库2张表，用userID来做sharding key，那么你的计算公式就是：

db_index = userID % 4

table_index = (userID / 4) % 2

这里需要注意一点分表的时候不能简单的只对2取模，因为会造成库上不同表上的数据数量的不均衡。比如说对于userID = 4，8，12，16，20...这一类id，都会落到db_index = 0的库中，然后数据全部在table_index = 0的表上，table_index = 1的表上一条数据也没有。

4、分库分表怎么做跨库join查询

首先说一个个人的观点：1、分库分表后要尽量避免做跨库查询，因为你的业务既然是有强关联的，那么就不应该拆分出去。

然后再说下解决办法：1、最笨的方法，那就是多个库查询完后手工代码join。

2、可以建一张全量表，每一行记录最初只有一部分字段有数据，缺少的这部分字段，用同步job的方式，把另一个库的数据同步到这张全量表里面。

3、在查询的表里冗余字段，其实和第二种方法差不多。

从原理上来看，二和三这两种方法，实际上是让原本跨库变的不跨库，个人觉得和这个问题是有矛盾的，好像做题有点偏题的感觉，人家问的就是跨库的场景。。。除此以外，如果你有什么好的方案，欢迎评论分享。

5、分库分表怎么做分页查询

个人觉得这个是分库分表后最麻烦的，貌似没有什么好的方案，只能多个库查出数据，手工代码排序后分页输出，当然这里排序可以用多路归并提高一下速度，但是代码比较难写（可行，但是还没有实践过）。如果你有什么好的方案，欢迎你来评论分享。

6、分库分表主键id怎么生成

首先有两个原则：1、不能重复 2、全局递增

未完待补。。。

7、分库分表后怎么扩容

未完待补。。。