执行器就会去根据我们的优化器生成的一套执行计划，然后不停的调用存储引擎的各种接口去完成SQL语句的执行计划
8、异步刷磁盘（随机刷盘）
发送请求
连接
执行SQL语句
Redo Log Buffer
binlog 日志文件
线程
磁盘文件
SQL语句
redo log日志
undo log日志文件
获取SQL
name=\"zhz1\"
3、更新内存中数据
查询优化器
原子性
执行器
数据库连接池
name=\"zhz\"
执行SQL
InnoDB
解析SQL
此时redolog和binlog都是修改日志name=\"zhz1\"
Tomcat
执行计划
MySQL数据库
注释
4、写Redo log日志
原子性扩展
SQL接口
查询最优路径
SQL解析器
redo log buffer的作用：一旦系统宕机，避免数据丢失。什么时候会把redo log buffer存进mysql中？ 1、当我们提交一个事务的时候，此时就Mysql会根据一定的策略把redo日志从redo log buffer里刷入到磁盘文件里去。那么这个策略是什么控制的呢？ 1、通过innodb_flush_log_at_trx_commit控制，他又3个选项： - 0：你提交事务的时候，不会把redo log buffer里的数据刷入磁盘文件的，此时可能你都提交事务了，结果mysql宕机了，然后此时内存里的数据全部丢失。（宕机会把系统缓存清空） - 1：你提交事务的时候，就必须把redo log从内存刷入到磁盘文件里去，只要事务提交成功，那么redo log就必然在磁盘里。（一般建议设置这个） 解释：当我们的策略是1的时候，我们想一个场景：当我们此时提交事务了，mysql正把redo log buffer写入到redo日志时，并且也写入成功了，但就是写入成功之后，系统宕机了，但是此时还没把磁盘数据更成最新的数据，那么数据会丢失吗，答案是不会，因为musql重启之后，会读redo log把宕机前的数据给提交了，存到磁盘中 - 2：提交事务的时候，把redo日志写入磁盘文件对应的os cache缓存里去，而不是直接进入磁盘文件，可能1秒后才会把os cache里的数据写入到磁盘文件里去。 解释：会有丢失的可能性，因为提交事务之后，会有个暂存的地方，此时在暂存的时候就宕机了，会造成日志数据并未落磁盘而导致日志数据丢失redo log记录日志形式：\"对哪个数据页中的什么记录，做了个什么修改\"
5、redo log日志刷入磁盘（准备提交事务的时候）
2、写入旧值，便于回滚
7、本次更新对应的binlog文件名称和这次更新的binlog日志在文件里的位置，都写入到redo log日志文件里去，同时在redo log日志文件里写入一个commit标记
调用对应接口执行SQL语句
Buffer Pool缓冲区
更新阶段的第三步（更新buffer pool中的缓存数据）： 当我们把要更新的那行记录从磁盘文件加载到缓冲池，同时对他加锁之后，而且还把更新前的旧值写入undo日志文件之后，我们就可以正式开始更新这行记录了，更新的时候，先是会更新缓冲池中的记录，此时这个数据就是脏数据了。（也就是bufferpool和磁盘数据不一致，bufferpool的最新）
用户B
1、加载缓存数据（会加锁）
6、binlog日志写入磁盘（准备提交事务的时候）
Mysql的binlog也是有不同的刷盘策略的：是由sync_binlog控制的，默认是0 - 0：binlog先写入os cache内存缓存中，可能1s后会把他刷入磁盘文件中，所以跟redo log一样的，当刷入os cache中时，宕机会丢日志。 - 1：会强制在提交事务的时候，把binlog直接写入到磁盘文件里去，提交事务之后，哪怕机器宕机，磁盘上的binlog是不会丢失的。
解释
1、除了上方的WAL（预写式日志）可以实现原子性，我们市场中还有Commit Logging(提交日志)和Shadow Paging(影子分页)都可以实现事务的原子性和持久性 Commit Logging（提交日志）：只有在日志记录全部都安全写入磁盘之后，数据库在日志中看到代表事务成功的“提交记录”(Commit Record)之后，才会根据日志上的信息对真正的数据进行修改，修改完成后，再在日志中加入一条“结束记录”(End Record)表示事务已完全持久化。 Shadow Paging（影子分页）就是类似JUC中的写时复制（Copy-on-write=>COW），就是在写时复制一份，在复制的那一份中修改，也就是说在整个事务中，需要同时修改两份数据。
IO线程
