InnoDB引擎

最新推荐文章于 2024-10-01 17:33:05 发布

半个菜鸟_

最新推荐文章于 2024-10-01 17:33:05 发布

阅读量1k

点赞数 20

文章标签： mysql 数据库

本文链接：https://blog.csdn.net/qq_62074445/article/details/137176234

版权

逻辑存储结构
架构
事务原理
MVCC

逻辑存储结构

表空间（ibd文件）：一个MySQL实例可以对应多个表空间，用于存储记录、索引等数据。

段：

分为：数据段（Leaf node segment）、索引段（Non-leaf node segment）、回滚段（Rollback segment）。

InnoDB是索引组织表，数据段就是B+树的叶子节点，索引段即为 B+树的非叶子节点，段用来管理多个Extent（区）

区：表空间单元结构，每个区的大小为1M。默认情况下，InnoDB存储引擎页大小为16K，即一个区中共有64个连续的页。

页：是InnoDB存储引擎磁盘管理的最小单位，每个页的大小默认为16KB。为了保证页的连续性，InnoDB存储引擎每次从磁盘申请4-5个区。

行：InnoDB存储引擎数据是按行进行存放的。

Trx_id：每次对某条记录进行改动时，都会把对应的事务id赋值给trx_id隐藏列。（最后一次操作时id）

Roll_pointer：每次对某条记录进行改动时，都会把旧的版本写入undo日志中，然后这个隐藏列就相当一个指针，可以通过它来找到该记录修改前的信息。（通过这个指针可以改动前的数据）

架构

MySQL5.5版本开始，默认使用InnoDB存储引擎。因为它擅长事务处理，具有崩溃恢复特性，在日常开发中使用非常广泛。

这里是InnoDB架构图，左侧为内存结构，右侧有磁盘结构。

内存结构

缓冲池：

更改缓冲区：

个人理解小结：

缓冲池类似于操作系统中的内存，是用于缓存表数据和索引数据的重要组件。

更改缓冲区可以理解为一个用于暂存等待对数据修改的缓冲池。

自适应哈希索引是一种优化策略，用于动态地创建哈希索引来加速一些查询。

日志缓冲区用于缓存事务日志，以提高事务提交的性能。

磁盘结构

这个后台线程目的是：将内存中数据存放到磁盘中

事务原理

事务介绍

事务是一组操作的集合，它是一个不可分隔的工作单位，事务会把所有的操作作为一个整体向系统提交或撤销操作请求，即这些操作要不同时成功，要不同时失败。

特性：ACID

原子性（Atomicity）：事务是不可分割的最小操作单元。

一致性（Consistency）：事务完成时，必须使所有数据都保持一致状态

隔离性（Isolation）：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行。

持久性（Durability）：事务一旦提交或回滚，它对数据库中的数据的改变是永久的。

redo log（重做日志） -> 持久性

重做日志：记录的是事务提交时数据页的物理修改，是用来实现事务的持久性。

该日志文件由两部分组成：

重做日志缓冲（redo log buffer）：在内存中

重做日志文件（redo log file）：磁盘中

当事务提交之后会把所有修改的信息都存储到日志文件中，用于刷新脏页到磁盘，发生错误时，进行数据恢复使用。

说一下上面这个图片的执行过程，让知道redo log的作用：

用户提交修改，到Buffer Pool中，并将数据页的变化写入到Redolog Buffer中。（知道当前页不会立即进行刷新，而是有规律时间的刷新。前面讲过，如果提交到Buffer Pool后，页变成脏页了）

Buffer Pool将内存中的信息存入磁盘中，先将Redolog 信息先写入，然后再是Buffer Pool中的信息

顺利进行，插入成功。

如果失败，就要用到Redolog中的保留的日志了，通过日志重新写入数据。

系统会过期清理不需要的在磁盘上的redolog文件。

undo log（回滚日志） -> 原子性

回滚日志：用于记录数据被修改前的信息，作用包含两个：提供回滚和 MVCC（多版本并发控制）。

undo log 和 redo log记录物理日志不同。undo log是逻辑日志。

下面进行一下解释：就是当用户进行一个delete记录时，undo log中会多出一条insert（与delete相反的操作记录），用于进行回滚。

Undo log销毁：undo log在事务执行时产生，事务提交时，并不会立即删除undo log，因为这些日志可能还用于MVCC。

Undo log存储：undo log采用段的方式进行管理和记录，存放在前面介绍的rollback segment回滚段中，内部包含1024个undo log segment。

MVCC

基本概念

当前读（加锁读）
- 读取的是记录的最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如：select ...lock in share mode（共享锁），select ... for update、update、insert、delete（排它锁）都是一种当前读
快照读（不加锁读）
- 简单的select（不加锁）就是快照读，读取的是记录数据的可见版本，有可能是历史数据，不加锁，是非阻塞读。
  - Read Committed：每次select，都生成一个快照读。
  - Repeatable Read：开启事务后第一个select语句才是快照读的地方。
  - Serializable：快照读会退化成当前读。
MVCC
- 全称Multi-Version Concurrency Control（多版本并发控制）。指维护一个数据的多个版本，使读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现，还需要依赖数据库记录中的三个隐式字段、undo log日志、readView。

记录中隐藏字段

undo log

回滚日志，在insert、update、delete的时候产生的便于数据回滚的日志
当insert的时候，产生的undo log日志只在回滚时需要，在事务提交后，可被立即删除
对于update、delete的时候，产生的undo log日志不仅在回滚的时候需要，在快照读也需要（MVCC中，快照读是通过查看数据库的历史版本来获取数据的），不会被立即删除

undo log 版本链

不同事务或相同事务对同一条记录进行修改，会导致该记录的undolog生成一条记录版本链表，链表的头部是最新的旧数据，尾部是最早的旧数据。

readView

readView（读视图）是 快照读SQL执行时MVCC提取的依据，记录并维护系统当前活跃的事务（未提交的）id。

ReadView中包含了四个核心字段：

字段	含义
m_ids	当前活跃的事务ID集合（尚未提交或回滚的事务）
min_trx_id	最小活跃事务ID（未提交或未回滚的事务ID）
max_trx_id	预分配事务ID，当前最大事务ID+1（因为事务ID是自增的）
creator_trx_id	ReadView创建者事务ID