MySQL 进阶图文详解InnoDB储存引擎

news2024/9/25 15:30:04

前言

SQL 语句的最终执行者是存储引擎。存储引擎在经解析器、优化器处理后被执行器调用其接口执行优化后的执行计划。MySQL 存储引擎包括 InnoDB、Myisam、Memory、Archive、CSV 存储引擎等，其中最常用也是MySQL 默认的存储引擎是 InnoDB。
写入缓冲池（Buffer pool）

InnoDB 中有一个非常重要的组件——缓冲池（Buffer pool）,缓冲池中存储了 MySQL 在磁盘文件上的数据缓存。所以当 InnoDB 执行更新语句时，会首先判断数据是否在缓冲池，如果不在，那么会从磁盘中加载到缓冲池，然后对更新的记录加独占锁，再执行更新。
在这里插入图片描述

写入undo 日志文件

更新数据会有更新失败的可能，那如果更新失败需要回滚怎么办？此时就需要在更新之前把需要更新的记录写入 undo 日志文件，在提交日志之前都是可以回滚的。
在这里插入图片描述

更新数据

在把数据写入缓冲池、原来的数据写入 undo 之后，就可以正式更新数据了。这时首先更新的是加入缓冲池的缓存数据，更新之后原来的 “name=zhangsan” 就变成了 “name=lisi” ，缓存中的数据就是脏数据了，因为此时磁盘上还是 “name=zhangsan” ，但是内存中的数据已经修改了。
　　在这里插入图片描述

写入redo log buffer

经过以上步骤，内存中的缓存数据已经修改了，如果此时数据库宕机了，那刚才修改的岂不是毫无意义了？所以这个时候就需要把对缓存做的修改写入到 redo log buffer 中，这个缓冲区是用于存放 redo 日志的，就是记录对数据的修改操作。所以当数据库宕机时，就可以通过 redo 日志来恢复对数据的操作。那如果事务提交之前，数据库宕机了呢？内存中的数据会全部丢失，但是磁盘上的数据并没有修改，而且事务并没有提交成功，所以并没有影响。
在这里插入图片描述

在提交事务时，会根据策略把 redo 日志写入磁盘文件，这个策略通过 innodb_flush_log_at_trx_commit 来配置。
策略一：参数值为 0 时，不会把 redo 日志写入磁盘，如果事务提交成功后宕机了，那么内存中的数据和 redo 日志都会丢失，这种方式性能最高，但是对事务而言不安全；
策略二：参数值为 1 时，事务成功时，必须把 redo 日志写入磁盘，只要事务成功，redo 日志必然在磁盘中，这种方式是最安全的事务，但是会损耗性能；
策略三：参数为 2 时，把 redo 日志写入 os cache 系统内存中，而不是直接写入磁盘，在一定时间后才会由系统刷入磁盘，这种方式也有风险，写入系统内存后宕机依然会丢失数据，事务却提交成功了，但是性能相比策略二低，安全性相比策略一高，算是一种折中方式吧。
　　一般建议 redo 日志刷盘策略选策略二，事务一旦提交成功，数据绝不能丢失。
　　在这里插入图片描述

写入binlog

实际上MySQL 在提交事务成功时，不仅会 redo 刷盘还会写入 binlog 日志。redo 是 InnoDB 存储引擎所特有的，binlog 属于 MySQL Server 的日志文件。binlog 是一种归档日志，记录的是偏向逻辑性的日志，类似于“对user表中的id=10这行数据做了更新操作，更新后的值是lisi”；而 redo 是一种偏向物理性值的重做日志，类似于“对哪个数据页中的什么记录，做了什么修改”。步骤1、2、3、4属于事务开始提交，5、6属于事务提交。
在这里插入图片描述

binlog 也有不同的刷盘策略，使用参数 sync_binlog 控制 binlog 的刷盘策略。策略一：参数值为 0，此时会先写入 os cache，然后等待 os cache 刷盘，所以这种策略也是有安全风险的，可能会丢失 binlog 日志；策略二：参数值为 1，此时会在提交事务时，强制写入磁盘。
　　在这里插入图片描述