更新一条记录完整流程

具体更新一条记录UPDATE t_user SET name='xiaolin'WHERE id= 1;的流程如下

执行器负责具体执行，会调用存储引擎的接口，通过主键索引树搜索获取 id =1这一行记录:。
- 如果 id=1 这一行所在的数据页本来就在 buffer pool中，就直接返回给执行器更新;。
- 如果记录不在 buffer pool，将数据页从磁盘读入到 buffer pool，返回记录给执行器。
执行器得到聚簇索引记录后，会看一下更新前的记录和更新后的记录是否一样:
- 如果一样的话就不进行后续更新流程;
- 如果不一样的话就把更新前的记录和更新后的记录都当作参数传给 InnoDB 层，让 InnoDB 真正的执行更新记录的操作;
开启事务，InnoDB 层更新记录前，首先要记录相应的undo log，因为这是更新操作，需要把被更新的列的旧值记下来，也就是要生成一条 undo log，undo log 会写入 Buffer Pool 中的 Undo 页面，不过在内存修改该 Undo 页面后，需要记录对应的 redo log。
InnoDB 层开始更新记录，会先更新内存(同时标记为脏页)，然后将记录写到 redo log 里面，这个时候更新就算完成了。为了减少磁盘I/0，不会立即将脏页写入磁盘，后续由后台线程选择一个合适的时机将脏页写入到磁盘。这就是 WAL技术，MySQL的写操作并不是立刻写到磁盘上，而是先写 redo 日志，然后在合适的时间再将修改的行数据写到磁盘上。
至此，一条记录更新完了。
在一条更新语句执行完成后，然后开始记录该语句对应的 binlog，此时记录的 binlog 会被保存到binlog cache，并没有刷新到硬盘上的 binlog 文件，在事务提交时才会统一将该事务运行过程中的所有binlog 刷新到硬盘。
事务提交(为了方便说明，这里不说组提交的过程，只说两阶段提交)
- oprepare 阶段:将 redo log 对应的事务状态设置为 prepare，然后将 redo log 刷新到硬盘;commit 阶段:将 binlog 刷新到磁盘，接着调用引擎的提交事务接口，将 redo log 状态设置为。
- commit(将事务设置为 commit 状态后，刷入到磁盘 redo log 文件)
至此，一条更新语句执行完成。