当前位置：首页 > news >正文

【Mysql】详解InnoDB存储引擎以及binlog，redelog，undolog+MVCC

news 来源：原创 2025/6/10 5:06:48

1.InnoDB存储引擎

在Mysql中，InnoDB存储引擎是默认的，也是我们最常用的一个存储引擎，其中分为内存结构和磁盘结构两大部分，整体架构图如下：

1.1Buffer Pool

Buffer pool(缓存区)是Mysql内存的一个主要区域，用于Innodb存储引擎访问表数据的时候，先把数据读取到Buffer pool中，相当于一个内存缓存，加快数据的处理速度。

1.1.2Buffer Pool的存储结构和内存淘汰机制

Buffer Pool中的数据毕竟是有限的，在内存空间满的时候，会淘汰最近最少使用的数据；

首先它分为俩大块区域：

New SubList：占用Buffer Pool的5/8的大小
Old SubList：占用Buffer Pool的3/8的大小

当有数据进入的时候，会进入New SubList的head位置，内部的数据单位是页，以链表的形式连接起来，最后不经常使用的数据随着时间的推移会慢慢的进入Old Sublist中，淘汰Old SubList的tail 区域；

1.2 Change Buffer

Change Buffer是针对操作二级索引（非聚簇索引）的一个优化，针对DML的一个优化；

如果是操作的是二级索引，对应的数据没有在Buffer Pool中，那么不会立刻写到Buffer Pool中，会写入Change Buffer中做一个缓冲；等到后面，被修改的数据被读取的时候，那么将会把Change Buffer里面的数据合并到Buffer Pool中，这样可以减少磁盘IO次数，提高性能；

如果是一级索引，那么不会触发Change Buffer，直接在Buffer Pool中进行修改；

二级索引修改整体流程：

更新一条记录时，当该记录在Buffer Pool缓冲区中时，直接在Buffer Pool中修改对应的页，一次内存操作。（end）
如果该记录不在Buffer Pool缓冲区中时，在不影响数据一致性的前提下，InnoDB会将这些更新操作缓存在Change Buffer中，不去磁盘做IO操作。。
当下次查询到该记录时，会将这个记录扔到Buffer Pool，然后Change Buffer会将和这个也有关的操作合并，进行修改。

如果数据到达了Change Buffer，还没来得及到达Buffer Pool，MySQL就宕机了，怎么办？

首先要清楚当一个事务提交之后，会将所有的更改记录记录到redolog中，包括Change Buffer中的数据，后续会根据redolog中的数据进行恢复；

1.3 AHI

AHI（自适应Hsah索引）是InnoDB中优化查询操作的功能，当某些索引值使用的频繁，那么可以建立Hash索引提高查询效率；

AHI功能默认自动开启，会从B+树 O(logn)-》O(1);

1.4 Log Buffer

Log Buffer 是存储写入磁盘上的日志文件一个内存区域，主要针对redo log；也是为了减少磁盘的IO次数，提供性能；

2. redo log

redo log（重做日志）：是Innodb存储引擎独有的，当数据库宕机的时候，用来恢复数据（配合binlog），可以恢复近期的数据，保证之前还没有写入到磁盘的数据不会丢失，保证数据的持久性和完整性；

2.1 redo log 是怎么保证数据的完整

在Mysql中，在操作数据的时候，不会立刻落到磁盘中，而是会先放在Buffer Pool中/Change Buffer中，但是会优先放进log Buffer中，写入流程如下:

所有我们只需要知道第四步 log Buffer 是何时落入磁盘的即可；

Log Buffer 刷盘机制：

何时刷入磁盘，一般会根据参数：innodb_flush_log_at_trx_commit 0 1 2 设定

默认为1；

当为0情况：提交事务不会刷盘，只会根据后台提供的一个线程每秒去刷新到os的缓存中；

当为1的情况下：只要提交事务了，那么Log Buffer中的数据一定会在os的内存中，并且后台的线程也会慢慢刷到os的内存中，然后由内存也会强刷到磁盘中

当为2的情况下：提交事务后，Log Buffer中的数据一定为落到os的内存中；但os不会立刻刷到磁盘中，延迟写入;

1：事务提交后日志会立即刷写到操作系统内存，并强制刷新到磁盘，保证数据的持久性，但会牺牲一定的性能。
2：事务提交后日志会立即刷写到操作系统内存，但不会强制刷新到磁盘，依赖操作系统异步写入磁盘，性能较好，但可能在宕机时丢失数据。
0：事务提交后日志仅写入内存，完全不保证磁盘持久性，性能最好，但风险最大。

3.bin log

bin log 并不是innodb独有的日志，它属于服务层，公共的；像redo log 和 undo log中只存在于Innodb引擎层独有；主要作用用于数据备份，数据恢复，主从同步。保证数据的一致性，完整性；

3.1 bin log的日志存储形式

1.statement：会记录sql语句的原文，如果sql语句中存在例如像now（）这样的函数，一旦恢复数据的时候，会按照当前的时间恢复导致数据的不准确

2.row（默认）：不仅记录sql语句的原文，还会记录当前行的数据，不会导致恢复数据的不一致，但是记录的东西多了，需要的空间也会大很多，并且同步的时候也会变长；

3.mixed：在statement和row中做一个权衡，由Mysql自行判断，判断是否当前数据会导致不一样的情况下，如果不会使用statement，反正row；

3.2 bin log 是怎么保证数据的完整

与redolog类似，里面有一个binlog cache，在事务提交之后，再刷新到磁盘；

每个线程会分配一个binlog cache空间，无论多大的事务，也会一次性写入binlog cache；

如果事务太大，binlog cache默认大小为32kb，会自动扩容，但不会超过一个最大值，一般情况下也不会超过；

binlog cache写入磁盘步骤：

可以设置sync_binlog的参数，决定它的同步流程：0 1 N

这个不会像redo log 后台有线程会自动提交给os的内存

当为0时：事务提交后，一定会执行write操作，将binlog cache的数据写入os的缓存中，至于os的缓存何时fsync磁盘中，由系统自行控制；

当为1（默认）时，事务提交后，一定会执行write操作和fsync操作，会保证binlog cache的数据一定落入磁盘中；

当为N的时：提交事务后，后执行write操作，但是会放入os的缓存中，必须要为N个事务的时候，才会执行fsync操作同步到磁盘中；这种最坏的结局就是丢失N-1个事务，但是提高效率加，减少io次数；

俩阶段提交（2PC）

什么是俩阶段提交？

redo log 是用来在mysql宕机之后用来恢复数据；而bin log 用作数据备份或者主从同步保证架构的一致性；侧重点不同；

举例：在执行一条更新操作的时候，并且有事务操作时候，redo log 会不断的写入到os的缓存中，而bin log只能在提交事务的时候才会写到os的缓存中，并且fsync操作写到磁盘；

如果在此过程中，mysql宕机了，可以会导致redo log 和bin log中的数据造成不一致的情况；

假如此时修改age的时候18为38，redolog 在没提交事务的时候就已经完成了写入，而binlog此时值还为18，那么一旦这时候mysql宕机，binlog数据还是为18；

mysql中重启之后恢复数据，从节点会根据binlog中的文件读取数据 age 为18

而宕机后主节点会根据redolog进行查询数据 age 为38

这时候主从节点数据不同，那么将产生问题；

此时需要2PC解决问题;

2PC执行过程：

将redo log 分为俩个步骤，部署成redo log prepare 和 redo log commit；就是俩阶段提交；

事务未提交的时候，那么redo log将会是prepare状态，而真正提交了的数据，将会是commit状态；

mysql宕机之后，mysql主节点根据redolog进行恢复，那么会比对redo log提交状态，如果是prepare状态，那么也会比对binlog中的数据，如果binlog没有这份数据，那么数据将会被回滚；

在mysql提交事务的时候出现异常，但是redolog prepare 和binlog 已经修改成功值，那么后续比对的时候一致，就不会出现主从不一致情况；

4 undo log

undo log也是属于innodb存储引擎中的日志；

它是保存了数据的历史记录，一方便事务回滚的时候，可以回到之前的版本，另一方面在MVCC多版本并发控制的时候，在读取快照的时候，需要在undo log文件中读取；

并且mysql中的原子性根据undo log实现，即使数据库宕机，也可以恢复到之前的版本，undo log在没有提交事务的时候，数据就已经在磁盘中；

5. MVCC

MVCC:多版本并发控制，在以前只能进行读读并发操作，一旦设计到读写操作，那么将会阻塞一方，就会导致效率低下；

在MVCC的内部，会根据undo log保存的数据记录的版型信息来实现的；每个事务读取的版本会不一样，在同一个事务中，每个用户只能看见当前事务创建快照前的数据和事务本身提供的数据；

MVCC在RC,RR的隔离级别才会适用到；

当前读：将select lock in share mode(共享锁), select for update ; update, insert ,delete(排他锁)这些操作都是一种当前读，操作读取的是记录最新的版本，并且还要保证其他事务不能修改当前数据，会对读取的数据加锁

快照读：像不加锁的select就是快照读，是基于并发的性能下，它的实现基于MVCC，在很多情况下，避免了加锁的操作，提供性能，因为其他事务可以进行操作，快照读就读取的不一定是最新版本的数据，可能是历史数据

MVCC根据隐藏字段，undolog，RedaVied三者实现的；

5.1 隐藏字段

InnoDB在每个数据库中的每一行会提供三个字段：

DB_TRX_ID：标记最近修改的事务id，属于递增的；

DB_ROLL_PTR：回滚指针，undolog记录的多个版本之间，通过DB_ROLL_PTR来连接

DB_ROW_ID：如果表中没有主键，那么会这个会作为隐藏主键存在

5.2 undo log的存储结构

假如有一种user表，有id和name字段

现在有事务2进行将张三修改为李四；

1.获取排它锁 2.将旧版本数据放入undo log中 3.修改数据将事务id修改为2 将回滚指针指向旧版本数据 4.释放锁

现在又来了一个事务ID为3，修改这行数据，将李四修改为王五同理：

5.3 ReadView：

ReadView就是读操作中的可见性判断核心，也就是当前事务能不能读取到undo log中的某行数据或当前行数据。ReadVied内部维护了很多的变量和逻辑；

当开启事务的时候，执行第一个select命令，就会创建一个ReadView 也就是快照；

在当前事务下，用户想读取某行的记录，InnoDB会将DB_TRX_ID和ReadVied中的属性进行比较，才能判断是否可以查找到；

ReadView属性内容：

m_creator_trx_id : 当前事务的id，也就是事务id

m_ids: 创建快照时候，处于活跃事务id的集合、

m_low_limit_id: 如果当前行事务大于这个值，那么数据将会是不可见；它是未分配事务的最小事务id，也就是最大活跃事务+1；

m_up_limit_id: 活动事务集合中最小的id，如果当前行的事务小于这个值，那么数据将会是可见的；

在RC隔离级别下，每次执行select语句，都会创建快照；

在RR隔离级别下，只有第一次执行select语句，会创建快照，后续再查询的时候，都是基于第一次的快照；

ReadView 可见性判断：

就是按照一下逻辑去比对

// id参数，是你想查看的那行数据的事务ID
bool changes_visible(trx_id_t		id, const table_name_t&	name) const MY_ATTRIBUTE((warn_unused_result)){ut_ad(id > 0);// m_up_limit_id 是活跃事务的最小id，如果当前行的事务ID，小于m_up_limit_id，说明这个事务必然已经提交了，这个数据是可见的。// 如果当前行的事务ID和当前创建ReadView的事务ID相等，说明就是当前事务修改的数据，必然可见。if (id < m_up_limit_id || id == m_creator_trx_id) {return(true);}check_trx_id_sanity(id, name);// 当前行的事务ID，大于了m_low_limit_id，必然不可见。创建Read View的时候，m_low_limit_id这个事务还没有呢。if (id >= m_low_limit_id) {return(false);// 没有活跃事务，并且当前行数据的事务ID，还小于m_low_limit_id，那这个数据必然可见。} else if (m_ids.empty()) {return(true);}const ids_t::value_type*	p = m_ids.data();// 如果上述情况都不满足，无法判断可见还是不可见，此时需要拿着当前行的事务ID，以及活跃事务列表开始判断。// 1、如果我发现当前行的事务ID，在活跃事务列表中。此时在Read View来说，这个事务没提交，不可见。// 2、如果我发现当前行的事务ID，不在活跃事务列表中，说明创建Read View时候，你就提交了，可见。return(!std::binary_search(p, p + m_ids.size(), id));
}

当id < m_up_litmit_id 可见id=13的数据

RC隔离级别每次查询都会创建快照当第一次查询name为王五

事务14进行了提交事务，那么将name修改成赵六

当第二次查询的时候可以查出name为赵六满足 14 id < 15 m_up_limit_id

所以RC隔离级别就出现不可重复读的问题

RR隔离级别只会生成第一次查询的快照 name 为王五

那么第二次查询的时候不满足 14 id < 14 m_up_limit_id 条件

也不满足 14 id = 12 creator_id

满足了查询的事务id 在活动列表中那么就是不可见的

所以查询不出来name为赵六的结果

最终结果 name为王五