InnoDB存储引擎

关注

原创最新推荐文章于 2025-07-09 10:49:11 发布 352 阅读 AI 写同款· GEO 优化 ›

Mysql技术内幕InnoDB存储引擎——InnoDB存储引擎 特此申明：前段时间找工作所以看了《Mysql技术内幕InnoDB存储引擎》，整理的时候除了参考网上已有的笔记贴，加上自己整合的，可能和别人有雷同之处。不过无所谓啦，写出来自己看看，需要的朋友参考下，仅此而已。一．mysql体系结构和存储引擎 1.1、数据库和实例的区别数据库：物理操作系统或其他形式文件类型的集合。在mysql下数据库文件可以是frm，阅读详情

01 | InnoDB存储结构

在这里插入图片描述

1.1 InnoDB内存结构（In-Memory Structures）

1.1.1 Buffer Pool：缓冲池

目的：避免频繁的随机IO读写影响数据库性能。
InnoDB存储数据，都是存放在表空间中，表空间实际对应着一个或者几个实际文件，访问数据时，InnoDB只能以Page页（默认16K）为单位进行读写，InnoDB通过Buffer Pool把加载进入内存的页缓存起来，避免立即释放，从而减少磁盘IO操作，提升效率。
查看Buffer Pool信息：

SHOW ENGINE INNODB STATUS;

Buffer Pool内部组成

Page管理机制
Page根据状态可分为以下三种类型：
- free page：空闲page，未被使用
- clean page：被使用page，但数据没有被修改过
- dirty page：脏页，被使用page，并且数据被修改过，page页中数据和磁盘数据产生了不一致
针对上述三种类型，InnoDB通过三种链表结构来维护和管理
- free list：空闲缓冲区，管理free page
- flush list：表示需要刷新到磁盘的缓冲区，管理dirty page，内部page按修改时间排序。脏页即存在于flush链表，也存在于LRU链表中，两种互不影响，LRU链表负责管理page的可用性和释放，flush链表负责管理脏页的刷盘操作
- lru list：表示正在使用的缓冲区，管理clean page和dirty page，缓冲区以midpoint为基点，前面链表称为new列表区，存放经常访问的数据，占63%；后面的链表称为old列表区，存放使用较少数据，占37%。
改进型LRU算法维护
- 普通LRU：末尾淘汰法，新数据从链表头部加入，释放空间时从末尾淘汰
- 改进LRU：链表分为new和old两个部分，加入元素时并不是从表头插入，而是从中间
  midpoint位置插入，如果数据很快被访问，那么page就会向new列表头部移动，如果
  数据没有被访问，会逐步向old尾部移动，等待淘汰。
  每当有新的page数据读取到buffer pool时，InnoDB引擎会判断是否有空闲页，是否足
  够，如果有就将free page从free list列表删除，放入到LRU列表中。没有空闲页，就会
  根据LRU算法淘汰LRU链表默认的页，将内存空间释放分配给新的页。
常用配置参数

show variables like '%innodb_page_size%'; -- 查看page页大小
show variables like '%innodb_old%'; -- 查看lru list中old列表参数
show variables like '%innodb_buffer%';  -- 查看buffer pool参数

建议：将innodb_buffer_pool_size设置为总内存大小的60%-80%，innodb_buffer_pool_instances可以设置为多个，这样可以避免缓存争夺。

1.1.2 Change Buffer：写缓冲区

在进行DML操作时，如果Buffer Pool没有相应的Page数据，并不会立刻将磁盘页加载到缓冲池，而是在Change Buffer记录缓存变更，等未来数据读取时，再将数据合并恢复到Buffer Pool中。
当更新一条记录时，如该记录在Buffer Pool中存在，则直接在Buffer Pool中修改，执行一次内存操作；如果该记录不存在（未命中），会直接在Change Buffer进行一次内存操作，不从磁盘查询数据，避免一次磁盘IO。当下次查询记录时，会先进行磁盘读取，然后再从Change Buffer中读取信息合并，最终载入Buffer Pool中。Change Buffer 主要节省的是随机读磁盘的 IO 消耗。
注1：写缓冲区仅适用于非唯一普通索引！！。如使用唯一索引，在进行DML时，InnoDB必须要要做唯一性校验，因此必须查询磁盘，将记录查询到Buffer Pool中，然后在Buffer Pool中修改，不会在Change Buffer 中操作。
注2：Buffer Pool中的避免磁盘IO是避免表空间数据的磁盘读写，Redo日志依旧需要进行磁盘读写

Change buffer更新过程说明：
change buffer 更新过程
假设输入语句为两条更新语句将id为3的value更改为c，id为7的value更改为u。

id为3的数据在page1页中，并且page1在Buffer Pool中，直接更新内存
id为7的数据没有在内存中，就在内存的change buffer中记录更新记录
将上述两个动作写入Redo log中
在这个过程中，避免了随机磁盘读写的性能消耗，只需要做一次Redo log的顺序读写。

1.1.3 Adaptive Hash Index：自适应哈希索引

用于优化对Buffer Pool数据的查询。InnoDB存储引起会监控对表索引的查找，如果观察到简历哈希索引可以带来速度的提升，则建立哈希索引。InnoDB存储引擎会自动根据访问的频率和模式来为某些页简历哈希索引。

1.1.3 Log Buffer：日志缓冲区

用来保存要写入磁盘上的log文件（Redo/Undo）的数据，日志缓冲区的内容会依据相应的策略刷新到磁盘log文件中。日志缓冲区满时会自动将其刷新到磁盘，当遇到BLOB或多行更新的大事物操作时，增加日志缓冲区可以节省磁盘I/O。可以通过调整innodb_flush_log_at_trx_commit参数控制日志刷新策略：

0：每隔1秒执行写日志文件和刷盘操作，最多丢失1秒数据
1：事物提交，立刻写日志文件和刷盘，数据不丢失，但会频繁IO操作（默认设置）
2：事物提交，立刻写日志文件，每隔1秒中进行刷盘操作（推荐设置）

1.2 InnoDB磁盘结构（On Disk Structures）

InnoDB磁盘主要包含Tablespaces、InnoDB Data Dictionary、Doublewrite Buffer、Redo log和Undo Logs。

1.2.1 表空间（Tablespaces）

用于存储表结构和数据。分为以下几种类型：

系统表空间（The System Tablespaces）： 包含InnoDB数据字典，Doublewrite Buffer、Change Buffer、Undo Logs的存储区域。系统表空间也默认包含任何用户在系统表空间创建的表数据和索引数据。系统表空间是一个共享的表空间因为它是被多个表共享的。该空间的数据文件通过参数innodb_data_file_path控制，默认值是ibdata1:12M:autoextend(文件名为ibdata1、12MB、自动扩展)。
独立表空间（File-Per-Table Tablespaces）： 5.6开始默认开启，独立表空间是一个单表表空间，用于存储用户数据，而非创建于系统表空间中。每一个表都有一个ibd文件，用于存储数据以及索引信息。基本表结构数据存储在.frm文件中。该表创建于自己的数据文件中。当innodb_file_per_table选项开启时，表将被创建在独立表空间中，否则创建在系统表空间中。每个表文件由一个.ibd数据文件代表，该文件默认被创建于数据库目录中。
通用表空间（General Tablespaces）： 通用表空间为通过create tablespace语法创建的共享表空间。通用表空间可以创建于mysql数据目录外的其他表空间，其可以容纳多张表，且其支持所有的行格式。
撤销表空间（Undo Tablespaces）： 撤销表空间由一个或多个包含Undo日志文件组成。在MySQL 5.7版本之前Undo占用的是System Tablespace共享区，从5.7开始将Undo从System Tablespace分离了出来。InnoDB使用的undo表空间由innodb_undo_tablespaces配置选项控制，默认为0。参数值为0表示使用系统表空间ibdata1;大于0表示使用undo表空间undo_001、undo_002等。
临时表空间（Temporary Tablespaces）： 临时表空间分为session temporary tablespaces 和global temporary tablespace两种。sessiontemporary tablespaces 存储的是用户创建的临时表和磁盘内部的临时表。globaltemporary tablespace储存用户临时表的回滚段（rollback segments ）。mysql服务器正常关闭或异常终止时，临时表空间将被移除，每次启动时会被重新创建。

1.2.2 数据字典（InnoDB Data Dictionary）

InnoDB数据字典由内部系统表组成，这些表包含用于查找表、索引和表字段等对象的元数据。元数据物理上位于InnoDB系统表空间中。由于历史原因，数据字典元数据在一定程度上与InnoDB表元数据文件（.frm文件）中存储的信息重叠。

1.2.3 双写缓冲区（Doublewrite Buffer）

位于系统表空间，是一个存储区域。在BufferPage的page页刷新到磁盘真正的位置前，会先将数据存在Doublewrite 缓冲区。如果在page页写入过程中出现操作系统、存储子系统或mysqld进程崩溃，InnoDB可以在崩溃恢复期间从Doublewrite 缓冲区中找到页面的一个好备份。在大多数情况下，默认情况下启用双写缓冲区，要禁用Doublewrite 缓冲区，可以将innodb_doublewrite设置为0。使用Doublewrite 缓冲区时建议将innodb_flush_method设置为O_DIRECT。

1.2.4 重做日志（Redo Log）

重做日志是一种基于磁盘的数据结构，大小固定，用于在崩溃恢复期间更正不完整事务写入的数据。MySQL以循环方式写入重做日志文件，记录InnoDB中所有对Buffer Pool修改的日志。当出现实例故障（像断电），导致数据未能更新到数据文件，则数据库重启时须redo，重新把数据更新到数据文件。读写事务在执行的过程中，都会不断的产生redo log。默认情况下，重做日志在磁盘上默认由两个名为ib_logfile0和ib_logfile1的文件物理表示，类似“衔尾蛇”首尾相连，如下图所示。
在这里插入图片描述
write pos是当前记录的位置，一边写一边后移，check point是当前要擦出的位置，擦出记录前要把记录更新到数据文件。

1.2.5 撤销日志（Undo Logs）

撤消日志是在事务开始之前保存的被修改数据的备份，用于例外情况时回滚事务。撤消日志属于逻辑日志，根据每行记录进行记录。撤消日志存在于系统表空间、撤消表空间和临时表空间中。

作用

实现事物的原子性
Undo Log是为了实现事物的原子性而出现的产物。事物处理过程中，如果出现了错误或者用户执行了ROLLBACK语句，MySQL可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。
实现多版本的并发控制（MVCC）
Undo Log在Mysql InnoDB存储引擎中用来实现多版本并发控制，事务未提交前，Undo Log保存了未提交之前的版本数据，Undo Log中的数据可作为数据旧版本快照供其他并发事物进行快照读。

在这里插入图片描述

事物1update表中记录，mysql会将表中的记录备份到Undo Buffer中
如果rollback，将会从Undo Buffer中读取原始数据进行恢复
如果多个事物同事读取这条记录，会从Undo Buffer中读取这条记录（RR）

02 | InnoDB线程模型

线程模型维护了缓存数据的更新以及磁盘刷盘的操作。
在这里插入图片描述

2.1 IO Thread

在InnoDB中使用了大量的AIO（Async IO）来做读写处理，这样可以极大提高数据库的性能，主要负责IO请求的回调处理。在InnoDB1.0版本之前共有4个IO Thread，分别是write，read，insert buffer和log thread，后来版本将read thread和write thread分别增大到了4个，一共有10个了，可通过SHOW ENGINE INNODB STATUS查看，如图所示。
在这里插入图片描述

read thread（4个）：负责读取操作，将数据从磁盘加载到缓存page页
write thread（4个）：负责写操作，将缓存脏页刷新到磁盘
log thread（1个）：负责将日志缓冲区内容刷新到磁盘
insert buffer thread（1个）：负责将写缓冲内容刷新到磁盘

2.2 Purge Thread

事物提交之后，回收已经分配的undo页

2.3 Page Cleaner Thread

将脏数据刷新到磁盘，脏数据刷盘后相应的redo log也就可以覆盖，即可以同步数据，又能达到redo log循环使用的目的，会调用write thread线程进行处理。

2.4 Master Thread

Master thread是InnoDB的主线程，负责调度其他各线程，优先级最高。作用是将缓冲池中的数据异步刷新到磁盘，保证数据的一致性。包含：脏页的刷新（page cleaner thread）、undo页回收（purge thread）、redo日志刷新（log thread）、合并写缓冲等。内部有两个主处理，分别是每隔1秒和10秒处理。
每1秒的操作：

刷新日志缓冲区，刷到磁盘
合并写缓冲区数据，根据IO读写压力来决定是否操作
刷新脏页数据到磁盘，根据脏页比例达到75%才操作（innodb_max_dirty_pages_pct，innodb_io_capacity）

每10秒的操作：

刷新脏页数据到磁盘
合并写缓冲区数据
刷新日志缓冲区
删除无用的undo页

03 | InnoDB数据文件

InnoDB文件存储结构

在这里插入图片描述

Tablespace： 表空间，用于存储多个ibd数据文件，而ibd文件用于存储表的记录和索引，一个文件包含多个Segment。
Segment： 段，用于管理多个Extent，分为数据段、索引段、回滚段。一个表至少包含两个Segment，一个管理数据，一个管理索引。每多创建一个索引，会多两个Segment
Extent： 区，一个区固定包含64个连续的页，大小默认为1M。当表空间不足，需要分配新的页资源，不会一页一页的分，而是直接分配一个区
Page： 页，用于存储多个Row记录，大小默认为16K。包含多种页类型，比如数据页、undo页、系统页、事务数据页、BLOB对象页。Page是文件最基本的单位，无论何种类型的Page页，都是由Page Header（页头）、Page Trailer（页尾）和Page Body组成。
Row： 行，包含记录的字段值、事物ID、滚动指针、字段指针等信息。表的行格式决定了它的行是如何物理存储的，这反过来又会影响查询和DML操作的性能。InnoDB存储引擎支持一下四种行格式：
- REDUNDANT
  使用REDUNDANT行格式，表会将变长列值的前768字节存储在B树节点的索引记录中，其余
  的存储在溢出页上。对于大于等于786字节的固定长度字段InnoDB会转换为变长字段，以便
  能够在页外存储。
- COMPACT
  与REDUNDANT行格式相比，COMPACT行格式减少了约20%的行存储空间，但代价是增加了
  某些操作的CPU使用量。如果系统负载是受缓存命中率和磁盘速度限制，那么COMPACT格式
  可能更快。如果系统负载受到CPU速度的限制，那么COMPACT格式可能会慢一些。
- DYNAMIC（默认）
  使用DYNAMIC行格式，InnoDB会将表中长可变长度的列值完全存储在页外，而索引记录只
  包含指向溢出页的20字节指针。大于或等于768字节的固定长度字段编码为可变长度字段。
  DYNAMIC行格式支持大索引前缀，最多可以为3072字节，可通过innodb_large_prefix参数
  控制。
- COMPRESSED
  COMPRESSED行格式提供与DYNAMIC行格式相同的存储特性和功能，但增加了对表和索引
  数据压缩的支持。