MySQL进阶：InnoDB引擎

InnoDB引擎

逻辑存储结构

—表空间
对应ibd文件，用于存储记录、索引等数据。
---------段
分为数据段（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和Roll_pointer两个隐藏字段：
Trx_id: 每次对某条记录进行改动时，都会把对应的事务id值赋给trx_id隐藏列。
Roll_pointer: 每次对某条记录进行改动时，都会把旧的版本写入到undo日志当中，然后这个隐藏列相当于一个指针，指向旧版本日志。

架构

内存架构

• Buffer Pool：缓冲池以页（page）为单位缓存磁盘上经常操作的数据，在执行增删改查操作时，先操作缓冲池中的数据（没有数据，则从磁盘加载并缓存），然后再以以一定频率刷新到磁盘。减少磁盘IO，加快处理速度。
  缓冲池中的页以链表数据结构管理。页分为3种：
  free page：未被使用的页。
  clean page：被使用的页，数据没有被修改。
  dirty page：被使用的页，但数据已经被修改，和磁盘数据不一致。
• Chang Buffer：更改缓冲区，主要针对非唯一二级索引。执行DML操作时，如果Buffer Pool中没有相应缓冲数据，则先将DML操作信息存放在更改缓冲区，等待到相应数据从磁盘加载到Buffer Pool中后，进行合并处理，从而减少磁盘IO。
• Adaptive Hash Index：给缓冲池中的页建立哈希索引，由系统自动完成。
• log buffer：先将日志缓存到log buffer中，定期刷新到磁盘中。增删改操作很多时，可以适当增大日志缓冲区大小（innodb_log_buffer_size）。
  innodb_flush_log_at_trx_commit:日志刷新到磁盘的时机，1：日志在每次事务提交时写入并刷新到磁盘。0：每秒将日志写入并刷新到磁盘一次。
  2：日志在每次事务提交后写入，并每秒刷新到磁盘一次。

磁盘架构

• System Tablespace: 存放change buffer
• File-Per-Table Tablespace：每张表的表空间。
• General Tablespace：通用表空间，用户自己指定，用的比较少。
  undo tablespace：撤销表空间，mysql实例初始化时自动创建两个，初始大小16M，用于存储undo log。
• Temporary Tablespace：InnoDB分会话临时表空间和全局临时表空间。存储用户创建的临时表等数据。
• Doublewrite Buffer Files：双写缓冲区，将数据页从Buffer Pool刷新到磁盘前，先将数据页写入双写缓冲区文件中，便于系统异常时恢复数据。
• 重做日志。当事务提交后，会把所有修改信息存到该日志中，用于在刷新脏页到磁盘时，发生错误时，进行数据恢复使用。
  以循环方式写入文件：ib_logfile0, ib_logfile1。

后台线程

将缓冲池的数据在合适时机刷新到磁盘当中
分4类：

• Master Thread：
  负责调度其他线程，还负责将缓冲池中的数据异步刷新到磁盘中，保持数据一致性。还包括脏页的刷新，合并插入缓cu存，undo页的回收。
• IO Thread
  主要负责处理IO请求。

  线程类型	默认个数	职责
  Read Thread	4	负责读操作
  Write Thread	4	负责写操作
  Log Thread	1	负责将日志缓冲区刷新到磁盘
  Insert buffer thread	1	负责将写缓冲区内容刷新到磁盘

• Purge Thread
  主要用于回收事务已经提交了的undo log。
• Page Cleaner Thread
  协助Master Thread刷新脏页到磁盘的线程，减轻Master Thread的压力，减少阻塞。

事务原理

redo log和undo log来保证原子性、一致性和持久性。
锁机制和MVCC来保证隔离性。

• redo log保证数据持久性。
• undo log是逻辑日志，当delete时，undo log存放一条insert，update时，存反向的update。undo log在事务执行时产生，事务提交时，并不会立即删除undo log，因为这些日志可能还用于MVCC。
  undo log存储：采用段的方式进行管理和记录，存放在rollback segment中，内部包含1024个undo log segment。

MVCC

基本概念

• 当前读：读取的是记录最新版本。加锁的select就是当前读。
• 快照读：普通的select语句，不加锁。读取的是数据可见版本，有可能是历史数据。
  Read Committed：每次select都生成一个快照读。
  Repeatable Read：开启事务后第一个select语句才是快照读的地方，后面的直接读取生成的快照。
  Serializable：快照读会退化为当前读。
• MVCC：Multi-Version Concurrency Control，多版本并发控制。维护数据的多个版本，使得读写操作没有冲突。快照读为Mysql实现MVCC提供了非阻塞读功能。MVCC还需依赖数据库记录中三个隐式字段、undo log，readView。

隐式字段

DB_TRX_ID：最近影响该行的事务id。
DB_ROLL_PTR：帮助找到undo log，指向记录上一个版本。
DB_ROW_ID：隐藏主键，如果表结构没有指定主键，才会生成该隐藏字段。

undo log版本链

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oR4oN2Hv-1687157391327)(image-2.png)]

ReadView

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

包含4个核心字段

• m_ids: 当前活跃的事务ID集合
• min_trx_id: 最小活跃事务ID
• max_trx_id: 预分配事务ID，当前最大事务ID+1（事务ID是自增的）
• creator_trx_id: ReadView创建者的事务ID

版本链数据访问规则

trx_id: 代表当前版本记录事务ID

1. trx_id == creator_trx_id ? 可以访问该版本。（条件成立，说明数据是当前这个事务更改的。）
2. trx_id < min_trx_id ? 可以访问该版本。（条件成立，说明数据已经提交了。）
3. trx_id > max_trx_id ? 不可以访问该版本。（条件成立，说明该事务是在ReadView生成后才开启。）
4. min_trx_id $<=$ trx_id $<=$ max_trx_id 且 trx_id $\notin$ m_ids ? 可以访问该版本 （条件成立，说明数据已经提交。）

不同隔离级别，生成ReadView的时机不同。（见基本概念—快照读）。
_id $\notin$ m_ids ? 可以访问该版本 （条件成立，说明数据已经提交。）

不同隔离级别，生成ReadView的时机不同。（见基本概念—快照读）。