全网最牛X的MySQL两阶段提交，你真的完全搞懂了吗？

目录一、吹个牛二、事务及它的特性三、简单看下两阶段提交的流程四、两阶段写日志用意？五、加餐：sync_binlog = 1 问题六、如何判断binlog和redolog是否达成了一致七、两阶段提交设计的初衷 - 分布式事务八、再看MySQL两阶段写日志九、留一个彩蛋十、推荐阅读（公众号首发，欢迎关注白日梦） 一、吹个牛 面试官的一句：“了解MySQL的两阶段提交吗？” 不知道问凉了多少人！ 这篇文章白日梦就和大家分享什么是MySQL的两阶提交到底是怎么回事！不管你原来晓不晓得两阶段提交，相信我！这篇文章中你一定能get到新的知识！ 在说两阶段提交之前，白日梦用了大量的篇幅再讲undo-log、redo-log、binlog。 先了解它们，才能更好的理解什么是两阶段提交，如果你如果还没有看，推荐你去翻一翻前面的文章。 二、事务及它的特性 在说两阶段提交事物之前，我们先来说说事务。 一般当我们的功能函数中有批量的增删改时，我们会添加一个事物包裹这一系列的操作，要么这一组操作全部执行成功，只要有一条SQL执行失败了我们就全部回滚。相信你一定听说过这个比较经典的转账的Case。有一定工作经验的同学都知道，这么做其实是保护我们的数据库中不出现脏数据。整体数据会变的可控。 对MySQL来说你可以通过下面的命令显示的开启、提交、回滚事务 # 开启事务 begin; # 或者下面这条命令 start transaction; # 提交 commit; # 回滚 rollback; 但是日常开发中大家普遍使用编程语言操作数据库。比如Java、Golang... 在使用这种具体编程语言持久层的框架时，它们一般都支持事务操作，比如：在Spring中你可以对一个方法添加注解@Transctional显示的开启事务。Golang的beego中也提供了让你可以显示的开启事务的函数。 有一点不太好的地方是：大家在享受这种编程框架带来的便利的同时，它也屏蔽了你对MySQL事务认知。让人们懒得去往细了看事务 你可以往看我下面这个很简单的Case。 我有一张数据表 CREATE TABLE `test_backup` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; 然后我往这个表中insert几条数据 mysql> insert into test_backup values(1,'tom'); mysql> insert into test_backup values(2,'jerry'); mysql> insert into test_backup values(1,'herry'); 再去查看binlog。 你会不会诧异？我上面明明没有显示的添加begin、commit命令，但是MySQL实际执行我的SQL时，竟然为我添加上了！ 原因很简单：跟大家分享一个参数如下： 一般大家的线上库都会将这个参数置为ON，你的SQL会自动的开启一个事物，并且MySQL会自动的帮你把它提交。 也就是说: 当这个参数为ON时，你使用的DAO持久层框架发送给数据库的SQL其实都会被放在一个事物中执行，然后这个事物被自动提交，而我们对这个过程是无感知的。 具体一点，比如你使用某框架的@Transctional注解，或者在golang中可以像下面的方式获得一个事物： db := mysql.Client ops := &sql.TxOptions{ Isolation: 0, ReadOnly: false, } tx, err := db.BeginTx(ctx, ops) // todo with tx 然后你所有的操作都放在这个事物中执行。 这时你使用的持久层框架肯定会向MySQL发送一条命令：`begin;`或者是`start transcation;`来保证你这一组SQL中执行一条SQL后，开启的事物不会被MySQL自动帮你提交了。 其实还是推荐将这个参数设置成ON的，当然你也可以像下面这样将它关闭 mysql> set autocommit = 0; 但是关闭它之后，MySQL不会帮你自动提交事物，全靠研发同学自己来维护就容易会出现长事物，在内存中产生一个极其长的undo log链条。坏处多多。 todo 关于长事物，你可以看白日梦的这篇笔记： 三、简单看下两阶段提交的流程 了解了什么是事物，再来看下什么是两阶段提交。