深入理解MVCC与innoDB底层原理

2026-01-06 10:20:51   0  举报





AI智能生成

掌握MySQL中MVCC（多版本并发控制）机制和InnoDB存储引擎的底层原理是数据库设计和优化的精髓。在InnoDB中，MVCC通过隐藏的事务ID和行的多个版本实现非锁定读取，允许用户在高并发下读取数据，而不会被其他写操作阻塞。这种机制依赖于undo日志来记录旧版本数据，当事务需要访问旧版本记录时，InnoDB通过undo日志中的信息构建数据快照。对于一致性非锁定读，InnoDB会根据事务的隔离级别和系统版本号（Row ID）确保读取的数据是可见的。

MySQL

作者其他创作

大纲/内容

MVCC(多版本并发控制)

允许多个用户（事务）同时访问数据库，而不会因为读写操作相互阻塞，从而极大地提升了数据库在高并发场景下的性能和吞吐量。 核心思想：不为数据加锁，而是为数据创建多个版本。

作用

提升并发性能

解决幻读问题

在RR隔离级别下，mvcc通过一致性视图read-view，有效的解决了快照读的幻读问题，当前读的幻读需要依赖临键锁解决。

依赖三个核心技术点

数据隐藏字段

DB_TRX_ID(6字节)

事务id：最近修改事务ID。记录最后一次插入或更新这条记录的事务ID

DB_ROLL_PTR(7字节）

回滚指针：指向这条记录的上一个版本的地址，该地址存储在 Undo Log 中

DB_ROW_ID(6字节）

行标识id：如果表没有定义主键，InnoDB 会自动生成一个聚簇索引基于这个字段。

MVCC 的本质：就是通过 Read View 这个一致性视图，在数据的 Undo Log 版本链中找到最适合当前事务的那个可见版本，从而实现非阻塞的读操作和高并发。

undo log 日志版本链

Undo Log 保存了数据被修改前的历史版本。当一条记录被多次修改，它的各个旧版本数据就会通过 DB_ROLL_PTR 指针串联成一个版本链

read-view 一致性视图

是什么？

Read View 是事务在执行快照读（普通 SELECT 语句）时产生的一个一致性视图。它决定了这个事务能看到哪个版本的数据。

何时创建？

1.在读已提交（RC）隔离级别下，每次执行快照读都会生成一个新的 Read View。 2.在可重复读（RR）隔离级别下，只在事务中第一次执行快照读时生成一个 Read View，后续所有读操作都复用这个视图。这正是 RR 级别实现“可重复读”的关键。该视图在事务结束前永远不会变化

组成元素

执行查询时所有未提交的事物id数组（数组里最小的事物id为min_id）和已创建的最大事务id（max_id）组成。

版本比对规则（数据可见性算法）

只有写操作才会生成事务id，读操作的事物id为零。

参照图

innodb日志底层原理

一条更新语句在数据库执行过程

核心参数

redo log核心参数

innodb_log_buffer_size

设置innodb_log_buffer大小的参数，默认16M,最大4G，最小为1M

innodb_log_group_home_dir

设置redolog日志文件存放位置,默认为’./’,即data/目录下

innodb_log_files_in_group

设置redolog文件个数，默认为2，ibd_logfile0,ibd_logfile1..，最大为100个

innodb_log_file_size

设置ibd_logfile磁盘文件大小，默认值为48M，最大值为512G（所有ibd_logfile总和大小不超512G）

innodb_flush_log_at_trx_commit

这个参数控制redolog写入策略3种选择： 1.设置为0，表示每次事务提交都是只是把redo_log留在redo_log_buffer中，数据库宕机会丢失数据。 2.设置为1，表示每次事务提交都将redo_log_buffer里的数据同步到磁盘，数据安全，不会因为数据库宕机而丢失数据，但是效率会低一点。 3.设置为2，表示每次事务提交都会把redo_log_buffer写到操作系统的page_cache里。这种情况如果数据库宕机不会丢失数据，但是操作系统宕机了，会丢数据

binglog

主要作用于备份恢复与主从复制

写入磁盘机制 sync_binglog参数控制

设置为0时，每次事务提交后，不做刷新到磁盘操作，而是让操作系统自行决定什么时候来同步，或者page_cache满了后才做同步到磁盘，系统宕机会丢数据

设置为1时，每次事务提交后都fsync强制刷新磁盘

设置为N>1,N次事务提交后，才通过fsync操作将数据写入磁盘。系统宕机会丢N次事务数据。

日志格式

undolog

innodb采用回滚段的方式管理，默认128个回滚段，每个回滚段支持1024个事务，意味着可以同时支持128乘以1024事务并发。

undolog什么时候删除

1.对于新增类型，事务提交后就删除了 2.修改内型不会立即删除，mvcc会使用，只有当没有事务用到时，才可以清除

redolog写入过程