通用分库分表方案

一、数据库瓶颈

• 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的查询

• 拆分规则越简单越好