MySQL是如何保证数据一致性的？

以你之姓@ 2024-02-05 21:23 55阅读 0赞

#### 文章目录 ####

*  前言
 *  MySQL保证的一致性
 *  MySQL发生不一致环节
 *   *  并发冲突
     *  redolog不完整
     *  binlog&redolog不一致
 *  MySQL解决不一致方案
 *   *  加锁解决并发冲突
     *  undolog解决redolog不完整
     *  XA两阶段提交解决binlog和redolog的不一致
 *  总结

## 前言 ##

通过上文[《MySQL是如何保证数据不丢失的？》][MySQL]可以了解DML的操作流程以及数据的持久化机制。对于一个数据库而言，除了数据的持久性、不丢失之外，一致性也是非常重要的，不然这个数据是没有任何意义的。在使用MySQL时，数据不一致的情况也可能出现，所以，本文就来看看MySQL是如何保证数据一致的。

## MySQL保证的一致性 ##

在这之前先划清一下界限，看一下MySQL保证的是哪里的一致性。

拿一个最简单的转账例子，用户A向用户B转1000元，正常的sql是这样的

update account set balance=balance-4000 where user='A' and balance >= 4000;
    update account set balance=balance+4000 where user='B';

示例表数据如下  
![在这里插入图片描述][efa3525c490844d387cf8ab709dee031.png]  
如果最终用户A账户没有扣4000，而用户B账户多了4000，总金额也无缘无故的多了4000。这个时候就造成了数据不一致了。出现这个问题可能存在几个原因：

1.  在MySQL客户端执行sql时没有做校验。如果用户A余额并不足以4000，由于没有校验，两条sql都会成功执行，用户B就会凭空多出4000。
2.  两条sql并不在同一事务中。可能sql1执行失败了，sql2执行成功，由于不再一个事务中导致用户B多了4000。
3.  在MySQL内部执行时因为某些故障而出现了不一致情况。

很显然，第三点是需要MySQL解决处理的。而第一点是属于MySQL客户端的逻辑BUG，第二点会存在客户端在使用事务时不遵循规则的情况，都属于外部因素，**MySQL不可控**。

所以，MySQL保证的一致性是：**在一个事务中的DML（增删改）操作。尽管DML本身可能存在问题。**

## MySQL发生不一致环节 ##

划清界限后再分析一下在DML执行过程中，哪个环节会发生数据不一致。 以上面的sql为例，假设已经进行过校验且在同一事务。

### 并发冲突 ###

在执行第一条sql时，「**执行器**」会通过条件`user='A' and balance >= 4000`在「**存储引擎**」获取到符合条件的记录，然后进行balance扣减操作。（不知道这个流程的可以看下前面的文章）

如果这个时候存在并发现象，扣减操作可能会执行多次，这个balance肯定就不是预想中的结果了，也就发生数据不一致了。如下图

![在这里插入图片描述][9146cca50ee7484f9a09bd4d7ef6e717.png]

当3个update请求同一时间调用存储引擎对同一数据页更新后，正常情况下，balance值应该为0。但是因为并发操作，balance的值可能会被修改为-1000或者-2000等其他值，这样的bug显然是不可被接受的。

有并发经验的应该都知道需要通过锁资源可以避免这个情况，InnoDB也是通过加**锁**来处理的。

### redolog不完整 ###

通过上文可以知道，InnoDB是通过「**双写缓冲**」、「**Redo Log**」等机制保证数据不丢失的。

这种情况下，假设第一条sql执行成功并且对应的redo log已经被刷新到磁盘中，但是第二条sql执行失败或者MySQL服务宕机导致其redolog未刷新到磁盘，那么在下次启动恢复时，就会发生数据不一致了。如下图

![在这里插入图片描述][b218d4c922c945f5a2d90bd55872ed3e.png]

sql示例的第一条执行结果通过redolog恢复了，但是第二条的redolog随着宕机丢失了，于是乎造成了数据的不一致。（redo log的刷盘机制和构建脏页可以通过上文进行了解。）

对于这种情况，InnoDB是通过上文提到的「**Undo Log**」来解决的。

### binlog&redolog不一致 ###

我们知道，binlog中记录了所有对数据更新的原始sql，以便数据备份恢复、主从复制。与redolog不一样的是binlog属于MySQL server层，而redolog是InnoDB的机制，用于故障恢复，两者并不冲突，这里不过多赘述。

虽然不冲突，但是要保证两者在事务提交后都可以持久化到磁盘，不然就会在主从复制的时候出现数据不一致现象，如下图

![在这里插入图片描述][482e29dd8ee84b588d429844d2b80b48.png]

只要binlog和redolog有一方没有同步持久到磁盘都会发生类似现象。针对这种情况MySQL是通过**两阶段提交**解决的。

以上就是DML在执行过程中可能出现不一致的环节（没有想到的欢迎评论交流）。接下来具体看一下InnoDB针对以上几种情况是如何处理解决，从而保证数据一致性的。

## MySQL解决不一致方案 ##

### 加锁解决并发冲突 ###

锁没有什么好说的，innoDB根据隔离级别决定是否用锁(当然，还有server层的表锁什么的这里不展开)。这里就演示下在隔离级别`REPEATABLE-READ`下，锁在SQL执行中的具体作用和效果。

当在第一个事务中执行 `update account set balance=balance-4000 where user='A' and balance >= 4000;` 时，其他事务不能对user为’A’的记录进行更新。如下图，当第二个事务窗口执行 `update account set balance=balance-1000 where user='A' and balance >= 1000;` 时会被阻塞住，直到第一个事务提交或者超时。

![在这里插入图片描述][53118574fb8a409aa96212a25075ad57.png]

这个时候可以通过 `select * from sys.innodb_lock_waits ;` 查看一下锁的相关信息

![在这里插入图片描述][d90f1aef44284f97a682ef5252afe7be.png]

这里的`locked_type`是RECORD，也就是行记录锁，还有一个是间隙锁。

间隙锁的作用是保证某个范围内的数据在锁定情况下不会发生任何变化。比如，当第一个事务执行`update account set balance=balance-100 where id between 7 and 9;`后，第二个事务在执行`INSERT INTO account (id, user,balance) VALUES (8, 'ABD',5000);`时会阻塞，但是执行 `INSERT INTO account (id, user,balance) VALUES (16, 'ABDD',5000);`会成功执行，因为插入id为16的行数据不会影响到7～9之间的数据。这个时候去查看`select * from sys.innodb_lock_waits;`时会发现`waiting_lock_mode`值为 `X,GAP（间隙）`。

![在这里插入图片描述][3e2d5ccc0ed74fc4a2b10ec8dd9473f8.png]

**所以说，锁避免了事务的并发访问导致的数据不一致。**

### undolog解决redolog不完整 ###

InnoDB在因sql执行失败或者MySQL服务宕机导致redolog不完整从而出现数据不一致是这么解决的：

1.  在更新数据页之前，InnoDB会先将数据当前的状态记录在「**Undo Log**」中。
2.  之后，再将更新后的相关数据记录到「**Redo Log**」中。

这样的话，不论出现哪种情况都可以通过undo log将数据回滚并保持一致，这个就是经常提到的原子性以及「**回滚**」操作。

就如上图（redo log不完整环节），加上Undo log之后数据状态如下图

![在这里插入图片描述][4c97cb8fc8cc46658ced32b71fa75ad3.png]

图中加了行记录的隐藏字段事务ID和回滚指针以及undo log页和undo的redo。

undo log 记录的就是user='A’和‘B’事务提交前的数据，各为4000。

redo log 中会记录所有的更新操作，包括undo，因为undo记录的也是更新语句。需要说一下，这里记录的undo是演示使用，对于一条update操作，真正的undo会记录一条delete和一条insert操作，原因上文有介绍。

> 为什么redo log会记录undo

undo log是以页为单位，跟随页的刷新机制，会存在丢失的情况，所以在记录undo后也会将该undo记录到redo，避免undo丢失，一旦undo丢失就回滚不了了。

有了undo log后，假设第二条sql执行失败，这个时候就会通过行记录中的事务ID（txidx）和回滚指针（roll\_pointx、roll\_pointx1）去undolog中找对应的回滚操作（如图中的 ‘\*\*回滚指针’\*\*箭头），最终将事务回滚保证原子性和一致性。

针对上图的状态，如果发生宕机，那么在重新MySQL服务时，会有两个操作：

1.  会先通过redo log构建「**脏页**」。
2.  根据redo log中记录的事务提交状态来决定是否回滚。

如图

![在这里插入图片描述][80250053895a4f5f99939d1440d15572.png]

当前user='A’的事务状态为prepare，所以需要进行回滚操作。回滚流程是这样的：

1.  根据数据中该记录的事务ID（txidx）在undolog中找对应的回滚操作。
2.  发现事务ID有两个undo操作，user='A’和‘B’的。
3.  执行undo操作，将数据页中的记录回滚至事务提交前状态。

最终的结果就是user='A’和‘B’的balance会回滚到4000。

**所以说，undo避免了事务或者宕机的异常导致的数据不一致。**

### XA两阶段提交解决binlog和redolog的不一致 ###

redo log中的事务状态不仅在这里起到作用，在binlog和redolog的一致上，同样是通过这个状态来判断并且决定是否需要回滚。

这个就不得不说到MySQL的XA两阶段提交协议了，在这之前，我一直以为XA是运用到MySQL与外部应用的，没想到是应用在MySQL内部的。不过分布式事务嘛，原理基本上都一样，想要深入了解的可以看[《分布式事务及解决方案》][Link 1]，这里就不过多赘述了。

XA的两阶段分别是prepare和commit，在事务提交前，redolog中记录的状态都是prepare，当事务提交后，该状态就会被更新为commit，同时将XID写入到对应的binlog中并刷新到磁盘。如下图

![在这里插入图片描述][296d8cb0567149ff97585856a6df18e9.png]

这样的话，如果发生宕机，下次启动时可以根据redolog中的状态以及XID去binlog中查找，如果存在意味着两者一致，不存在就进行回滚操作。

**所以说，XA两阶段提交保证了binlog和redolog逻辑一致，从而避免主从节点的数据不一致。**

## 总结 ##

MySQL一致性的保证基本上涉及到InnoDB存储引擎的各个组件，「Buffer Pool」、「Log Buffer」、「Redo Log」、「Undo Log」等，还有DML操作的流程、锁、故障恢复等功能。最后再总结下MySQL是如何保证一致性的。

1.  对于并发操作带来的数据不一致性问题，InnoDB通过锁来解决。
2.  对于可能会发生的redolog不完整的情况，InnoDB通过Undo Log来解决。
3.  对于redolog&binlog不一致带来的主从节点数据不一致，MySQL是通过XA两阶段提交来解决。

[MySQL]: https://wangbinguang.blog.csdn.net/article/details/135090703
[efa3525c490844d387cf8ab709dee031.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/1afcc8a926ab4c999c49213218462099.png
[9146cca50ee7484f9a09bd4d7ef6e717.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/95ad7f508be949768c711f26de7f6bb3.png
[b218d4c922c945f5a2d90bd55872ed3e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/529df28069eb43c8a4cb17ee0849b115.png
[482e29dd8ee84b588d429844d2b80b48.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/07aba53e710841cea102d8a2188b1726.png
[53118574fb8a409aa96212a25075ad57.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/f7aafd6dd1f742688faf4d92d3b92a55.png
[d90f1aef44284f97a682ef5252afe7be.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/be7ac837abfa426d8d6b48427e08a1f7.png
[3e2d5ccc0ed74fc4a2b10ec8dd9473f8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/753a5870d06441c28cb3be1b617cfb9f.png
[4c97cb8fc8cc46658ced32b71fa75ad3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/034e4f00aed846ec96d5cc39bd479f48.png
[80250053895a4f5f99939d1440d15572.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/d72d225389714f11899cd0df582b44fa.png
[Link 1]: https://wangbinguang.blog.csdn.net/article/details/125355907
[296d8cb0567149ff97585856a6df18e9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/01/30/2e3ea7f661764de0b41d03bf741179fd.png