这四种情况下，才是考虑分库分表的时候！.docxVIP

这四种情况下，才是考虑分库分表的时候！ 不管是IO瓶颈还是CPU瓶颈，最终都会导致数据库的活跃连接数添加，进而靠近甚至达到数据库可承载的活跃连接数的阈值。在业务service来看，就是可用数据库连接少甚至无连接可用，接下来就可以想象了（并发量、吞吐量、崩溃）。 IO瓶颈 第一种：磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询会产生大量的IO，降低查询速度-分库和垂直分表 其次种：网络IO瓶颈，恳求的数据太多，网络带宽不够 -分库 CPU瓶颈 第一种：SQl问题：如SQL中包含join,group by, order by，非索引字段条件查询等，添加CPU运算的操作-SQL优化，建立合适的索引，在业务Service层进行业务计算。 其次种：单表数据量太大，查询时扫描的行太多，SQl效率低，添加CPU运算的操作。-水平分表。 水平分库 1、概念：以字段为依据，依据肯定策略（hash、range等），将一个库中的数据拆分到多个库中。 2、结果： 每个库的结构都一样 每个库中的数据不一样，没有交集 全部库的数据并集是全量数据 3、场景：系统确定并发量上来了，分表难以根本上处理问题，并且还没有明显的业务归属来垂直分库的情况下。 4、分析：库多了，io和cpu的压力自然可以成倍缓解 水平分表 1、概念：以字段为依据，依据肯定策略（hash、range等），讲一个表中的数据拆分到多个表中。 2、结果： 每个表的结构都一样 每个表的数据不一样，没有交集，全部表的并集是全量数据。 3、场景：系统确定并发量没有上来，只是单表的数据量太多，影响了SQL效率，加重了CPU负担，以至于成为瓶颈，可以考虑水平分表。 4、分析：单表的数据量少了，单次执行SQL执行效率高了，自然减轻了CPU的负担。 垂直分库 1、概念：以表为依据，依据业务归属不同，将不同的表拆分到不同的库中。 2、结果： 每个库的结构都不一样 每个库的数据也不一样，没有交集 全部库的并集是全量数据 3、场景：系统确定并发量上来了，并且可以笼统出单独的业务模块的情况下。 4、分析：到这一步，基本上就可以服务化了。例如：随着业务的进展，一些公用的配置表、字典表等越来越多，这时可以将这些表拆到单独的库中，甚至可以服务化。再者，随着业务的进展孵化出了一套业务模式，这时可以将相关的表拆到单独的库中，甚至可以服务化。 垂直分表 1、概念：以字段为依据，依据字段的活跃性，将表中字段拆到不同的表中（主表和扩展表）。 2、结果： 每个表的结构不一样。 每个表的数据也不一样，一般来说，每个表的字段至少有一列交集，一般是主键，用于关联数据。 全部表的并集是全量数据。 3、场景：系统确定并发量并没有上来，表的记录并不多，但是字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大，以至于数据库缓存的数据行削减，查询时回去读磁盘数据产生大量随机读IO，产生IO瓶颈。 4、分析：可以用列表页和详情页来挂念理解。垂直分表的拆分准绳是将热点数据（可能经常会查询的数据）放在一起作为主表，非热点数据放在一起作为扩展表，这样更多的热点数据就能被缓存下来，进而削减了随机读IO。拆了之后，要想猎取全部数据就需要关联两个表来取数据。 但记住千万别用join，由于Join不只会添加CPU负担并且会将两个表耦合在一起（必需在一个数据库实例上）。关联数据应当在service层进行，分别猎取主表和扩展表的数据，然后用关联字段关联得到全部数据。 分库分表工具 sharding-jdbc（当当） TSharding（蘑菇街） Atlas（奇虎360） Cobar（阿里巴巴） MyCAT（基于Cobar） Oceanus（58同城） Vitess（谷歌） 各种工具的利弊自查 分库分表带来的问题 分库分表能有效缓解单机和单表带来的功能瓶颈和压力，突破网络IO、硬件资源、连接数的瓶颈，同时也带来一些问题，下面将描述这些问题和处理思路。 事务全都性问题 分布式事务 当更新内容同时存在于不同库找那个，不行避开会带来跨库事务问题。跨分片事务也是分布式事务，没有简约的方案，一般可使用“XA协议”和“两阶段提交”处理。 分布式事务能最大限度保证了数据库操作的原子性。但在提交事务时需要协调多个节点，推后了提交事务的时间点，延长了事务的执行时间，导致事务在访问共享资源时发生冲突或死锁的概率增高。随着数据库节点的增多，这种趋势会越来越严峻，从而成为系统在数据库层面上水平扩展的枷锁。 最终全都性 对于那些功能要求很高，但对全都性要求不高的系统，往往不苛求系统的实时全都性，只需在允许的时间段内达到最终全都性即可，可接受事务补偿的方式。与事务在执行中发生错误马上回滚的方式不同，事务补偿是一种事后检查补救的措施，一些常见的实现方法有：对数据进行对账检查，