MySQL进阶篇-InnoDB引擎（逻辑存储布局、内存布局、磁盘布局、背景线程、变乱原理、MVCC）

假如想相识更多与 MySQL 干系的内容，可以检察 MySQL 专栏：MySQL
视频教程：进阶-InnoDB引擎-逻辑存储布局
1. 逻辑存储布局

1.1 表空间（Tablespace）

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

---

Linux 环境下安装的 MySQL 数据默认存放在 /var/lib/mysql 目次下

1. cd /var/lib/mysql

复制代码

我们可以进入到某一个数据库对应的目次下，检察全部表空间文件（每一个 idb 文件都是一个表空间文件）

1. cd blog

复制代码

1. ls -l

复制代码

1.2 段（Segment）

段，分为数据段（Leaf node segment）、索引段（Non-leaf node segment）、回滚段（Rollback segment）
InnoDB 是索引构造表，数据段就是B+树的叶子节点，索引段即为B+树的非叶子节点
1.3 区（Extent）

区，表空间的单元布局，每个区的巨细为1M
默认环境下，InnoDB存储引擎页巨细为16K，即一个区中一共有64个一连的页
1.4 页（Page）

页，是InnoDB 存储引擎磁盘管理的最小单元，每个页的巨细默以为 16 KB。为了包管页的一连性，InnoDB 存储引擎每次会从磁盘申请 4 - 5 个区
1.5 行（Row）

InnoDB 存储引擎是按行举行存放数据的

• Trx_id：每次对某条记载举行改动时，都会把对应的变乱 id 赋值给trx_id隐蔽列
  
• Roll_pointes：每次对某条引记载举行改动时，都会把旧的版本写入到 undo 日志中，然后这个隐蔽列就相称于一个指针，可以通过它来找到该记载修改前的信息
  

2. 架构

从 5.5 版本开始，MySQL 默认使用 InnoDB 存储引擎。InnoDB 存储引擎善于变乱处理处罚，具有瓦解规复特性，在一样平常开辟中使用非常广泛

---

下面是 InnoDB 的架构图，左侧为内存布局，右侧为磁盘布局

2.1 内存布局

2.1.1 Buffer Pool（缓冲池）

   一样平常来说， MySQL 会单独摆设到一台服务器上，这台服务器 80% 的内存都会分配给缓冲池
  Buffer Pool：缓冲池，主内存中的一个地域，内里可以缓存磁盘上常常利用的真实数据，在实行增编削查利用时，先利用缓冲池中的数据（若缓冲池中没有数据，则从磁盘加载并缓存），然后再以肯定频率革新到磁盘，从而淘汰磁盘IO，加速处理处罚速率

---

缓冲池以 Page 为单元，底层接纳链表数据布局管理 Page。根据状态，将Page分为三种范例：

• free page：空闲 Page，未被使用
  
• clean page：被使用的 Page，数据没有被修改过
  
• dirty page：脏页，被使用过的 Page，数据被修改过，也中数据与磁盘的数据产生了不同等
  

2.1.2 Change Buffer（更改缓冲区）

   

• Change Buffer（更改缓冲区）是在 MySQL 8.x 版本中才出现的
  
• 在 MySQL 5.x 版本中，对应地域被称作 Insert Buffer（插入缓冲区）
  

  Change Buffer：更改缓冲区（针对于非唯一二级索引页），在实行DML语句时，假如数据 Page 没有在Buffer Pool中，不会直接利用磁盘，而会将数据变动存在更改缓冲区 Change Buffer 中，在将来数据被读取时，再将数据归并规复到Buffer Pool 中，再将归并后的数据革新到磁盘中

---

Change Buffer的意义：

• 与聚集索引差别，二级索引通常黑白唯一的，而且以相对随机的次序插入二级索引
  
• 同样，删除和更新大概会影响索引树中不相邻的二级索引页，假如每一次都利用磁盘，会造成大量的磁盘IO
  
• 有了 Change Buffer 之后，我们可以在缓冲池中举行归并处理处罚，淘汰磁盘IO
  

2.1.3 Adapted Hash Index（自顺应哈希索引）

   自顺应哈希索引无需人工干预，是体系根据环境自动完成
  Adaptive Hash Index：自顺应 Hash 索引，用于优化对Buffer Pool数据的查询
InnoDB存储引擎会监控对表上各索引页的查询，假如观察到 Hash 索引可以提升速率，则创建 Hash 索引，称之为自顺应hash索引

---

在 MySQL 终端中可以检察自顺应哈希索引是否已开启

1. show variables like '%hash_index%';

复制代码

2.1.4 Log Buffer（日志缓冲区）

Log Buffer：日志缓冲区，用来生存要写入到磁盘中的 log 日志数据（redo log、undo log），默认巨细为 16 MB，日志缓冲区的日志会定期革新到磁盘中。假如必要更新、插入或删除许多行的变乱，增长日志缓冲区的巨细可以节省磁盘 IO

---

与日志缓冲区干系的参数：

• innodb_log_buffer_size：缓冲区巨细
  
• innodb_flush_log_at_trx_commit：日志革新到磁盘机遇
  

---

innodb_flush_log_at_trx_commit 是MySQL数据库中InnoDB存储引擎的一个关键设置参数，它控制着变乱日志的革新频率，即变乱提交时日志被写入磁盘的活动。这个参数有几个取值：

• 0：每隔一秒，日志缓存被革新到磁盘，而且日志文件同步。假如MySQL瓦解，大概会丢失末了一秒的变乱
  
• 1（默认值，也是保举值）：每次变乱提交时，InnoDB都会将日志缓存写入并革新到磁盘上的日志文件。这确保了变乱的ACID特性，纵然体系瓦解也不会丢失变乱
  
• 2：每次变乱提交时，InnoDB会将日志缓存写入到日志文件，但并不会每次都举行革新到磁盘的利用，而是依赖利用体系来决定何时实行现实的磁盘写入。假如体系瓦解，大概会丢失一些末了提交的变乱
  

---

在 MySQL 终端中可以检察与日志缓冲区干系的参数

1. show variables like '%log_buffer_size%';
2. show variables like '%flush_log%';

复制代码

2.2 磁盘布局

2.2.1 System Tablespace（体系表空间）

System Tablespace：体系表空间是更改缓冲区的存储地域。假如表是在体系表空间而不是每个表空间文件或通用表空间中创建的，它也大概包罗表和索引数据。（在 MySQL 5.x 版本中还包罗 InnoDB 数据字典、undolog等）
干系参数：innodb_data_file_path
2.2.2 File-Per-Table Tablespaces（每个表的文件表空间）

File-Per-Table Tablespaces：每个表的文件表空间，包罗单个 InnoDB 表的数据和索引，存储在文件体系上的单个数据文件中
干系参数：innodb_file_per_table
2.2.3 General Tablespaces（通用表空间）

General Tablespaces：通用表空间，必要通过 CREATE TABLESPACE 语法创建通用表空间。在创建表时，可以指定该表空间
2.2.4 Undo Tablespaces（取消表空间）

Undo Tablespaces：取消表空间，MySQL实例在初始化时会自动创建两个默认的 undo 表空间（初始巨细16M），用于存储 undolog 日志
2.2.5 Temporary Tablespaces（暂时表空间）

Temporary Tablespaces：InnoDB 使用会话暂时表空间和全局暂时表空间存储用户创建的暂时表等数据
2.2.6 Doublewrite Buffer Files（双写缓冲区）

Doublewrite Buffer Files：双写缓冲区，InnoDB引擎将数据页从 Buffer Pool 革新到磁盘前，将数据页写入双写缓冲区文件中，便于体系非常时规复数据

2.2.7 Redo Log（重做日志）

Redo Log：重做日志，用来实现变乱的长期性。该日志文件由两部门构成

• 重做日志缓冲（redo log buffer）
  
• 重做日志文件（redo log）
  

重做日志缓冲在内存中，而重做日志文件在磁盘中。当变乱提交之后会把全部修改信息都会存到该日志中，用于在革新脏页到磁盘时，发生错误时，举行数据规复使用
2.3 背景线程

2.3.1 Master Thread

Master Thread是 InnoDB 存储引擎中一个非常焦点的线程，它负责和谐和实行 InnoDB 存储引擎中的许多背景任务。以下是 Master Thread 的重要作用：

• 革新脏页：定期将缓冲池中的脏页（已修改但未写入磁盘的页）革新到磁盘上，以保持数据的同等性
  
• 归并插入缓冲：定期将插入缓冲（Insert Buffer）中的数据归并到辅助索引页中，以优化插入利用的性能
  
• 革新日志缓冲：定期将日志缓冲（Log Buffer）中的数据革新到磁盘上的重做日志文件（Redo Log File），以确保变乱的长期性
  
• 整理无用的undo日志：定期整理不再必要的undo日志，开释空间。
  

2.3.2 IO Thread

在 InnoDB 存储引擎中大量使用了 AIO 来处理处罚 IO 哀求，如许可以极大地进步数据库的性能，而 IOThread 重要负责这些 IO 哀求的回调
线程范例默认个数职责Write Thread4负责将脏页从缓冲池写入磁盘。这些线程实行现实的磁盘写入利用Read Thread4负责从磁盘读取页到缓冲池。这些线程实行磁盘读取利用以添补缓冲池Insert Buffer1负责归并插入缓冲（Change Buffer）中的记载到辅助索引页Log IO Thread1负责将日志缓冲区的内容革新到磁盘上的重做日志文件2.3.3 Purge Thread

Purge Thread 负责以下任务：

• 整理已经提交的变乱不再必要的旧版本数据
  
• 接纳 undo 页，以开释空间供新变乱使用
  

2.3.4 Page Cleaner Thread

Page Cleaner Thread 的作用包罗：

• 帮助 Master Thread 革新脏页，淘汰 Master Thread 的工作负载
  
• 管理 InnoDB 缓冲池的脏页革新，以保持缓冲池的干净
  

3. 变乱原理

MySQL-根本篇-变乱（变乱简介、变乱利用、变乱的四大特性、并发变乱引发的题目、变乱的隔离级别）

3.1 redo log

视频教程：进阶-InnoDB引擎-变乱原理-redo log

---

redo log：重做日志，记载的是变乱提交时数据页的物理修改
日志文件由两部门构成：重做日志缓冲（redo log buffer）以及重做日志文件（redo log file），重做日志缓冲在内存中，重做日志文件在磁盘中
当变乱提交之后会把全部修改信息都存到日志文件中，用于在革新脏页到磁盘发生错误时举行数据规复

3.2 undo log

undo log：回滚日志，用于记载数据被修改前的信息，有提供回滚、MVCC（多版本并发控制）两个作用

---

undo log 和 redo log 记载物理日志不一样，undo log 记载的是逻辑日志。可以以为当 delete 一条记载时，undolog 中会记载一条对应的 insert 记载；当 update 一条记载时，它记载的是 update 语句实行之前的记载；当实行 rollback 利用时，就可以从 undo log 的逻辑记载中读取到相应的内容并举行回滚

• undo log 烧毁：undo log 在变乱实行时产生，变乱提交时，并不会立即删除 undo log，由于这些日志大概还用于MVCC
  
• undo log 存储：undo log 接纳段的方式举行管理和记载，存放在前面先容的 rollback segment 回滚段中，内部包罗 1024 个 undo log segment
  

4. MVCC

视频教程：84.进阶-InnoDB引擎-MVCC-根本概念

• 原子性：undo log
  
• 长期性：redo log
  
• 同等性：undo log + redo log
  
• 隔离性：锁 + MVCC
  

4.1 根本概念

4.1.1 当前读

读取的是记载的最新版本，读取时还要包管其他并发变乱不能修改当前记载，会对读取的记载举行加锁
以下一样平常利用都是一种当前读

• select … lock in share mode（共享锁）
  
• select … for update
  
• update
  
• insert
  
• delete（排他锁）
  

4.1.2 快照读

简单的 select （不加锁）就是快照读。快照读，读取的是记载数据的可见版本，有大概是汗青数据，不加锁，黑白壅闭读

---

差别变乱隔离级别下的快照读

• Read committed：每次实行 select 语句都会天生一个快照读
  
• Repeatable Read：开启变乱后第一个 select 语句才是快照读的地方
  
• Serializable：快照读会退化为当前读
  

4.1.3 MVCC

MVCC（Multi-Version Concurrency Control，多版本并发控制）是一种用于数据库管理体系中的并发控制技能，它允许多个变乱同时对同一数据举行读取和修改，而不会相互干扰
MVCC通过生存数据行的多个版原来实现并发控制。每个变乱在修改数据时，都会天生一个新的版本，而不是直接覆盖旧数据
在变乱开始时，数据库会为变乱创建一个数据快照，变乱中的全部读取利用都是基于这个快照举行的。MVCC 的具体实现，必要依赖于数据库记载中的三个隐式字段、undolog 日志和 readView
4.2 隐蔽字段

隐蔽字段字段名寄义DB_TRX_ID变乱ID记载末了修改本行数据的变乱ID，用于MVCC和变乱回滚DB_ROLL_PTR回滚指针指向该行记载的Undo Log信息，用于在变乱回滚时取消对该行的修改DB_ROW_ID行ID假如表没有主键，InnoDB会自动天生一个行ID来作为聚簇索引的键值可以运行以下指令来检察某张表的隐蔽字段（blog 是数据库名，course 是表名）

1. cd /var/lib/mysql
2. && cd blog
3. && sudo ibd2sdi course.ibd

复制代码

4.3 undo log版本链

undolog：回滚日志，在实行 insert、update、delete 语句的时间产生，便于数据回滚的日志

• 当 insert 的时间，产生的 undolog 日志只在回滚时必要，在变乱提交后，可被立即删除
  
• 当实行 update、delete 语句的时间，产生的 undolog 日志不光在回滚时必要，在快照读时也必要，不会立即被删除
  

---

undo log 版本链：差别变乱或雷同变乱对同一条记载举行修改，会导致该记载的 undolog 天生一条记载版本链表，链表的头部是最新的旧记载，链表尾部是早的旧记载
4.4 ReadView（四个焦点字段）

ReadView（读视图）是快照读 SQL 实行时 MVCC 提取数据的依据，记载并维护体系当前活泼的变乱（未提交的变乱）的 id
ReadView 中包罗的四个焦点字段：
字段名寄义m_ids当前体系中活泼的读写变乱的变乱ID列表。这些变乱大概修改了数据，因此读取利用必要思量这些变乱min_trx_id在创建ReadView时，当前体系中活泼的读写变乱中最小的变乱IDmax_trx_id在创建ReadView时，体系应该分配给下一个变乱的变乱ID。这个值是当前最大变乱ID加1，由于变乱ID是自增的creator_trx_id创建这个ReadView的变乱的变乱ID。对于只读变乱，这个值是0。对于读写变乱，这个值是变乱自己的变乱ID假设 trx_id 代表当前变乱的 id，版本链数据访问规则如下

差别的隔离级别，天生 Readview 的机遇差别：

• READ COMMITTED：在变乱中每一次实行快照读时天生 ReadView
  
• REPEATABLE READ：仅在变乱中第一次实行快照读时天生 ReadView，后续复用该 ReadView
  

4.5 原理分析（READ COMMITTED级别）

当变乱隔离级别是 READ COMMITTED 时，天生 Readview 的机遇是在变乱中每一次实行快照读时

第一个 ReadView（终极读取到的数据是 0x00002 对应的数据）

第二个 ReadView（终极读取到的数据是 0x00003 对应的数据）

4.6 原理分析（REPEATABLE READ级别）

REPEATABLE READ 隔离级别下，仅在变乱中第一次实行快照读时天生 ReadView，后续复用该 ReadView

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。