必须结合日志系统详解的博客搭配看不然根本看不懂更本无法理解！！！
1.mysql 执行查询命令
mysql 执行更新命令
1. 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器;否则，需要先从磁盘读入内存，然后再返回。
2. 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的 一行数据，再调用引擎接口写入这行新数据。
3. 请注意此时引擎并没有写入磁盘中，而是引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
4. 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。
5. 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交(commit)状 态，更新完成。
由图可知redo 日志存在两个不同的阶段 （两阶段提交） prepare commit 状态
写入了binlog再commit
重点理解二个提交阶段prepare 和 commit
不要被二个日志给带歪了，从二个提交状态来理解。
我们来说一下，如果重启会不会带来问题：
1.在写入redolog处于prepare阶段后，还没来的及写binlog时重启
只要处于prepare状态，mysql重启后发现是prepare状态的数据，就会认为是无效数据，所以不会产生影响
2.redolog处于prepare阶段，binlog也写完并写入磁盘，此时还没commit就重启。
这个时候redolog是prepare, binlog也已经完整了，Mysql重启后，认为认可这一个事务，会提交掉。
二个阶段提交有大作用
不只是误操作后需要用这个过程来恢复数据。当你需要扩容的时候，也就是需要再 多搭建一些备库来增加系统的读能力的时候，现在常见的做法也是用全量备份加上应用 binlog 来实现的，这个“不一致”就会导致你的线上出现主从数据库不一致的情况。
简单说，redo log 和 binlog 都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态 保持逻辑上的一致。
