必须结合日志系统详解的博客搭配看不然根本看不懂更本无法理解！！！

1.mysql 执行查询命令

mysql update where 子查询 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)状 态，更新完成。

mysql update where 子查询 mysql更新查询_重启_02

由图可知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 都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态 保持逻辑上的一致。