通用分库分表方案
一、数据库瓶颈
-
CPU瓶颈
-
SQL问题，如SQL中包含join\group by\order by\非索引字段条件查询等 -> SQL优化，建立合适索引
-
单表数据量太大 -> 水平分表
-
IO瓶颈
-
磁盘读IO瓶颈 -> 分库和垂直分表
-
网络IO瓶颈 -> 分库
二、分库分表
-
水平分库
-
以字段为依据，按一定策略（hash\range等），将一个库中的数据拆分到多个库中
-
如：user_id 可根据user_id%2=0和user_id%2=1来将数据分到db user0和db user1两个数据库
-
如：根据订单来源分到不同的db库
-
结果
-
每个库的结构都一样
-
每个库的数据都不一样，没有交集
-
所有库的并集是全量数据
-
应用场景
-
系统并发量较大，分表难以从根本上解决问题，且没有明显的业务归属来垂直分库
-
效果
-
库多了，io和cpu压力成倍环境
-
水平分表
-
以字段为依据，按一定策略（hash\range等），将一个表中的数据拆分到多个表中
-
如：user_id可根据user_id%2=0和user_id%2=1将一个表中的数据拆分到tb_user_0和tb_user_1两个表中
-
结果
-
每个表的结构都一样
-
每个表的数据都不一样，没有交集
-
所有表的并集是全量数据
-
应用场景
-
系统并发量不大，只是单表的数据量太多，影响SQL效率，加重CPU负担
-
效果
-
表的数据量少了，单次SQL执行效率高，可减轻CPU负担
-
垂直分库
-
以表为依据，按照业务归属不同，将不同的表拆分到不同的库中
-
结果
-
每个库的结构都不一样
-
每个库的数据也不一样，没有交集
-
所有库的并集是全量数据
-
应用场景
-
系统绝对并发量较大，且可以抽象出单独的业务模块
-
效果
-
可以考虑进行服务化改造
-
垂直分表
-
以字段为依据，按照字段的活跃性，将表中字段拆到不同的表中（主表和扩展表）
-
结果
-
每个表的结构都不一样
-
每个表的数据也不一样，每个表的字段至少有一列交集，一般是主键，用于关联数据
-
所有表的并集是全量数据
-
应用场景
-
系统绝对并发量没有上来，表的记录并不多，但是字段多，且热点数据和非热点数据在一起，单行数据所需的存储空间较大。以至于数据库缓存的数据行减少，查询时会去读磁盘数据产生大量的随机读IO,产生IO瓶颈
-
分析
-
拆分原则：将热点数据放在一起作为主表，非热点数据放在一起作为扩展表；则更多热点数据就能被缓存下来，减少随机读IO；
-
获取全部数据需要关联两个表，但不要用join，因为join会增加cpu负担且会将两个表耦合在一起
-
关联数据，应该放在业务Service层做，分别获取主表和扩展表数据然后用关联字段关联得到全部数据
-
分库分表工具
-
sharding-sphere:jar
-
TDDL:jar
-
Mycat:中间件
-
分库分表步骤
-
根据容量（当前容量和增长量）评估分库或分表个数 -> 选key(均匀) -> 分表规则（hash或range等） -> 执行（一般双写） -> 扩容问题（尽量减少数据移动）
-
分库分表问题
-
非partition key的查询问题
-
扩容问题
-
水平扩容库（升级从库法）
-
水平扩容表（双写迁移法）
-
总结
-
确定瓶颈，再确定分库还是分表、水平还是垂直、分几个
-
选key很重要，既要拆分均匀，也要考虑非partition key的查询
-
拆分规则越简单越好
