BufferPool缓存机制

1、更新数据流程

• 流程图
  
• sql更新数据刷到磁盘前会经过serve层
  • 连接器-管理连接和权限校验
  • 优化器-语法词法分析
  • 优化器-执行计划生成索引选择
  • 执行器-连接bufferPool

1.1 流程步骤

1. 从磁盘加载数据到buffer pool，会先去判断要更新的数据所在数据页是否已经被加载到了，如果已经被加载到了buffer pool中的数据页就直接使用
2. 写入数据的旧值到undo log日志中
   • 如果事务提交失败要回滚数据，可以用undo日志里的数据恢复buffer pool里的缓存数据
3. 更新buffer pool数据页中内存数据
4. 写入内存中的redo log，这个时候还没写入磁盘中，记录对那个表那条记录做了什么操作
5. 预提交事务，将内存的redo log写入磁盘中的redo log日志，用于崩溃恢复
6. 提交事务之前，还要在内存中写binlog日志，提交事务时写入磁盘文件
7. 写入commit标记至redo日志文件里提交事务完成，该标记为了保证事务提交后redo与binlog数据一至
8. IO随机写入磁盘以paqe为单位写入

1.2 binlog日志

redo log一种偏向物理性质的重做日志，因为他里面记录的是类似这样的东西，“对哪个数据页中的什么记录，做了个什么修改”。而且redo log本身是属于InnoDB存储引擎特有的一个东西。而binlog叫做归档日志，他里面记录的是偏向于逻辑性的日志，类似于“对表中的id=1的一行数据做了更新操作，更新以后的值是什么”。binlog不是InnoDB存储引擎特有的日志文件，是属于mysql server自己的日志文件。

在更新数据时，我们知道会写undo log、redo log日志，同时还会写binlog日志，和redo log日志一样，先是写在内存中，提交事务时，才会写入磁盘。对于binlog刷盘其实有不同的策略，可以通过sync_binlog参数进行配置，默认为0，查看命令：

show variables like 'sync_binlog';

sync_binlog=0时，先将binlog写入内存中，还不是写入磁盘文件，之后线程写入磁盘。写入磁盘前mysql宕机日志会丢失，不安全。

sync_binlog=1时，在提交事务会强制将binlog写入磁盘，日志不会丢失

保证数据的完整性

1. 在更新完buffer pool中数据页，mysql崩溃宕机了，此时已经写了undo log日志，相当于事务没有完成，回滚数据，那么重启系统数据还是之前完整的数据
2. 在写入redo log、binlog过程中，mysql宕机，相当于事务没有提交完成，此时视为回滚事务，重启mysql执行undo log即可恢复到原来数据
3. 如果事务提交成功，buffer pool里的数据还没来得及写入磁盘，此时系统宕机了，可以用redo日志里的数据恢复buffer pool里的缓存数据
4. binlog刷盘参数sync_binlog配置为1，在提交事务会强制将binlog写入磁盘，日志不会丢失，binlog刷盘参数sync_binlog配置为0，随机写入磁盘，以paqe为单位写入