Mysql分库分表

为什么要分库分表？

原文链接：原文链接

我没有用过分库分表，靠着这篇博客了解的

关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后，由于查询维度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。

而切分数据库和表的方式就两种，垂直切分和水平切分

数据库瓶颈产生原因和解决办法

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

IO瓶颈

第一种：

磁盘读IO瓶颈，热点数据太多，数据库缓存放不下，每次查询会产生大量的IO，降低查询速度->分库和垂直分表

第二种：

网络IO瓶颈，请求的数据太多，网络带宽不够 ->分库

CPU瓶颈

第一种：

SQl问题：如SQL中包含join,group by, order by，非索引字段条件查询等，增加CPU运算的操作->SQL优化，建立合适的索引，在业务Service层进行业务计算。

第二种：

单表数据量太大，查询时扫描的行太多，SQl效率低，增加CPU运算的操作。->水平分表。

分库分表

水平分库

一张表的数据通过不同的分发策略发送到不同的数据库中

• 两个数据库中的表结构完全一致
• 他们的数据完全不同
• 两个库中的所有数据的并集是全部的数据

适用场景：
库多了，并发就上去了，解决了你的并发量问题

垂直分库

根据表中业务的不同来进行划分不同字段到不同的库中

• 每个库中表结构都不同
• 每个库中数据和字段不一样
• 所有库的并集是全量数据

适用场景：

划分成多个库，提高了并发度，并且需要按照业务模块划分到不同表中

表中业务模块都定义好的情况下，才能够使用，否则后期使用是灾难

水平分表

将一张表的数据按照某种策略拆分到多个表中

• 每个表的字段结构都相同
• 每个表的数据不一样
• 所有表的并集是全部的数据

适用场景：

系统并发量没有到瓶颈，就是单表数据过多，导致查询缓慢，加重了CPU的负担，这种情况可以使用水平分表

垂直分表

将一张表的字段按照字段的活跃性拆分到不同的表中

• 每个表的字段结构不一样
• 每个表的数据没有相同的，但是会有一个交集，通常是一个主键，用于关联数据
• 所有表的并集是全部的数据

适用场景：

并发量没有上来，表的记录并不多，但是字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大，以至于数据库缓存的数据行减少，查询时回去读磁盘数据产生大量随机读IO，产生IO瓶颈。
总结就是，字段太多，查询时产生大量io，产生io瓶颈，导致查询慢，可以使用这种方式

分库分表工具

1. List item
2. sharding-jdbc（当当）
3. TSharding（蘑菇街）
4. Atlas（奇虎360）
5. Cobar（阿里巴巴）
6. MyCAT（基于Cobar）
7. Oceanus（58同城）
8. Vitess（谷歌） 各种工具的利弊自查