MySQL 中的数据编辑过程中涉及的两阶段提交

志前面已经介绍过了，就不再介绍了，简单的聊一聊 binlog 文件，binlog 是 MySQL server 层提供的二进制文件，因此所有的存储引擎都可以使用 binlog 功能，binlog 是追加写的逻辑日志，记录了执行语句的原始逻辑，文件写到指定大小后会切换到下一个文件继续写，并不会覆盖以前写过的日志文件。

binlog 日志文件主要用于数据恢复和集群环境下各服务器之间的数据同步，在工作中，我们误删了数据或者表之类，如果需要恢复的话都是利用 binlog 日志来恢复的，所以 binlog 日志是 MySQL 数据库中比较重要的模块。

知道这两个日志之后，我们把重点回到 MySQL 数据库两阶段提交，前面我们说了两阶段提交发生在数据变更期间，为了更好的理解两阶段提交，



 

个步骤：

1、执行器先找引擎取 id=2 这一行数据，如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器;否则，需要先从磁盘读入内存，然后再返回。

2、执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。

3、引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。

4、执行器生成这个操作的 binlog，并把 binlog 写入磁盘。

5、执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交(commit)状态，更新完成。

在这五步中，注意用红颜色标出来的部分，redo 日志被分割成 prepare 和 commit 两个阶段提交，这个过程称为两阶段提交，不将 redo 日志拆分成两步提交行不行?

我们可以用反推法来证明，假设不使用两阶段提交，那么就有两种情况，一种是先提交 redo 日志再提交 binlog 日志，另一种是先提交 binlog 日志再提交 redo 日志，一起来看看这两种提交方式有什么问题?

先写 redo log 后写 binlog。假设在 redo log 写完，binlog 还没有写完的时候，MySQL 进程异常重启。在这个过程中更新发生了异常，redo 日志是

（编辑：长春站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!