共计 2424 个字符，预计需要花费 7 分钟才能阅读完成。
一、数据库瓶颈
不论是 IO 瓶颈，还是 CPU 瓶颈，最终都会导致数据库的沉闷连接数减少，进而迫近甚至达到数据库可承载沉闷连接数的阈值。在业务 Service 来看就是，可用数据库连贯少甚至无连贯可用。接下来就能够设想了吧(并发量、吞吐量、解体)。
1、IO 瓶颈
第一种：磁盘读 IO 瓶颈，热点数据太多，数据库缓存放不下，每次查问时会产生大量的 IO，升高查问速度 -> 分库和垂直分表。第二种：网络 IO 瓶颈，申请的数据太多，网络带宽不够 -> 分库。
2、CPU 瓶颈
第一种：SQL 问题，如 SQL 中蕴含 join，group by，order by，非索引字段条件查问等，减少 CPU 运算的操作 -> SQL 优化，建设适合的索引，在业务 Service 层进行业务计算。第二种：单表数据量太大，查问时扫描的行太多，SQL 效率低，CPU 率先呈现瓶颈 -> 程度分表。
二、分库分表
1、程度分库
概念：以字段为根据，依照肯定策略(hash、range 等)，将一个库中的数据拆分到多个库中。后果：
- 每个库的构造都一样;
- 每个库的数据都不一样，没有交加;
- 所有库的并集是全量数据;
场景：零碎相对并发量上来了，分表难以基本上解决问题，并且还没有显著的业务归属来垂直分库。剖析：库多了，io 和 cpu 的压力天然能够成倍缓解。
2、程度分表
概念：以字段为根据，依照肯定策略(hash、range 等)，将一个表中的数据拆分到多个表中。
后果：
- 每个表的构造都一样;
- 每个表的数据都不一样，没有交加;
- 所有表的并集是全量数据;
场景：零碎相对并发量并没有上来，只是单表的数据量太多，影响了 SQL 效率，减轻了 CPU 累赘，以至于成为瓶颈。举荐：一次 SQL 查问优化原理剖析剖析：表的数据量少了，单次 SQL 执行效率高，天然加重了 CPU 的累赘。
3、垂直分库
概念：以表为根据，依照业务归属不同，将不同的表拆分到不同的库中。
后果：
- 每个库的构造都不一样;
- 每个库的数据也不一样，没有交加;
- 所有库的并集是全量数据;
场景：零碎相对并发量上来了，并且能够形象出独自的业务模块。剖析：到这一步，基本上就能够服务化了。例如，随着业务的倒退一些专用的配置表、字典表等越来越多，这时能够将这些表拆到独自的库中，甚至能够服务化。再有，随着业务的倒退孵化出了一套业务模式，这时能够将相干的表拆到独自的库中，甚至能够服务化。
4、垂直分表
概念：以字段为根据，依照字段的活跃性，将表中字段拆到不同的表 (主表和扩大表) 中。
后果：
- 每个表的构造都不一样;
- 每个表的数据也不一样，一般来说，每个表的字段至多有一列交加，个别是主键，用于关联数据;
- 所有表的并集是全量数据;
场景：零碎相对并发量并没有上来，表的记录并不多，然而字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大。以至于数据库缓存的数据行缩小，查问时会去读磁盘数据产生大量的随机读 IO，产生 IO 瓶颈。剖析：能够用列表页和详情页来帮忙了解。垂直分表的拆分准则是将热点数据 (可能会冗余常常一起查问的数据) 放在一起作为主表，非热点数据放在一起作为扩大表。这样更多的热点数据就能被缓存下来，进而缩小了随机读 IO。拆了之后，要想取得全副数据就须要关联两个表来取数据。但记住，千万别用 join，因为 join 不仅会减少 CPU 累赘并且会讲两个表耦合在一起(必须在一个数据库实例上)。关联数据，应该在业务 Service 层做文章，别离获取主表和扩大表数据而后用关联字段关联失去全副数据。
三、分库分表工具
- sharding-sphere：jar，前身是 sharding-jdbc;
- TDDL：jar，Taobao Distribute Data Layer;
- Mycat：中间件。
注：工具的利弊，请自行调研，官网和社区优先。
四、分库分表步骤
依据容量 (以后容量和增长量) 评估分库或分表个数 -> 选 key(平均)-> 分表规定(hash 或 range 等)-> 执行(个别双写)-> 扩容问题(尽量减少数据的挪动)。
五、分库分表问题
1、非 partition key 的查问问题
基于程度分库分表，拆分策略为罕用的 hash 法。端上除了 partition key 只有一个非 partition key 作为条件查问
映射法
基因法
注：写入时，基因法生成 user_id，如图。对于 xbit 基因，例如要分 8 张表，23=8，故 x 取 3，即 3bit 基因。依据 user_id 查问时可间接取模路由到对应的分库或分表。
依据 user_name 查问时，先通过 user_name_code 生成函数生成 user_name_code 再对其取模路由到对应的分库或分表。id 生成罕用 snowflake 算法。
端上除了 partition key 不止一个非 partition key 作为条件查问
映射法
冗余法
注：依照 order_id 或 buyer_id 查问时路由到 db_o_buyer 库中，依照 seller_id 查问时路由到 db_o_seller 库中。感觉有点轻重倒置! 有其余好的方法吗? 扭转技术栈呢?
后盾除了 partition key 还有各种非 partition key 组合条件查问
NoSQL 法
冗余法
2、非 partition key 跨库跨表分页查问问题
基于程度分库分表，拆分策略为罕用的 hash 法。
注：用 NoSQL 法解决(ES 等)。
3、扩容问题
基于程度分库分表，拆分策略为罕用的 hash 法。
程度扩容库
(降级从库法)
注：扩容是成倍的。
程度扩容表(双写迁徙法)
- 第一步：(同步双写)批改利用配置和代码，加上双写，部署;
- 第二步：(同步双写)将老库中的老数据复制到新库中;
- 第三步：(同步双写)以老库为准校对新库中的老数据;
- 第四步：(同步双写)批改利用配置和代码，去掉双写，部署;
注：双写是通用计划。
六、分库分表总结
- 分库分表，首先得晓得瓶颈在哪里，而后能力正当地拆分(分库还是分表? 程度还是垂直? 分几个?)。且不可为了分库分表而拆分。
- 选 key 很重要，既要思考到拆分平均，也要思考到非 partition key 的查问。
- 只有能满足需要，拆分规定越简略越好。