一、数据库瓶颈

会导致数据库的活跃连接数增加，进而逼近甚至达到数据库可承载活跃连接数的阈值。在业务Service来看就是，可用数据库连接少甚至无连接可用。接下来就可以想象了吧（并发量、吞吐量、崩溃）。

1. IO瓶颈-分库和垂直分表
   • 磁盘IO瓶颈，热点数据太多，数据库缓存放不下，每次查询会产生大量的IO（分库和垂直分表）。
   • 网络IO瓶颈，请求数据太多，网络带宽不够（分库）。
2. CPU瓶颈-分摊给业务和水平分表
   • SQL问题：包含join、groupby、 order by，非索引字段条件查询等，增加CPU运算的操作（优化SQL，建立合适的索引，再业务层进行业务计算）。
   • 单表数据多，查询扫描的行太多，SQL效率低（水平分表）。

分库分表

1、水平分库（ 并发量高 ）

以字段为依据（用户取模、订单来源），按一定策略（hash、range等），将一个库中的数据拆分到多个库中。

场景：系统绝对并发量上来了，分表难以根本上解决问题，并且还没 有明显的业务归属来垂直分库。

2、水平分表（ 单表数据大 ）

类似分库，就是把库换成表。每个表结构都一样，每个表数据都不一样，所有表的并集是全量数据。

场景：并发量没有上来，只是单表的数据量太多，影响了单次SQL执行效率。

3、垂直分库（ 并发量高、服务化 ）

按照业务归属不同，将不同的表拆分到不同的库中。每个库的结构都不一样，数据也不一样。

场景：系统绝对并发量上来了，并且可以抽象出单独的业务模块。

4、垂直分表（ 利于缓存数据行 ）

按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。

场景：并发量没有上来，表记录不多，但字段多，单行数据所需的存储空间较大。导致缓存的数据行减少，查询会产生大量的随机读IO（如列表页–热点数据和详情页–非热点数据）。

备注：分表后不要用join，因为不仅会增加CPU负担并会将两个表捆绑在一起（不能分布部署 ）。尽量在业务层获取每个表数据，然后用关联字段拼接。

三、分库分表工具

Sharding-sphere [Sharding-JDBC]（当当）、TSharding（蘑菇街）、Atlas（奇虎360）、Cobar（阿里巴巴）、MyCat（基于Cobar）、Oceanus（58同城）和Vitess（谷歌）

注：工具的利弊，请自行调研，官网和社区优先。

四、分库分表步骤

根据容量（当前和增长量）评估分库或分表个数–>选key–>分配规则（hash或range）–>执行（双写）–>扩容问题（尽量减少数据的移动）。

五、分库分表问题

1、非partition key的查询问题

备注：基因法关于user_id的xbit基因（如分8张表，2^3=8），故x取3，即3bit基因。根据user_id查询时直接取模路由到对应的分库或分表。

根据user_name查询，先通过user_name_code生成函数生成code，然后对其取模路由到对应的分库分表。id生成常用snowflake算法。

后台除了partition key还有各种非partition key组合条件查询：Nosql法（推荐）后台与前端共享数据库与ES、冗余法（mq做桥梁）运营后台与前端数据库分离。

2、非partition key跨库跨表分页查询问题（ ES解决 ）

基于水平分库分表，拆分策略常用hash法。

3、扩容问题

水平扩容库（升级从库法）

水平扩容表（双写迁移法）

1. 修改应用配置和代码，加上双写，部署
2. 将老库中的老数据复制到新库中；
3. 以老库为准校对新库中的老数据；
4. 修改应用配置和代码，去掉双写，部署。

备注：双写是通用方案。

六、分库分表总结

• 分库分表，首先要知道瓶颈在哪里，然后才能合理地拆分（分库还是分表？水平还是垂直？分几个）。
• 选key很重要，既要考虑到拆分均匀，也要考虑到非partition key地查询。
• 只要能满足需求，拆分规则越简单越好。

七、分库分表示例（ Sharding-JDBC ）

代码

上手优惠