本文小编为大家详细介绍“MySQL的两阶段提交机制是什么”，内容详细，步骤清晰，细节处理妥当，希望这篇“MySQL的两阶段提交机制是什么”文章能帮助大家解决疑惑，下面跟着小编的思路慢慢深入，一起来学习新知识吧。

创新互联建站-专业网站定制、快速模板网站建设、高性价比路桥网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式路桥网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖路桥地区。费用合理售后完善，十余年实体公司更值得信赖。

MySQL通过两阶段提交的机制，保证了redo log和bin log的逻辑一致性，进而保证了数据的不丢失以及主从库的数据一致。

而说起两阶段提交，就不得不先介绍一下redo log和bin log。

redo log

redo log即重做日志，是InnoDB引擎特有的一种日志（有的面试官经常问到这一点）。

redo log主要做什么呢？

以更新数据为例，我们知道，MySQL的数据是存储在磁盘上的，如果每一次更新数据，都去磁盘寻址找到要更新的数据，进行更新操作的话，这个IO成本是非常高的。

如果是固态硬盘还好，如果是机械硬盘，那么MySQL的更新性能根本无法满足我们的业务需要。

所以，MySQL采用了一种叫做WAL的技术，Write-Ahead Logging。

当更新数据时，将更新操作（即某个数据页上做了什么修改）先写到redo log里面，然后更新内存，这个更新操作就算完成了。MySQL会在服务器空闲的时候，把redo log的操作记录刷新到磁盘里，以保持数据的一致性。

需要注意的是，redo log虽然也是磁盘上的一个文件，但是由于操作是顺序写，所以性能是非常高的。

当然了，redo log也是有大小上限的，不可能无限制的写入。

以上图为例，配置了4个redo log，write pos就是代表当前记录写到什么位置了，而check point表示一个推进点，它会不断的前移，做擦除数据的操作，以保证redo log可以不断的写入。

当然，擦除数据之前，会把redo log的记录刷新到磁盘。

通过redo log，可以保证即使MySQL发生异常重启，数据也不会丢失（因为redo log是物理日志，可以进行重放），这个特性就叫做crash-safe。

bin log

bin log是MySQL Server提供的一种日志，叫做归档日志，所有引擎都可以使用bin log。

那bin log和redo log的区别是什么呢？

1，这两种日志的提供者不同：bin log是由MySQL Server提供的，redo log是InnoDB引擎特有的。

2，redo log主要记录的是某个数据页做了什么修改，bin log记录的是语句的原始逻辑，比如更新了某一行的某个字段。

3，redo log是循环写的，数据会被覆盖。bin log是追加写，一个文件写满，就写下一个文件。

两阶段提交

介绍完了redo log和bin log，我们再看一下他们两者是如何配合完成两阶段提交的。

上图就是一个更新数据的流程，可以看到，在更新一条数据之前，MySQL会先将数据加载到内存，然后更新内存，开始写redo log。

此时，redo log处于prepare状态，等到bin log写完之后，再提交事务，这一条记录的更新操作就算完成了。

redo log prepare -> 写bin log -> redo log commit，这个流程就叫做两阶段提交。

下面我们分析一下，采用两阶段提交的好处。

情景一，redo log处于prepare状态时，如果写bin log失败了，那么更新失败，此时redo log没有commit，bin log也没有记录，两者的状态是一致的，没有问题。

情景二，redo log处于prepare状态时，写bin log成功，但是宕机导致commit失败了。此时bin log产生了记录，redo log没有写入成功，数据暂时不一致。

但是不用担心，当MySQL重启时，会检查redo log中处于prepare状态的记录。在redo log中，记录了一个叫做XID的字段，这个字段在bin log中也有记录，MySQL会通过这个XID，如果在bin log中找到了，那么就commit这个redo log，如果没有找到，说明bin log其实没有写成功，就放弃提交。

通过这样的机制，保证了redo log和bin log的一致性。

读到这里，这篇“MySQL的两阶段提交机制是什么”文章已经介绍完毕，想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会，如果想了解更多相关内容的文章，欢迎关注创新互联行业资讯频道。

本文名称：MySQL的两阶段提交机制是什么
网站URL：http://ybzwz.com/article/gdigce.html