分库分表

一，数据库瓶颈问题
不管是IO瓶颈还是cpu瓶颈，最终都会导致数据库的活跃连接数增加，进而逼近甚至到达数据库可承载活跃链接阈值，在业务service来看就是，可用数据库连接数少甚至无连接可用。
1，IO瓶颈
第一种磁盘读写IO瓶颈，热点数据太多，数据库缓存放不下，每次查询时会产生大量的IO，降低查询速度 -》分库和垂直分表
第二种：网络IO瓶颈，请求的数据太多，网络宽带不够 -》分库。
2，cpu瓶颈
第一种：sql问题，如sql中包含join,group by ,order by ,非索引字段条件查询，增加cpu运算-》sql优化，建立合适的索引，在业务层进行计算
第二种：单表数据量太大，-》水平分表
二，分库分表
1，水平分库
以字段为依据，按照一定的策略（hash等），将一个库 中的数据拆分到多个库中
比如根据userId取模（userid%2=0），取出=0放第一个库，取出=1放第二个库
或者根据业务，比如订单来源（内部订单 ，第三方订单）进行拆分。
结果：
每个库的结构都一样；每个库的数据都不一样，没有交集。所有库的并集就是全量数据
应用 的场景
系统并发量上来，分表难以解决问题，并且没有明显的业务归属来垂直分库。
2，水平分表
以字段为依据，按照一定的策略（hash range等），将一个表中的数据拆分到多个表中
结果：
每个表的结构一样，每个表的数据不一样，没有交集，所有表的并集是全量数据
应用 的场景
系统绝对并发量并没有上来，只是单表数量太多，影响了sql效率，加重cpu负担，以至于成为瓶颈
分析：
表的数据量少了，单次sql执行效率高，自然减轻了cpu负担
3， 垂直分库
以表为依据，按照业务归属不同，将不同的表拆分到不同的库中，比如所有配置表存一个库，订单表一个库，用户权限一个库。
结果：
每个库的结构都不一样，数据也不一样，没有交集，所有库的并集是全量数据
场景：
系统绝对并发量上来了，并且可以抽象出单独的业务模块
分析：
到这一步，基本就可以服务化了，例如,随着业务的发展一些公用的配置表，字典表等越来越多，这时可以将这些表拆分到单独的库中，甚至可以服务化。
4，垂直分表
以字段为依据，按照字段的活跃度，将表中字段拆分到不同的表中（主表和扩展表）
结果：
每个表结构不一样，每个表数据也不一样，一般来说，每个表的字段至少有一列交集，一般是主键用于关联数据，所有表的并集是全量数据。
场景：
系统绝对并发量并没有上来，表的记录并不多，但是字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间大，以至于数据库缓存的数据行减少，查询时会去读磁盘数据产生大量的随机读Io，产生IO瓶颈
分析：
可以用列表页和详情页来帮助理解，垂直分表的拆分原则是将热点数据放在一起作为主表，非热点数据放在一起作为扩展表，这样更多的热点数据就能够被缓存下来，进而减少了随机读IO，拆了之后要想获取全量数据需要关联两表来取数据。
关联数据应该在业务service层做文章，分别获取主表和扩展表数据然后用关键字段关联得到全量数据。
三， 分库分表工具
Sharding-jdbc 这种clent层方案的优点在于不用部署，运营成本比较低
Mycat这种proxy层方案需要部署，自己运营一套中间件，运营成本高，好处对于各个项目是透明的，升级简单。
分库分表步骤：
根据容量（当前容量和增长量）评估分库分表个数-》选key->分表规则（hash或range）-执行-扩容问题
分库分表问题
1，非主键的查询问题（水平分库分表，拆分策略为常用hash法）
单key业务
索引表法，缓存映射法
查询字段和key的映射关系存储到缓存中，找到key后进行取模找出表。