简述一条更新语句的执行过程

更新语句(增删改)的执行，基本流程和查询一致，也要经过连接器、分析器、优化器、执行器等功能模块，区别就在于拿到符合条件的数据之后的操作。

1. 执行器先通过存储引擎获取需要修改的数据。如果该数据所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。

2. 执行器修改数据后，再调用存储引擎接口写入这行新数据。

3. 存储引擎将这行新数据更新到内存(buffer pool)中，同时将这个更改前的数据记录到undo log(保留历史数据，记录事务版本号，形成版本链)，以及将更改后的数据记录到 redo log 里面(记录的是数据页的改动)，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。

4. 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。

5. 执行器调用存储引擎的提交事务接口，存储引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成。

 

这里面还有一个change buffer

当需要更新一个数据页时，如果数据页在内存中就直接更新，而如果这个数据页还没有在内存中的话，在不影响数据一致性的前提下，InnoDB 会将这些更新操作缓存在 change buffer 中，这样就不需要从磁盘中读入这个数据页了。在下次查询需要访问这个数据页的时候，将数据页读入内存，然后执行 change buffer 中与这个页有关的操作。通过这种方式就能保证这个数据逻辑的正确性。

change buffer的收益主要在减少普通二级索引页从磁盘加载到内存的过程。对于数据的修改，还是要从磁盘中读数据到内存的。