了解mysql的更新语句需要先了解redo log(重做日志),bin log（归档日志.
redo log
redo log是一种WAL技术应用，英文全称为write-aheading-log，即首先将记录写入到日志里，当数据库空闲时，将记录写入磁盘。 为何有会采用这种计数呢，因为执行一条SQL更新语句会去写磁盘，然后磁盘会去查找对应的行，再进行更新，整个过程无论是IO操作，还是查找操作消耗都很大，因此mysql存储引擎innodb采用将数据先写入到redo log，然后更新内存，这样就算完成一条更新语句，然后在适当的时候再讲数据更新到磁盘中。 同时该技术能够结果crash-safe问题，当系统突然崩溃时，可以通过redo log恢复崩溃前的状态。
InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB，那么这块“粉板”总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写
bin log
Binlog有两种模式，statement 格式的话是记sql语句， row格式会记录行的内容，记两条，更新前和更新后都有。
redo log 是 InnoDB 引擎特有的日志，而 Server 层也有自己的日志，称为 binlog（归档日志）。
两种日志的不同点：
1 Redo log不是记录数据页“更新之后的状态”，而是记录这个页 “做了什么改动”。 Binlog有两种模式，statement 格式的话是记sql语句， row格式会记录行的内容，记两条，更新前和更新后都有。
2 redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用。
3 redo log 是循环写的，空间固定会用完；binlog 是可以追加写入的。“追加写”是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
innodb执行sql语句更新的内部流程：
执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；
否则，需要先从磁盘读入内存，然后再返回。执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。
然后告知执行器执行完成了，随时可以提交事务。执行器生成这个操作的 binlog，并把 binlog 写入磁盘。执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。
为什么要有两阶段提交？
redo log 等待 binlog 写入完成后，由 prepare 变为 commit 提交状态。
1 prepare阶段 2 写binlog 3 commit 当在2之前崩溃时 重启恢复：后发现没有commit，回滚。备份恢复：没有binlog 。 一致 当在3之前崩溃 重启恢复：虽没有commit，但满足prepare和binlog完整，所以重启后会自动commit。备份：有binlog. 一致。
本质上是因为 redo log 负责事务； binlog负责归档恢复； 各司其职，相互配合，才提供(保证)了现有功能的完整性； 现在 你非要破坏 其中一个log，完了，还妄想保证上述的功能，怎么可能呢？？？ 除非你从根本上 改写binlog，合并redo log 和 binlog 的 职责 和 功能！！！
定期全量备份的周期“取决于系统重要性，有的是一天一备，有的是一周一备”。那么在什么场景下，一天一备会比一周一备更有优势呢？
如果不是两阶段提交, 先写redo log和先写bin log两种情况各会遇到什么问题?
先写redo log，crash后bin log备份恢复时少了一次更新，与当前数据不一致。先写bin log，crash后，由于redo log没写入，事务无效，所以后续bin log备份恢复时，数据不一致。
