MySQL优化--主从同步，分库分表
目录
MySQL主从同步原理
MySQL主从复制的核心就是二进制日志
面试回答
分库分表
分库分表的时机
分库分表的策略
垂直分库
垂直分表
水平分库
水平分表
分库分表的策略
分库之后的问题
面试回答
MySQL主从同步原理
如果项目上线了，通常情况下，会去搭建主从的架构，一个JAVA应用，首先要去廉价而数据库的中间件，中间件其中至少连接了两个库。当主库写数据的时候，就要把数据同步到从库，那是如何进行同步的呢？原理又是什么呢?
MySQL主从复制的核心就是二进制日志
二进制日志（BINLOG）记录了所有的 DDL（数据定义语言CREATE,DROP,OUT）语句和 DML（数据操纵语言INSERT,UPDATE,DELETE）语句，但不包括数据查询（SELECT、SHOW）语句。
同步流程是这样的，当主库数据发生了变化，比如是一个写操作，也可以是DDL或者是DML，会把这些数据写到一个blog日志文件中，这时候，从库有一个IOthread线程，专门从主库的blog日志文件中读取数据，读取完成后，就会写入到从库的中继日志中，叫做Relay log。
再由从库的SQLthread线程来读取中继日志的文件，把里面的命令在重新执行一次，执行完之后，主库和从库不就保持同步了吗
复制主要分成三步：
Master 主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中。
从库读取主库的二进制日志文件 Binlog ，写入到从库的中继日志 Relay Log 。
slave重做中继日志中的事件，将改变反映它自己的数据。
面试回答
面试官：MySQL主从同步原理
候选人：MySQL主从复制的核心就是二进制日志(DDL（数据定义语言）语句 和 DML（数据操纵语言）语句)，它的步骤是这样的：
第一：主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中。
第二：从库读取主库的二进制日志文件 Binlog ，写入到从库的中继日志 Relay Log 。
第三：从库重做中继日志中的事件，将改变反映它自己的数据
分库分表
在主从同步阶段，主库和从库的数据是一样的，主要解决的是访问的压力，让读写分开进行，它是解决不理海量数据存储的问题的，这个时候，就需要分库分表
当然分库分表也不是一开始就需要的，而是有前提的
分库分表的时机
1，前提，项目业务数据逐渐增多，或业务发展比较迅速（单表的数据量达1000W或20G以后 ）
2，优化已解决不了性能问题（主从读写分离、查询索引…）
3，IO瓶颈（磁盘IO、网络IO）、CPU瓶颈（聚合查询、连接数太多）
分库分表主要解决的是存储的压力，本来只有一个库，现在分了多个库进行存储，是不是就可以存储更多的数据，同时因为我有多个库，那我每一个节点是不是都可以处理用户的请求呢，是不是就可以增加用户的连接数
分库分表的策略
垂直分库
以表为依据，根据业务将不同表拆分到不同库中。
如图，这是一张电商的数据库，前面两张都是和用户有关系，中间两张都是和订单有关系，后面两张是和商品有关系
所以现在我们可以根据不同的业务将不同的表存储到数据库中，这就是典型的垂直分库。而微服务不就是不同的服务对应不同的数据库，如图，不同的服务与不同的数据库相对应
特点：
1，按业务对数据分级管理、维护、监控、扩展
2，在高并发下，提高磁盘IO和数据量连接数
垂直分表
以字段为依据，根据字段属性将不同字段拆分到不同表中。
拆分规则：
1，把不常用的字段单独放在一张表
2，把text，blob等大字段拆分出来放在附表中
如图，前面的字段都是对于商品的基本描述，而最后的description描述则是大文本内容，所以我们将表拆为基本信息和详细信息，这两个表分别存储不同的数据，其中两张表之间是1对1的关系
特点：
1，冷热数据分离
2，减少IO过渡争抢，两表互不影响
水平分库
将一个库的数据拆分到多个库中。
当数据量越来越大，如果还放在一起可能会影响性能，这个时候我们就需要把他拆到各个库中进行存储。
如图，每个库中存储的数据是不一样的，所有的库加起来，才是这个订单业务的所有的数据，但是此时出现了一个问题，现在有三个库，那我们应该如何找到数据并且进行查询呢？
在我们查询的时候，其实是有一些路由的规则
1，根据id节点取模
2，按id也就是范围路由，节点1(1-100万 ),节点2(100万-200万)
…
特点：
1，解决了单库大数量，高并发的性能瓶颈问题
2，提高了系统的稳定性和可用性
水平分表
将一个表的数据拆分到多个表中(可以在同一个库内)。
特点：
优化单一表数据量过大而产生的性能问题;
避免IO争抢并减少锁表的几率;
分库分表的策略
在一开始的时候，我们的应用程序只是连接了其中的一个库，
现在我们一个应用程序连接了三个库，还要按照取模的方式去找到各个数据库，假如后面因为业务要求，又做了集群，实现起来就会越来越复杂，就会产生一系列的问题
分库之后的问题
1，分布式事务一致性问题
现在有多个库，多个表，现在要同时操作在不同数据库中的不同的表，每一个库都会管理自己的事务，假如有一个库它的提交失败了，这个时候是不是就会产生事务不一致的问题
2，跨节点关联查询
假如做了分库分表，现在你的a库和b库分别存储的是不同的表，两张表还要进行关联，这个又怎么做呢
3，跨节点分页、排序函数
和2一样，这种排序，分页又要怎么做呢，即使说是取模，那有应该怎么去分页查询这些数据呢
4，主键避重
假如现在做了水平分库，每个库中存储的都是相同的表，每个表中的id可能都是自增的，会不会出现id重复的情况呢
为了避免上述问题的产生，一般在项目中使用分库分表的话，都会去增加一个中间件，进行关联，并且可以帮助我们降低开发的难度，并且可以帮助我们解决上述的问题
分库分表中间件。比如：
sharding-sphere
mycat
面试回答
面试官：你们项目用过MySQL的分库分表吗？
候选人： 嗯，因为我们都是微服务开发，每个微服务对应了一个数据库，是根据业务 进行拆分的，这个其实就是垂直拆分。
面试官：那你之前使用过水平分库吗？
候选人： 嗯，这个是使用过的，我们当时的业务是(xxx)，一开始，我们也是单库，后 来这个业务逐渐发展，业务量上来的很迅速，其中(xx)表已经存放了超过 1000万的数据，我们做了很多优化也不好使，性能依然很慢，所以当时就使 用了水平分库。
我们一开始先做了3台服务器对应了3个数据库，由于库多了，需要分片，我 们当时采用的mycat来作为数据库的中间件。数据都是按照id（自增）取模 的方式来存取的。
当然一开始的时候，那些旧数据，我们做了一些清洗的工作，我们也是按照 id取模规则分别存储到了各个数据库中，好处就是可以让各个数据库分摊存 储和读取的压力，解决了我们当时性能的问题