MySQL事务完整生命周期的底层原理

国庆期间了解了一下MySQL中整个事务的底层流转过程，跟大家简单分享一下，中间可能有细节需补充，望各位执教。
ok，进入主题

事务在MySQL中再普通不过了。
那么在数据库里到底是如何通过事务执行一条简单SQL呢。
为了更好的理解，接下来讲的整个流程都以以下条件为前提。

1、autocommit = 0; #关闭自动提交
2、tx_isolation = 'READ-COMMITTED'; #隔离级别为读已提交
3、事务中的sql为DML
4、master主库下有个slave从库


事务完整的生命周期

一、客户端begin；开启一个事务

• 通过mysql_xid_next()生成xid

xid全称为Transaction Identifier，在InnoDB引擎中实现事务的唯一标识，在事务开始时被分配

二、用户执行SQL

例如：
insert into test.t (a,b,c) values (1,2,3);
或
update test.t set d="张三" where id=1;
或
delete from test.t where id=1;


• 这一步，如果是update、delete语句，且where条件是普通索引（非唯一索引或主键索引），则直接在change buffer中修改；
• 如果是insert 或update、delete语句中where条件是唯一索引或主键索引的sql，则会将对应的数据页拉到innodb_buffer_pool中

三、客户端commit；提交该事务

四、MySQL底层开始事务的2PC(两阶段提交)

1、binlog准备阶段

• 将上一次commit队列中最大的seq_number写入到本次事务的last_commit中

2、prepare阶段：

• 将redo_buffer中的内容写入os cache中
• 将redo_buffer中的xid落盘到undo上

由于undo写磁盘是非常消耗性能的，所以不在事务中进行，由mysql主线程直接控制

• 将xid写入binlog cache中

3、flush阶段：

• redo从os cache中刷到磁盘
• 循环log_buffer中的binlog到os cache
• 此时如果开启了GTID，则直接将GTID信息刷入磁盘上的binlog

gtid_event不经过binlog cache直接写入binlog，因此gtid_event是事务的第一个event

• 将last_commit和seq_number刷入磁盘上的binlog
• 检查写入的event总量加上现有的binlog大小，是否超过max_binlog_size，确认是否打上binlog切换标记
• 此时如果sync_binlog !=1，dump线程发送event给从库

4、sync阶段（注意！！！，此时master上的其他会话看不到该事务的内容）

• 此时如果主从为增强半同步，master确认slave传回的ACK信号
• binlog从os cache到刷到磁盘，同时slave也会通过relay log回放该事务
• 此时如果sync_binlog =1，dump线程发送event给从库

5、commit阶段

• 此时如果主从为半同步，master确认slave传回的ACK信号。（注意！！！此时master上的其他会话已经能看到该事务的内容，但是在slave看不到。因为从库的relay log才落盘，回放需要时间）
• 此时如果为增强半同步，slave也可以看到该事务内容
• 做innodb层的提交（循环每个事务的redo）
• 根据上面的标记决定是否切换binlog日志
• 如果设置了expire_logs_days，还会决定是否清理binlog
• 给客户端返回执行成功信号

五、DWR：double write buffer数据落盘

六、数据页写回磁盘

• 此时如果在第二步数据页没有加载到innodb_buffer的话，数据还是会先留在change buffer中，并在之后先刷到innodb_buffer再落盘
• 如果在第二步数据页已经加载到innodb_buffer的话，则根据脏页的刷新策略落盘

源码部分如下

最后

引用《反贪风暴》中东莞仔的话：“这段内容光我讲都要十几分钟，在mysql里跑只要几毫秒啊”