面试笔记——MySQL（主从同步原理、分库分表）

主从同步原理

主从同步结构：主库负责写数据，从库负责读数据，如图——

MySQL主从复制的核心就是二进制日志（BINLOG），它记录了所有的 DDL（数据定义语言）语句和 DML（数据操纵语言）语句，但不包括数据查询（SELECT、SHOW）语句。

具体的同步流程为：当主库的数据发生变化，会把操作语句写入到binlog的文件中；从库的IOthread专门从主库的binlog中读取数据；读取完成之后，就会把数据写入到从库的中继日志Relay log中；再由从库的SQLthread线程读取Relay log，并执行里面的命令；执行完成之后，主库与从库的数据就会保持一致。

复制分成三步：

1. Master 主库在事务提交时，会把数据变更记录在二进制日志文件 Binlog 中。
2. 从库读取主库的二进制日志文件 Binlog ，写入到从库的中继日志 Relay Log 。
3. slave重做中继日志中的事件，将改变反映它自己的数据。

分库分表

主从架构虽然可以让读写分开操作，解决了分担了数据库的访问压力，但是不能解决海量存储的问题。

分库分表的时机：

1. 前提，项目业务数据逐渐增多，或业务发展比较迅速（在企业项目中，单表的数据量达1000W或20G以后，就需要进行分库分表）
2. 优化已解决不了性能问题（主从读写分离、查询索引…）
3. IO瓶颈（磁盘IO、网络IO）、CPU瓶颈（聚合查询、连接数太多）

分库分表——解决海量存储问题：

拆分策略

垂直拆分： 包括垂直分库和垂直分表；
水平拆分： 包括水平分库和水平分表；

垂直分库： 以表为依据，根据业务将不同表拆分到不同库中。
特点：

• 按业务对数据分级管理、维护、监控、扩展
• 在高并发下，提高磁盘IO和数据量连接数

垂直分库，如图所示：

垂直分表： 以字段为依据，根据字段属性将不同字段拆分到不同表中。
拆分规则：

• 把不常用的字段单独放在一张表
• 把text，blob等大字段拆分出来放在附表中

特点：

• 冷热数据分离（经常被查询的数据称为热数据；相反，不常用的数据称为冷数据）
• 减少IO过渡争抢，两表互不影响

垂直分表，如图所示（注意在实际应用中，拆表不一定要在不同的库中进行，拆分成两个表就行了）：

水平分库： 将一个库的数据拆分到多个库中。
特点：

• 解决了单库大数量，高并发的性能瓶颈问题
• 提高了系统的稳定性和可用性

水平分库，如图所示：

路由规则：

• 根据id节点取模
• 按id也就是范围路由，节点1(1-100万 ),节点2(100万-200万)
• …

水平分表： 将一个表的数据拆分到多个表中(可以在同一个库内)。
特点：

• 优化单一表数据量过大而产生的性能问题;
• 避免IO争抢并减少锁表的几率;

水平分表，如图所示：

新的问题和新的技术

分库之后的问题：

• 分布式事务一致性问题
• 跨节点关联查询
• 跨节点分页、排序函数
• 主键避重

分库分表中间件：

• sharding-sphere
• mycat

使用分库分表中间件可以降低开发的难度，解决分库分表之后可能会遇到的问题：

总结——具体拆分策略：

1. 水平分库，将一个库的数据拆分到多个库中，解决海量数据存储和高并发的问题
2. 水平分表，解决单表存储和性能的问题
3. 垂直分库，根据业务进行拆分，高并发下提高磁盘IO和网络连接数
4. 垂直分表，冷热数据分离，多表互不影响
5. 注意：使用水平拆分策略时，需要使用中间件（sharding-sphere、mycat）来避免分库之后可能遇到的问题。