分库/分表
Last updated
Last updated
什么是分库/分表
库即database，表即table，分库即将1个database拆分为多个database，分表即将1个table拆分为多个table。
为什么要分
数据库的架构演变过程：单机→读写分离（主从）→分库分表。
读写分离可以在一定程度上解决请求量太大的问题：读请求和写请求分别在不同的数据库实例上。但是，如果写请求或者读请求再增长，单机可能就无法承受，比如单机的磁盘，内存，IO等都是有限的。所以，将单库变为多库，就是一种解决方案。
如果一张表的数据量无限增大，甚至整个库就一张表，但是仍然无法存储持续到来的数据，再或者，由于数据量的持续增长，索引也会变得很大，查询也会变得很慢，此时，将单表变为多表，就是一种解决方案。
所谓分库，其实就是将1个库中的n个表，拆分到多个库中，这样每个库中表的数量就减少了。所以，分库只有一种方式，就是垂直分库：按照业务模块来划分出不同的数据库，与微服务的划分方式类似。
比如一般的电商平台，包含了用户、商品、订单等几大模块，简单的做法是在同一个库中分别建3张表，但是随着业务量的增长，将所有业务都放在一个库中已经变得越来越难以维护，因此可以将不同业务放在不同的库中。
垂直分表，通俗的说法叫做“大表拆小表”，拆分是基于关系型数据库中的“列”（字段）进行的。通常情况，某个表中的字段比较多，可以新建立一张“扩展表”，且这个扩展表会冗余主表的主键列。
垂直拆分依据主要有几点：
（1）将长度较短，访问频率较高的列尽量放在一个表里（主表）
（2）将字段较长，访问频率较低的列尽量放在一个表里（扩展表）
（3）经常一起访问的属性，也可以放在一个表里
优先考虑1和2，第3点不是必须。另外，如果实在列过多，主表和扩展表都可以有多个。
垂直拆分后，可能会有这样的问题：原来只需要在一张表中就可以访问到的列，拆分后可能需要进行JOIN联表。
此时，建议不要使用JOIN来联表访问，而应该分两次进行查询。
比如，将表user(uid, name, age, gender)拆分为user_base(uid, name)和user_ext(uid, age, gender)，拆分前：
拆分后应该避免使用如下联表的方式查询
而是使用两次查询，然后交给应用程序来完成JOIN的语义
这么做主要基于如下考虑：
（1）join更消损耗数据库性能；
（2）join会让user_base表和user_ext表耦合在一起（必须在一个数据库实例上，否则无法JOIN），不利于数据量大时拆分到不同的数据库实例上。毕竟减少数据量，提升性能才是垂直拆分的初衷。
此外，拆分字段的操作建议在数据库设计阶段就做好。如果是在发展过程中拆分，则需要改写以前的查询语句，会额外带来一定的成本和风险，建议谨慎。
水平分表也称为横向分表，就是将表中不同的数据行按照一定规律分布到不同的数据库表中。一般而言，拆分后的表会落到不同的数据库实例中，也称为水平分库分表。
常见的水平拆分规则如下：
范围拆分
按照范围拆分，比如按照自增id来拆分，从0到10000一个表，10001到20000一个表...。
范围拆分的优点是策略简单，可以很快定位到数据在哪个库上，且扩容简单，如果容量不够，只要增加新库即可。
范围拆分的缺点：
列值必须要满足递增的特性
数据量不均，新增的库，在初期的数据会比较少
请求量不均，比如我们用户id来拆分，一般来说新注册的用户活跃度会比较高，导致服务器利用率不平衡
哈希取模
按照表中某个列的值的进行先哈希取模来拆分。
比如有user(uid, name)和order(uid, ...)，则可以对user和order中的uid进行取模操作（mod = uid % (表的数量)），这样同一个用户的订单就会落在同一个数据库实例中，可以避免跨库事务之类的问题。
如果要按照某个非数值类型的列进行拆分，则可以先对列值进行HASH操作，再取模。
哈希取模的优点是：策略简单，可以很快定位到数据在哪个库上，且数据量均衡，请求量均衡（前提是HASH均匀）。
哈希取模的不足是扩容麻烦：如果容量不够，要增加一个库，重新hash可能会导致数据迁移。
地理区域
比如按照华东，华南，华北这样来区分业务。
时间
按照时间拆分，实现“冷热数据分离”。
水平拆分后，对于拆分列（按照这个列进行拆分）上的查询，可以根据拆分规则，直接路由到库，但是对于非拆分列上的查询，就需要费一番周折。
比如user(uid, login_name)按照uid拆分为user_1(uid, login_name)和user_2(uid, login_name)。
那么，拆分列为uid，则如下查询可以根据拆分规则，直接路由到库(假设为user_1)，获取查询结果。
但是，对于按照login_name进行的查询，就很困难，因为不知道要去哪个库去查。
如果遍历所有库，当分库数量很多的时候，性能会显著降低。
针对这种查询，一般有如下解决方案。
索引表法
思路：uid能直接定位到库，login_name不能直接定位到库，如果通过login_name能查询到uid，问题解决
解决方案：新建表t(login_name, uid)，用login_name来访问时，先通过索引表查询到uid，再定位相应的库。
索引表属性较少，可以容纳非常多数据，一般不需要分库；如果数据量过大，可以通过login_name来分库。
这种方案的不足之处在于：多一次数据库查询。
缓存映射法
思路：访问索引表性能较低，把映射关系放在缓存里性能更佳
解决方案：login_name查询先到cache中查询uid，再根据uid定位数据库；假设cache miss，采用扫全库法获取login_name对应的uid，放入cache；login_name到uid的映射关系不会变化，映射关系一旦放入缓存，不会更改，无需淘汰，缓存命中率超高。
这种方案的不足之处在于：多一次缓存查询。
login_name生成uid
思路：不进行远程查询，由login_name直接得到uid
解决方案：在用户注册时，设计函数login_name生成uid，uid=f(login_name)，按uid分库插入数据；用login_name来访问时，先通过函数计算出uid，即uid=f(login_name)再来一遍，由uid路由到对应库。
这种方案的不足之处在于：函数设计需要非常讲究技巧，有uid生成冲突风险。
login_name基因融入uid
思路：不用login_name生成uid，可以从login_name抽取“基因”，融入uid中
假设分8库，采用uid%8路由，则uid的最后3个bit决定这条数据落在哪个库上，这3个bit就是所谓的“基因”。
解决方案：
>在用户注册时，设计函数login_name生成3bit基因，login_name_gene=f(login_name)
>同时，生成61bit的全局唯一id，作为用户的标识
>接着把3bit的login_name_gene也作为uid的一部分
>生成64bit的uid，由id和login_name_gene拼装而成，并按照uid分库插入数据
>用login_name来访问时，先通过函数由login_name再次复原3bit基因，login_name_gene=f(login_name)，通过login_name_gene%8直接定位到库
