一、数据库瓶颈
不论是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的查问。
- 只有能满足需要，拆分规定越简略越好。