Innodb引擎SQL执行的BufferPool缓存机制

SQL的执行

执行流程

1. 加载缓存数据，加载id为1的记录所在的整页数据（相当于索引树的一个结点，16KB）
2. 写入更新数据的旧值到undo日志中，方便回滚
3. 执行器更新BufferPool缓存池中的内存数据；
4. 写入redo日志，将操作结果写入Redo Log Buffer缓冲区。
5. 准备提交事务，redo日志写入磁盘中
6. 准备提交事务，将结果写入binlog日志，binlog日志写入磁盘，binlog主要用来恢复数据库磁盘里的数据；
7. 写入commit标记到redo日志文件里，提交事务完成，该标记为了保证事务提交后的redo与binlog数据一致。
8. 将Buffer Pool缓冲池中修改后的数据随机写入磁盘，以Page为单位写入，执行完后，磁盘中的name=zhuge666;

redo日志作用

如果事务提交成功，buffer pool里的数据还没吸入磁盘，此时系统宕机，可以用redo日志里的数据恢复buffer pool里的缓存数据，再重新写入磁盘；

undo日志作用

当事务更新完数据后，执行其它操作发生错误，导致事务执行失败，MySQL会将undo日志里最新的旧值回滚，保证数据一致性；

undo日志更详细介绍的介绍在：
MVCC机制

为什么Mysql不能直接更新磁盘上的数据而且设置这么一套复杂的机制来执行SQL了？

因为来一个请求就直接对磁盘文件进行随机读写，然后更新磁盘文件里的数据性能相当查；
因为磁盘随机读写的性能是相当差的，所以直接更新磁盘文件是不能让数据库抗住高并发请求的。

MySQL这套机制看起来复杂，但他保证每个请求都是更新内存（BufferPool），然后顺序写日志文件，同时还能保证各种异常情况下的数据一致性；

更新内存的性能 和顺序写磁盘上的日志文件的性能远比更新磁盘的性能高的多。