*** 我是一个莫得感情的小伙伴

一、前言

介绍一下 MySQL InnoDB 存储引擎是如何将数据一步一步最终写入到磁盘上的。

MYSQL数据库至理名言：  日志先行

INNODB的三大特性：插入缓存，双写，自适应hash

二、小二上正菜

日志先行（其实就是事务日志原理）

mysql在具体执行 insert 之前会做各种验证，这里就跳过了，直接介绍引擎层的处理过程

1、第一步，为保证数据一致性，INNODB先写 undolog回滚日志，逻辑日志，记录在ibdata1文件，必须先与数据落盘，保证崩溃可回滚机制。 

2、 第二步，为保证已提交但未落盘的数据不丢失，INNODB记录redo log 重做日志，redolog为物理日志，对应文件为ib_logfile0、ib_logfile1或者ib_logfileN，redolog是顺序循环写，相对高效，，对应参数 ：innodb_flush_log_at_trx_commit ；若开启binlog，则还需写binlog文件，对应参数： sync_binlog，Mysql为了保证master和slave的数据一致性和崩溃恢复，就必须保证binlog和INNODB redolog的一致性（binlog在server层，而redo log 在存储引擎层），MySQL引入二阶段提交，传说中的2PC。

2PC   prepare阶段：

1、协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。　　
2、各参与者执行事务操作，将Undo和Redo信息记入事务日志中（但不提交事务）。　　
3、如参与者执行成功，给协调者反馈YES，即可以提交；如执行失败，给协调者反馈NO，即不可提交。

               具体操作：1、执行SQL ，生成xid信息及undo和redo的内存日志调用prepare方法完成第一阶段，持有prepare_commit_mutex（5.6引入组提交）

                                2、并且write/sync redo log；

                                3、将回滚段设置为Prepared状态，binlog不作任何操作，返回ok；

PS：记录Binlog是在InnoDB引擎Prepare（即Redo Log写入磁盘）之后，这点至关重要。

2PC   Commit阶段：

1、此阶段分两种情况：所有参与者均反馈YES、或任何一个参与者反馈NO。
2、所有参与者均反馈YES时，即提交事务。
3、任何一个参与者反馈NO时，即中断事务。

               具体操作  1、write/sync Binlog；
                                2、InnoDB commit (写入COMMIT标记后释放prepare_commit_mutex)；

4、 第四步，提交。提交完成并不代表数据不会丢失，这与上面配置的参数有关。

5、第五步，数据落盘，与参数配置有关，配置的严格 第三步就可落盘，一般高性能模式是会延迟落盘，不会一提交立即落盘。

盗个图：

三、五星好评

1. MVCC 

2. INNODB 事务日志

3. INNODB 三大特性

4. 2PC

5. 核心参数配置

四、饭后甜点

附官方参考手册：分布式事务   https://dev.mysql.com/doc/refman/8.0/en/xa.html 

附爱可生参考文档： MySQL insert 语句的磁盘写入之旅 https://my.oschina.net/actiontechoss/blog/3226494/print

附大佬 ·double write· 文档：https://www.cnblogs.com/andy6/p/6938704.html