大家好，我是小白，好长时间没更新技术文了，相信大家看我写的水文也看烦了。

![](https://xiaobaidebug.oss-cn-hangzhou.aliyuncs.com/image/1539510639669-20220302001234401.jpg)

今天的文章，其实来自真实的面试题，而且还比较有趣，所以忍不住分享出来。

直接开始吧。

我们知道，mysql数据库，为了得到更高性能，一般会**读写分离**，主库用于写操作，比如用于执行`insert，update`操作，从库用于读，也就是最常见的`select`操作。像下面这个图这样。

![mysql读写分离](https://xiaobaidebug.oss-cn-hangzhou.aliyuncs.com/image/mysql%E8%AF%BB%E5%86%99%E5%88%86%E7%A6%BB2.drawio-20220419205818771.png)

虽然主库一般用于写操作，但也是**能读**的。那么今天的问题来了。

- 主库更新后，**主库**都读到最新值了，**从库**还有可能读到旧值吗？

- 主库更新后，**从库**都读到最新值了，**主库**还有可能读到旧值吗？

毕竟面试官都这么问了，那当然是有可能的，那至于是为啥，以及怎么做到的，今天我们来好好聊聊。

### 正常的主从更新流程

比如我在主库和从库都有张user表，此时有以下两条数据。

![数据库原始状态](https://xiaobaidebug.oss-cn-hangzhou.aliyuncs.com/image/%E6%95%B0%E6%8D%AE%E5%BA%93%E5%8E%9F%E5%A7%8B%E7%8A%B6%E6%80%81.png)

正常情况下，我们往主库执行写操作，比如更新一条数据，执行

```sql
update user set age = 50 where id = 1;
```

虽然这是一个单条写操作，但本质上可以理解为单条语句的事务。等同于下面这样

```sql
begin;
update user set age = 50 where id = 1;
commit;
```

这个事务如果执行成功了，数据会先写入到主库的binlog文件中，然后再刷入磁盘。

**binlog文件**是mysql的server层日志，记录了用户对数据库有哪些变更操作，比如建数据库表加字段，对某些行的增删改等。

它的位置可以通过下面的查询语句看到。

其中binlog在 `/var/lib/mysql/` 下，命名会类似`mysql-bin.00000x`。感兴趣的可以到这个目录下直接查看文件内容长什么样子。

如果两个mysql配置好了主从的关系，那么他们之间会建立一个**tcp长连接**，主要用于传输同步数据。

除此之外，主库还会再起一个**binlog dump线程**将binlog文件的变更发给从库。

可以在**主库**中通过 `show full processlist;` 查询到 binlog dump线程的存在。

![主库的binlog dump线程](https://xiaobaidebug.oss-cn-hangzhou.aliyuncs.com/image/image-20220301084729507.png)

以上，主库的工作就结束了，我们说说从库的。

从库在收到binlog后，会有一个**io线程**负责把收到的数据写入到**relay log（中继日志）**中。

然后再有一个**sql 线程**，来读取relay log的内容，然后对从库执行sql语句操作，从结果上来看就是将主库执行过的写操作，在从库上也重放一遍，这样主从数据就一致了。

是不是感觉relay log有些多余？

**为什么要先写一遍relay log然后再写从库，直接将数据写入到从库不好吗？**

在这里relay log的作用就类似于一个**中间层**，**主库是多线程并发写的，从库的sql线程是单线程串行执行的，所以这两边的生产和消费速度肯定不同。**当主库发的binlog消息过多时，从库的relay log可以起到暂存主库数据的作用，接着从库的sql线程再慢慢消费这些relay log数据，这样既不会限制主库发消息的速度，也不会给从库造成过大压力。

可以通过在**从库**中执行 `show full processlist;` 确认 io线程和sql线程的存在。

![io线程和sql线程](https://xiaobaidebug.oss-cn-hangzhou.aliyuncs.com/image/image-20220301102221753.png)

因此总结起来，主从同步的步骤就是

**1.执行更新sql语句。**

**2.主库写成功时，binlog会更新。**

**3.主库binlog dump 线程将binlog的更新部分发给从库**

**4.从库io线程收到binlog更新部分，然后写入到relay log中**

**5.从库sql线程读取relay log内容，重放执行sql，最后主从一致。**

![mysql主从同步](https://xiaobaidebug.oss-cn-hangzhou.aliyuncs.com/image/mysql%E4%B8%BB%E4%BB%8E%E5%90%8C%E6%AD%A5-20220419210000882.png)

到这里，我们可以开始回答文章开头的第一个问题。

### 主库更新后，主库都读到最新值了，从库还有可能读到旧值吗？

这是可能的，上面提到的主从同步的5个步骤里，第3到第5步骤，都需要时间去执行，而这些步骤的执行时间总和，就是我们常说的**主从延迟**。

当更新一行数据后，立马去读主库，主库的数据肯定是最新值，这点没什么好说的，但**如果此时主从延迟过大，这时候读从库，同步可能还没完成，因此读到的就是旧值。**

在实际的开发当中，主从延迟也非常常见，当数据库压力稍微大点，主从延迟就能到100ms甚至1s以上。

具体的主从延迟时间可以在从库中执行 `show slave status \G;`来查看，其中里面的`Seconds_Behind_Master`则是主从延迟的时间，单位是秒。

```sql
mysql> show slave status \G;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 172.17.0.2
                  Master_User: slave
                Connect_Retry: 30
              Master_Log_File: mysql-bin.000002
          Read_Master_Log_Pos: 756
               Relay_Log_File: edu-mysql-relay-bin.000004
                Relay_Log_Pos: 969
        Relay_Master_Log_File: mysql-bin.000002
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
        Seconds_Behind_Master: 2

```

所以如果你有**写数据后就立马要读数据**的场景，要是此时读的是从库，很有可能会读到**更新前**的旧数据，如果你对数据一致性有较高要求，这种时候**建议读主库**。

### 主库更新后，从库都读到最新值了，主库还有可能读到旧值吗？

那另一个问题就来了，如果从库都读到最新值了，那说明**主库肯定已经更新完成了**，那此时读主库是不是只能读到最新值呢？

**还真不是的**，待会我给大家复现下，但在这之前我们了解一些**前置知识点**。

#### mysql的四种隔离级别

这个绝对是面试八股文老股了。mysql有四种隔离级别，分别是**读未提交（Read uncommitted），读提交（Read committed），可重复读（Repeatable read）和串行化（Serializable）**。在不同的隔离级别下，并发读写效果会不太一样。

当前数据库处于什么隔离级别可以通过执行 `select @@tx_isolation;` 查看到。

```sql
mysql> select @@tx_isolation;
+-----------------+
| @@tx_isolation  |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set (0.01 sec)
```

也可以通过下面的语句去修改隔离级别。

```sql
SET GLOBAL TRANSACTION ISOLATION LEVEL REPEATABLE-READ;
```

下面用一个case来让大家直观点的理解这四个隔离级别的区别。

假设我们有两个线程同时对某行数据A(A=1)进行以下操作。

![一个case解释隔离级别](https://xiaobaidebug.oss-cn-hangzhou.aliyuncs.com/image/%E4%B8%80%E4%B8%AAcase%E8%A7%A3%E9%87%8A%E9%9A%94%E7%A6%BB%E7%BA%A7%E5%88%AB.2drawio.png)

我们执行事务都像上面这样，begin可以开启事务，commit会提交事务，上面两个线程，各执行一个事务，且此时是并发执行。

线程1会将某行的A这个字段从1更新为2。

线程2啥也不干，就读A。重点关注2线程的三次读A的行为，它们会根据隔离级别的不同，读到不同的值。

**第1次读A：**

- 如果是**读未提交**，那么会读到2，顾名思义，就算线程1未提交，线程2也能读到最新的值。
- 如果是读提交或者可重复读，那读到的都是1，**读提交**只认事务提交后的数据，而**可重复读**只要线程2的事务内没有执行对A的更新sql语句，那读A的数据就会一直不变。

**第2次读A：时机正好在线程1提交了事务之后**

- 如果是读未提交，前面都读到2了，现在读到的还是2，这个没啥好说的。
- 如果是**读提交**，那读到的都是2了，因为线程1的事务提交了，**读提交**只认提交后的数据，所以此时线程2能读到最新数据。
- 如果是可重复读那就还是1，理由跟上面一样。

**第3次读A：时机正好在线程2提交了事务之后**

- 如果是读未提交或读已经提交，结果跟前面一样，还是2。
- 如果是**可重复读**，那就变成了2，因为线程2前面的事务结束了，在**同一个事务内A的值重复多次读都是一致的**，但当事务结束了之后，新的查询不再需要受限于上一次开事务时的值。

上面的情况没有将**串行化**纳入讨论范围，只讨论了**读未提交，读提交和可重复读**这三个隔离级别，因为在这三个隔离级别下都有可能出现两个事务**并发执行**的场景，而在**串行化的隔离级别**中则不会出现，多个事务只会一个挨着一个依次**串行执行**，比如线程1的事务执行完了之后，线程2的事务才执行，因此不会产生并发查询更新的问题。

有了这个知识背景之后，我们就可以回到第二个问题里了。

数据库原始状态如下，此时主从都一样。

![数据库原始状态](https://xiaobaidebug.oss-cn-hangzhou.aliyuncs.com/image/%E6%95%B0%E6%8D%AE%E5%BA%93%E5%8E%9F%E5%A7%8B%E7%8A%B6%E6%80%81-20220419205854846.png)

假设当前的数据库事务隔离级别是**可重复读**，现在主库有A，B两个线程，同时执行begin，开启事务。

此时主库的线程2，**先读一次id=1的数据**，发现age=72，**由于当前事务隔离级别是可重复读**，那么只要线程2在事务内不做更新操作的话，那么**不管重复读多少次，age都是72**。在这之后主库的线程1将age更新为100且执行commit提交了事务。

主库线程1的事务提交成功之后binlog就会顺利产生，然后同步给从库。此时**从库去查询就能查到最新值age=100**。回过头来，此时主库的线程2因为还没提交事务，所以一直读到的都是旧值age=72。但如果这时候线程2执行commit提交了事务，那么再查询，就能拿到最新值age=100了。

所以从结论上来说，**出现了从库都读到最新值了，主库却读到了旧值的情况。**

![从库读到最新值主库却读到旧值](https://xiaobaidebug.oss-cn-hangzhou.aliyuncs.com/image/2%E4%BB%8E%E5%BA%93%E8%AF%BB%E5%88%B0%E6%9C%80%E6%96%B0%E5%80%BC%E4%B8%BB%E5%BA%93%E5%8D%B4%E8%AF%BB%E5%88%B0%E6%97%A7%E5%80%BC.drawio.png)

好了这道题到这里就结束了。

意不意外？

这道面试题，通过一个问题，将主从同步，事务隔离级别等知识点都串起来了。

还是有点意思的。

那么问题又来了，这四个隔离级别是挺骚气的，那他们是怎么实现的呢？

![](https://xiaobaidebug.oss-cn-hangzhou.aliyuncs.com/image/1597215709606.gif)

**如果文章对你有帮助，欢迎.....**

算了。

###### 别说了，一起在知识的海洋里呛水吧

**关注公众号:【小白debug】

ITPub博客

mysql主库更新后，从库都读到最新值了，主库还有可能读到旧值吗？

最新文章