一条SQL更新语句的执行过程
如果执行这条更新语句数据库是如何执行的呢？
update Student set name='小明' where StudentID=1
根据之前说过的SQL语句查询的流程来说，只要表上有数据更新，有关查询的索引就会失效，接下来分析器会根据每个单词识别知道这是Update语句，优化器根据这个ID获取需要的索引，然后执行器执行这一行，进行更新。
先说里面有一个重要的内容就是：redo log（重做日志）和 binlog（归档日志）。
重做日志
在MySQL语句更新的时候，如果每一次更新操作都需要写进磁盘，然后磁盘也找到对应的记录，然后再更新，会消耗很大的IO，降低系统的效率。
这个时候重做日志的场景就来了，当一条数据进行更新的时候，InnoDB引擎会先把记录写在redo log日志中，并更新内存完成更新。在系统空闲的时候引擎会把这个操作记录更新到磁盘。
但是如果一直在往redo log中写入数据，redo log日志也是有固定大小的，当写满了，会将最之前插入进来的数据，更新到磁盘，然后擦除这段数据可以用来记录新的操作。有了这个功能，MySQL在异常重启情况下数据都不会丢失。这个能力称为crash-safe。
归档日志
当时MySQL没有InnoDB引擎，只有归档日志binlog，因此其他引擎没有crash-safe功能，后面有了InnoDB才诞生redo log日志。
两种日志的特点：
- redo log是属InnoDB引擎，binlog是属于Mysql Server实现的。
- redo log是循环写的，写满了会从头清空一部分继续写，一边又一遍，binlog是可以追加写入，文件满了又会开辟下一个文件继续写。
- redo log是物理日志，记录了在什么地方进行了修改，而binlog记录的是更新的具体逻辑，把ID为二的数据名称改为小明。
Update语句更新流程
- 首先执行器根据StudentID=1的索引取得这一行数据，如果这一行数据在内存中，就直接返回给执行器，否者从磁盘读取进内存再返回。
- 执行器拿到数据给name改为小明，得到新的数据行。
- 引擎将这个数据更新到内存中，然后将操作记录写入redo log，这时redo log处于prepare状态，然后告知执行器已经完成可以提交事务。
- 执行器生成这个操作的binlog，并把binlog写进磁盘。
- 执行器调用引擎接口提交事务，并把刚刚写入的redo log 改成提交（commit）状态，更新完成
为什么要进行两次提交
如果不用两次提交会发生什么情况
假如不用redo log，在系统崩溃的时候，数据就没有了。
假如不用binlog，无法用binlog恢复数据库备份。
为什么要两种一起用呢，就好比事务，写入了redo log，即将写入binlog的时候系统崩溃，你的redo log没有丢失，可以等系统正常运行的的时候，再次提交并把binlog写进磁盘。redo log 和 binlog 都可以用于表示事务的提交状态，而两阶段提交就是让这两个状态保持逻辑上的一致。
redo log 用于保证 crash-safe 能力。innodb_flush_log_at_trx_commit 这个参数设置成1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。这个参数我建议你设置成 1，这样可以保证 MySQL 异常重启之后数据不丢失。
sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。这个参数我也建议你设置成 1，这样可以保证 MySQL 异常重启之后 binlog 不丢失。
