欢迎大家关注 github.com/hsfxuebao ，希望对大家有所帮助，要是觉得可以的话麻烦给点一下Star哈

为了管理方便，人们把连接管理、查询缓存、语法解析、查询优化这些并不涉及真实数据存储的功能划分为 MySQL server的功能，把真实存取数据的功能划分为存储引擎的功能。所以在MySQL server完成了查询优化 后，只需按照生成的执行计划调用底层存储引擎提供的API,获取到数据后返回给客户端就好了。

MySQL中提到了存储引擎的概念。简而言之，存储引擎就是指表的类型。其实存储引擎以前叫做表处理器，后来 改名为存储引擎，它的功能就是接收上层传下来的指令，然后对表中的数据进行提取或写入操作。

1. 查看存储引擎

查看mysql提供什么存储引擎：

show engines;
复制代码

show engines \G;
复制代码

显式如下：

*************************** 1. row ***************************
   Engine: InnoDB
  Support: DEFAULT
  Comment: Supports transactions, row-level locking, and foreign keys
Transactions: YES
     XA: YES
Savepoints: YES
*************************** 2. row ***************************
   Engine: MRG_MYISAM
  Support: YES
  Comment: Collection of identical MyISAM tables
Transactions: NO
     XA: NO
Savepoints: NO
*************************** 3. row ***************************
   Engine: MEMORY
  Support: YES
  Comment: Hash based, stored in memory, useful for temporary tables
Transactions: NO
     XA: NO
Savepoints: NO
*************************** 4. row ***************************
   Engine: BLACKHOLE
  Support: YES
  Comment: /dev/null storage engine (anything you write to it disappears)
Transactions: NO
     XA: NO
Savepoints: NO
*************************** 5. row ***************************
   Engine: MyISAM
  Support: YES
  Comment: MyISAM storage engine
Transactions: NO
     XA: NO
Savepoints: NO
*************************** 6. row ***************************
   Engine: CSV
  Support: YES
  Comment: CSV storage engine
Transactions: NO
     XA: NO
Savepoints: NO
*************************** 7. row ***************************
   Engine: ARCHIVE
  Support: YES
  Comment: Archive storage engine
Transactions: NO
     XA: NO
Savepoints: NO
*************************** 8. row ***************************
   Engine: PERFORMANCE_SCHEMA
  Support: YES
  Comment: Performance Schema
Transactions: NO
     XA: NO
Savepoints: NO
*************************** 9. row ***************************
   Engine: FEDERATED
  Support: NO
  Comment: Federated MySQL storage engine
Transactions: NULL
     XA: NULL
Savepoints: NULL
复制代码

2. 设置系统默认的存储引擎

查看默认的存储引擎：

show variables like '%storage_engine%';
#或
SELECT @@default_storage_engine;
复制代码

修改默认的存储引擎 如果在创建表的语句中没有显式指定表的存储引擎的话，那就会默认使用 InnoDB 作为表的存储引擎。 如果我们想改变表的默认存储引擎的话，可以这样写启动服务器的命令行：

SET DEFAULT_STORAGE_ENGINE=MyISAM;
复制代码

或者修改my.cnf 文件：

default-storage-engine=MyISAM
# 重启服务
systemctl restart mysqld.service
复制代码

3. 设置表的存储引擎

存储引擎是负责对表中的数据进行提取和写入工作的，我们可以为 不同的表设置不同的存储引擎 ，也就是 说不同的表可以有不同的物理存储结构，不同的提取和写入方式。

3.1 创建表时指定存储引擎

我们之前创建表的语句都没有指定表的存储引擎，那就会使用默认的存储引擎InnoDB 。如果我们想显式的指定一下表的存储引擎，那可以这么写：

CREATE TABLE 表名(
 建表语句;
) ENGINE = 存储引擎名称;
复制代码

3.2 修改表的存储引擎

如果表已经建好了，我们也可以使用下边这个语句来修改表的存储引擎：

ALTER TABLE 表名 ENGINE = 存储引擎名称;
复制代码

比如我们修改一下 engine_demo_table 表的存储引擎：

mysql> ALTER TABLE engine_demo_table ENGINE = InnoDB;
Query OK, 0 rows affected (0.05 sec)
Records: 0 Duplicates: 0  Warnings: 0
复制代码

这时我们再查看一下engine_demo_table的表结构：

mysql> SHOW CREATE TABLE engine_demo_table\G
*************************** 1. row ***************************
   Table: engine_demo_table
Create Table: CREATE TABLE `engine_demo_table` (
 `i` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.01 sec)
复制代码

4. 引擎介绍

4.1 InnoDB 引擎：具备外键支持功能的事务存储引擎

• MySQL从3.23.34a开始就包含InnoDB存储引擎。 大于等于5.5之后，默认采用InnoDB引擎。
• InnoDB是MySQL的 默认事务型引擎 ，它被设计用来处理大量的短期(short-lived)事务。可以确保事务的完整提交(Commit)和回滚(Rollback)。
• 除了增加和查询外，还需要更新、删除操作，那么，应优先选择InnoDB存储引擎。
• 除非有非常特别的原因需要使用其他的存储引擎，否则应该优先考虑InnoDB引擎。
• 数据文件结构：
  • 表名.frm 存储表结构（MySQL8.0时，合并在表名.ibd中）
  • 表名.ibd 存储数据和索引
• InnoDB是 为处理巨大数据量的最大性能设计 。
  • 在以前的版本中，字典数据以元数据文件、非事务表等来存储。现在这些元数据文件被删除了。比如：.frm ， .par ， .trn ， .isl ， .db.opt 等都在MySQL8.0中不存在了。
• 对比MyISAM的存储引擎，InnoDB写的处理效率差一些 ，并且会占用更多的磁盘空间以保存数据和索引。
• MyISAM只缓存索引，不缓存真实数据；InnoDB不仅缓存索引还要缓存真实数据， 对内存要求较高，而且内存大小对性能有决定性的影响。

4.2 MyISAM 引擎：主要的非事务处理存储引擎

• MyISAM提供了大量的特性，包括全文索引、压缩、空间函数(GIS)等，但MyISAM 不支持事务、行级锁、外键 ，有一个毫无疑问的缺陷就是 崩溃后无法安全恢复 。
• 5.5之前默认的存储引擎
• 优势是访问的 速度快 ，对事务完整性没有要求或者以SELECT、INSERT为主的应用
• 针对数据统计有额外的常数存储。故而 count( * ) 的查询效率很高
• 数据文件结构：
  • 表名.frm 存储表结构
  • 表名.MYD 存储数据 (MYData)
  • 表名.MYI 存储索引 (MYIndex)
• 应用场景：只读应用或者以读为主的业务

4.3 Archive 引擎：用于数据存档

• archive是归档的意思，仅仅支持插入和直询两种功能（行被插入后不能再修改）。
• 在MySQL5.5以后支持索引功能。|
• 拥有很好的压缩机制，使用zlib压缩库，在记录请求的时候实时的进行压缩，经常被用来作为仓库使用。
• 创建ARCHIVE表时，存储引擎会创建名称以表名开头的文件。数据文件的扩展名为.ARZ。
• 根据英文的测试结论来看，同样数据量下，Archive表比MyISAM表要小大约75%,比支持事务处理的工nnoDB表 小大约83%。
• ARCHIVE存储引擎采用了行级锁。该ARCHIVE弓|擎支持AUTO_INCREMENT 列属性。AUTO_INCREMENT可以 具有唯一索引或非唯一索引。尝试在任何其他列上创建索引会导致错误。
• Archive表适合日志和数据采集（档案）类应用；适合存储大量的独立的作为历史记录的数据。拥有很高的插入 速度，但是对查询的支持较差。
• 下表展示了ARCHIVE存储引擎功能

4.4 Blackhole 引擎：丢弃写操作，读操作会返回空内容

• Blackhole引擎没有实现任何存储机制，它会丢弃所有插入的数据，不做任何保存。
• 但服务器会记录Blackhole表的日志，所以可以用于复制数据到备库，或者简单地记录到日志。但这种应用方 式会碰到很多问题，因此并不推荐。

4.5 CSV 引擎：存储数据时，以逗号分隔各个数据项

• CSV引擎可以将普通的CSV文件作为MySQL的表来处理，但不支持索弓|。
• CSV引擎可以作为一种数据交换的机制，非常有用。
• CS侑储的数据直接可以在操隼系统里，用文本编辑器，或者excel读取。
• 对于数据的快速导入、导出是有明显优势的。

创建CSV表时，服务器会创建一个纯文本数据文件，其名称以表名开头并带有.CSV扩展名。当你将数据存储到表 中时，存储引擎将其以逗号分隔值格式保存到数据文件中。

案例如下

mysql> CREATE TABLE test (i INT NOT NULL, c CHAR(10) NOT NULL) ENGINE = CSV;
Query OK, 0 rows affected (0.06 sec)

mysql> INSERT INTO test VALUES(1,'record one'),(2,'record two');
Query OK, 2 rows affected (0.05 sec)
Records: 2 Duplicates: 0  Warnings: 0

mysql> SELECT * FROM test;
+---+------------+
| i | c     |
+---+------------+
| 1 | record one |
| 2 | record two |
+---+------------+
2 rows in set (0.00 sec)
复制代码

创建CSV表还会创建相应的 元文件 ，用于存储表的状态和 表中存在的行数。此文件的名称与表的名称相同，后缀为CSM 。如图所示

如果检查test.CSV通过执行上述语句创建的数据库目录中的文件，其内容使用Notepad++打开如下：

"1","record one"
"2","record two"
复制代码

这种格式可以被Microsoft Excel 等电子表格应用程序读取，甚至写入。使用Microsoft Excel打开如图所示

4.6 Memory 引擎：置于内存的表

概述：

Memory采用的逻辑介质是 内存 ， 响应速度很快 ，但是当mysqld守护进程崩溃的时候 数据会丢失 。另外，要求存储的数据是数据长度不变的格式，比如，Blob和Text类型的数据不可用(长度不固定的)。

主要特征：

• Memory同时 支持哈希（HASH）索引 和 B+树索引 。
  • 哈希索引相等的比较快，但是对于范围的比较慢很多
  • 默认使用哈希（hash）索引，其速度要比使用B型树（BTREE）索引快
  • 如果希望使用B树索引，可以在创建索引时选择使用
• Memory表至少比MyISAM表要 快一个数量级 。
• MEMORY 表的大小是受到限制的。表的大小主要取决于两个参数，分别是max_rows和 max_heap_table_size。其中，max_rows可以在创建表时指定；max_heap_table_size的大小默认为16MB，可以按需要进行扩大。
• 数据文件与索引文件分开存储。
  • 使用memory存储引擎的表实际对应一个磁盘文件，该文件的文件名与表名相同，类型为 frm 类型，该文件只存储表的结构，而其数据文件都是存在内存中
  • 这样有利于数据的快速处理，提供整个表的处理效率
• 缺点：其数据易丢失，生命周期短。基于这个缺陷，选择MEMORY存储引擎时需要特别小心。

使用Memory存储引擎的场景：

1. 目标数据比较小 ，而且非常 频繁的进行访问 ，在内存中存放数据，如果太大的数据会造成 内存溢出 。可以通过参数 max_heap_table_size 控制Memory表的大小，限制Memory表的最大的大小。

2. 如果 数据是临时的 ，而且 必须立即可用 得到，那么就可以放在内存中。

3. 存储在Memory表中的数据如果突然间 丢失的话也没有太大的关系 。

4.7 Federated 引擎：访问远程表

Federated引擎是访问其他MySQL服务器的一个 代理，尽管该引擎看起来提供了一种很好的 跨服务器的灵活性，但也经常带来问题，因此 默认是禁用的 。

4.8 Merge引擎：管理多个MyISAM表构成的表集合

4.9 NDB引擎：MySQL集群专用存储引擎

也叫做 NDB Cluster 存储引擎，主要用于MySQL Cluster 分布式集群环境，类似于 Oracle 的 RAC 集群。

4.10 引擎对比

MySQL中同一个数据库，不同的表可以选择不同的存储引擎。如下表对常用存储引擎做出了对比。

其实我们最常用的就是InnoDB 和 MyISAM，有时会提一下 Memory。

5. MyISAM和InnoDB的区别

很多人对InnoDB和MylSAM的取舍存在疑问，到底选择哪个比较好呢？

MySQL5.5之前的默认存储引擎是MylSAM, 5.5之后改为了InnoDB。

首先对于InnoDB存储引擎，提供了良好的事务管理、崩溃修复能力和并发控制。因为InnoDB存储引擎支持事务， 所以对于要求事务完整性的场合需要选择InnoDB,比如数据操作除了插入和查询以外还包含有很多更新、删除操 作，像财务系统等对数据准确性要求较高的系统。缺点是其读写效率稍差，占用的数据空间相对比较大。

其次对于MyISAM存储引擎如果是小型应用，系统以读操作和插入操作为主，只有很少的更新、删除操作，并且 对事务的要求没有那么高，则可以选择这个存储引擎。MyISAM存储引擎的优势在于占用空间小，处理速度快；缺 点是不支持事务的完整性和并发性。

这两种引擎各有特点，当然你也可以在MySQL中，针对不同的数据表，可以选择不同的存储引擎"

6. 阿里巴巴和淘宝用哪个

• Percona 为MySQL数据库服务器进行了改进，在功能上和性能上较MySQL 有很显著的提升。
• 该版本提升了在高负载情况下的 InnoDB 的性能、为DBA提供一些非常有用的性能诊断工具；另外有更多的参数和命令来控制服务器行为。
• 该公司新建了一款存储引擎 叫 Xtradb 完全可以替代 Innodb ,并且性能和并发上做得更好
• 阿里巴巴大部分mysql数据库其实使用的 percona 的原型加以修改。

7. 重点InnoDB 存储引擎

7.1 InnoDB的优势

InnoDB存储引擎在实际应用中拥有诸多优势，比如操作便利、提高了数据库的性能、维护成本低等。如 果由于硬件或软件的原因导致服务器崩溃，那么在重启服务器之后不需要进行额外的操作。InnoDB崩溃 恢复功能自动将之前提交的内容定型，然后撤销没有提交的进程，重启之后继续从崩溃点开始执行。

InnoDB存储引擎在主内存中维护缓冲池，高频率使用的数据将在内存中直接被处理。这种缓存方式应用 于多种信息，加速了处理进程

在专用服务器上，物理内存中高达80%的部分被应用于缓冲池。如果需要将数据插入不同的表中，可以 设置外键加强数据的完整性。更新或者删除数据，关联数据将会被自动更新或删除。如果试图将数据插 入从表，但在主表中没有对应的数据，插入的数据将被自动移除。如果磁盘或内存中的数据出现崩溃， 在使用脏数据之前，校验和机制会发出警告。当每个表的主键都设置合理时，与这些列有关的操作会被 自动优化。插入、更新和删除操作通过做改变缓冲自动机制进行优化。 InnoDB不仅支持当前读写，也会 缓冲改变的数据到数据流磁盘 。

InnoDB的性能优势不只存在于长时运行查询的大型表。在同一列多次被查询时，自适应哈希索引会提高 查询的速度。使用InnoDB可以压缩表和相关的索引，可以 在不影响性能和可用性的情况下创建或删除索 引 。对于大型文本和BLOB数据，使用动态行形式，这种存储布局更高效。通过查询

INFORMATION_SCHEMA库中的表可以监控存储引擎的内部工作。在同一个语句中，InnoDB表可以与其他 存储引擎表混用。即使有些操作系统限制文件大小为2GB，InnoDB仍然可以处理。 当处理大数据量时， InnoDB兼顾CPU，以达到最大性能 。

7.2 InnoDB 和ACID模型

ACID模型是一系列数据库设计规则，这些规则着重强调可靠性，而可靠性对于商业数据和任务关键型应 用非常重要。MySQL包含类似InnoDB存储引擎的组件，与ACID模型紧密相连，这样出现意外时，数据不 会崩溃，结果不会失真。如果依赖ACID模型，可以不使用一致性检查和崩溃恢复机制。如果拥有额外的 软件保护，极可靠的硬件或者应用可以容忍一小部分的数据丢失和不一致，可以将MySQL设置调整为只 依赖部分ACID特性，以达到更高的性能。下面讲解InnoDB存储引擎与ACID模型相同作用的四个方面

7.2.1 原子方面

ACID的原子方面主要涉及InnoDB事务，与MySQL相关的特性主要包括：

• 自动提交设置。
• COMMIT语句。
• ROLLBACK语句。
• 操作INFORMATION_SCHEMA库中的表数据。

7.2.2 一致性方面

ACID模型的一致性主要涉及保护数据不崩溃的内部InnoDB处理过程，与MySQL相关的特性 主要包括：

• InnoDB双写缓存。
• InnoDB崩溃恢复。

7.2.3 隔离方面

隔离是应用于事务的级别，与MySQL相关的特性主要包括： 自动提交设置。

• SET ISOLATION LEVEL语句。
• InnoDB锁的低级别信息。

7.2.4 耐久性方面

ACID模型的耐久性主要涉及与硬件配置相互影响的MySQL软件特性。由于硬件复杂多样 化，耐久性方面没有具体的规则可循。与MySQL相关的特性有：

• InnoDB双写缓存，通过innodb_doublewrite配置项配置。
• 配置项innodb_flush_log_at_trx_commit。
• 配置项sync_binlog。
• 配置项innodb_file_per_table。
• 存储设备的写入缓存。
• 存储设备的备用电池缓存。
• 运行MySQL的操作系统。
• 持续的电力供应。
• 备份策略。
• 对分布式或托管的应用，最主要的在于硬件设备的地点以及网络情况

7.3 InnoDB体系架构

下图简单描述了InnoDB存储引擎的体系结构：

InnoDB存储引擎有多个内存块，这些内存块组成了一个大的内存池。后台线程主要负责刷新内存池中的数据、将已修改的数据刷新到磁盘等等。接下来我们分别介绍后台线程和内存池。

7.3.1 后台线程

InnoDB后台有多个不同的线程，用来负责不同的任务。主要有如下：

• Master Thread : 这是最核心的一个线程,主要负责将缓冲池中的数据异步刷新到磁盘,保证数据的一致性,包括赃页的刷新、合并插入缓冲、UNDO 页的回收等.

• IO Thread : 在 InnoDB 存储引擎中大量使用了异步 IO 来处理写 IO 请求, IO Thread 的工作主要是负责这些 IO 请求的回调处理。

• Purge Thread: 事务被提交之后, undo log 可能不再需要,因此需要 Purge Thread 来回收已经使用并分配的 undo页。 InnoDB 支持多个 Purge Thread, 这样做可以加快 undo 页的回收。

• Page Cleaner Thread : Page Cleaner Thread 是在InnoDB 1.2.x版本新引入的,其作用是将之前版本中脏页的刷新操作都放入单独的线程中来完成,这样减轻了 Master Thread 的工作及对于用户查询线程的阻塞。

7.3.2 内存

InnoDB 存储引擎是基于磁盘存储的,也就是说数据都是存储在磁盘上的,由于 CPU 速度和磁盘速度之间的鸿沟, InnoDB 引擎使用缓冲池技术来提高数据库的整体性能。缓冲池简单来说就是一块内存区域.在数据库中进行读取页的操作,首先将从磁盘读到的页存放在缓冲池中,下一次读取相同的页时,首先判断该页是不是在缓冲池中,若在,称该页在缓冲池中被命中,直接读取该页。否则,读取磁盘上的页。对于数据库中页的修改操作,首先修改在缓冲池中页,然后再以一定的频率刷新到磁盘,并不是每次页发生改变就刷新回磁盘。

1. 缓冲池 Buffer Pool

缓冲池中缓存的数据页类型有:索引页、数据页、 undo 页、插入缓冲、自适应哈希索引、 InnoDB 的锁信息、数据字典信息等。索引页和数据页占缓冲池的很大一部分（先知道有这些页，后面章节详细介绍）。在InnoDB中，缓冲池中的页大小默认为16KB。

我们已经知道这个Buffer Pool其实是一片连续的内存空间，那现在就面临这个问题了：怎么将磁盘上的页缓存到内存中的Buffer Pool中呢？直接把需要缓存的页向Buffer Pool里一个一个往里怼么？不不不，为了更好的管理这些被缓存的页，InnoDB为每一个缓存页都创建了一些所谓的控制信息，这些控制信息包括该页所属的表空间编号、页号、页在Buffer Pool中的地址，一些锁信息以及LSN信息（锁和LSN这里可以先忽略），当然还有一些别的控制信息。

每个缓存页对应的控制信息占用的内存大小是相同的，我们就把每个页对应的控制信息占用的一块内存称为一个控制块吧，控制块和缓存页是一一对应的，它们都被存放到 Buffer Pool 中，其中控制块被存放到 Buffer Pool 的前边，缓存页被存放到 Buffer Pool 后边，所以整个Buffer Pool对应的内存空间看起来就是这样的：

控制块和缓存页之间的那个碎片是个什么呢？你想想啊，每一个控制块都对应一个缓存页，那在分配足够多的控制块和缓存页后，可能剩余的那点儿空间不够一对控制块和缓存页的大小，自然就用不到喽，这个用不到的那点儿内存空间就被称为碎片了。当然，如果你把Buffer Pool的大小设置的刚刚好的话，也可能不会产生碎片～

2. 重做日志缓冲

Innodb内存区域除了缓冲池外，还有重做日志缓冲。innodb存储引擎会先将重做日志信息写入缓冲区，然后按照一定频率刷新到重做日志文件。一般情况下master thread每秒钟会将缓存刷新到日志文件。因此用户只需要保证 每秒产生的事务量在这个缓冲大小之内即可。其可由参数innodb_log_buffer_size进行控制。默认是8M的重做日志缓冲能够满足大多数应用。因为在以下条件会刷新到重做日志文件

• master thread每一秒将重做日志缓冲刷新到重做日志文件
• 每个事务提交时会将重做日志缓冲刷新到重做日志文件
• 当重做日志缓冲池剩余空间小于1/2时，重做日志缓冲会刷新到重做日志文件

3. Free List

前面我们知道了缓冲池的结构。接下来说InnoDB存储引擎是怎么对缓冲池进行管理的?讲下我当时的困惑吧，（这部分可以不看，因为有些名词还没涉及到）看《Mysql技术内幕》这本书，讲LRU List比较多，Free List只是顺带一过，没有将free list初始时是怎么分配的或者是什么样的结构，导致我对缓冲池的管理总是想象不出来，后来经过在网上寻找资料，算是弄明白了。来看一下吧：

当我们最初启动MySQL服务器的时候，需要完成对Buffer Pool的初始化过程，就是分配Buffer Pool的内存空间，把它划分成若干对控制块和缓存页。但是此时并没有真实的磁盘页被缓存到Buffer Pool中（因为还没有用到），之后随着程序的运行，会不断的有磁盘上的页被缓存到Buffer Pool中，那么问题来了，从磁盘上读取一个页到Buffer Pool中的时候该放到哪个缓存页的位置呢？或者说怎么区分Buffer Pool中哪些缓存页是空闲的，哪些已经被使用了呢？我们最好在某个地方记录一下哪些页是可用的，我们可以把所有空闲的页包装成一个节点组成一个链表，这个链表也可以被称作Free链表（或者说空闲链表）。因为刚刚完成初始化的Buffer Pool中所有的缓存页都是空闲的，所以每一个缓存页都会被加入到Free链表中，假设该Buffer Pool中可容纳的缓存页数量为n，那增加了Free链表的效果图就是这样的：

从图中可以看出，我们为了管理好这个Free链表，特意为这个链表定义了一个控制信息，里边儿包含着链表的头节点地址，尾节点地址，以及当前链表中节点的数量等信息。我们在每个Free链表的节点中都记录了某个缓存页控制块的地址，而每个缓存页控制块都记录着对应的缓存页地址，所以相当于每个Free链表节点都对应一个空闲的缓存页。

有了这个Free链表事儿就好办了，每当需要从磁盘中加载一个页到Buffer Pool中时，就从Free链表中取一个空闲的缓存页，并且把该缓存页对应的控制块的信息填上，然后把该缓存页对应的Free链表节点从链表中移除，表示该缓存页已经被使用了～

简单回顾一下，为什么讲free list？是为了讲怎么管理buffer pool对吧。那free list就相当于是数据库服务刚刚启动没有数据页时，维护buffer pool的空闲缓存页的数据结构。

4. LRU list

下面再来简单地回顾Buffer Pool的工作机制。Buffer Pool两个最主要的功能：一个是加速读，一个是加速写。加速读呢？ 就是当需要访问一个数据页面的时候，如果这个页面已经在缓存池中，那么就不再需要访问磁盘，直接从缓冲池中就能获取这个页面的内容。加速写呢？就是当需要修改一个页面的时候，先将这个页面在缓冲池中进行修改，记下相关的重做日志，这个页面的修改就算已经完成了。至于这个被修改的页面什么时候真正刷新到磁盘，这个是后台刷新线程来完成的。

在实现上面两个功能的同时，需要考虑客观条件的限制，因为机器的内存大小是有限的，所以MySQL的InnoDB Buffer Pool的大小同样是有限的，如果需要缓存的页占用的内存大小超过了Buffer Pool大小，也就是Free链表中已经没有多余的空闲缓存页的时候岂不是很尴尬，发生了这样的事儿该咋办？当然是把某些旧的缓存页从Buffer Pool中移除，然后再把新的页放进来喽～ 那么问题来了，移除哪些缓存页呢？

为了回答这个问题，我们还需要回到我们设立Buffer Pool的初衷，我们就是想减少和磁盘的I/O交互，最好每次在访问某个页的时候它都已经被缓存到Buffer Pool中了。假设我们一共访问了n次页，那么被访问的页已经在缓存中的次数除以n就是所谓的缓存命中率，我们的期望就是让缓存命中率越高越好～

怎么提高缓存命中率呢？InnoDB Buffer Pool采用经典的LRU算法来进行页面淘汰，以提高缓存命中率。当Buffer Pool中不再有空闲的缓存页时，就需要淘汰掉部分最近很少使用的缓存页。不过，我们怎么知道哪些缓存页最近频繁使用，哪些最近很少使用呢？呵呵，神奇的链表再一次派上了用场，我们可以再创建一个链表，由于这个链表是为了按照最近最少使用的原则去淘汰缓存页的，所以这个链表可以被称为LRU链表（Least Recently Used）。当我们需要访问某个页时，可以这样处理LRU链表：

• 如果该页不在Buffer Pool中，在把该页从磁盘加载到Buffer Pool中的缓存页时，就把该缓存页包装成节点塞到链表的头部。
• 如果该页在Buffer Pool中，则直接把该页对应的LRU链表节点移动到链表的头部。

但是这样做会有一些性能上的问题，比如你的一次全表扫描或一次逻辑备份就把热数据给冲完了，就会导致导致缓冲池污染问题！Buffer Pool中的所有数据页都被换了一次血，其他查询语句在执行时又得执行一次从磁盘加载到Buffer Pool的操作，而这种全表扫描的语句执行的频率也不高，每次执行都要把Buffer Pool中的缓存页换一次血，这严重的影响到其他查询对 Buffer Pool 的使用，严重的降低了缓存命中率 ！

所以InnoDB存储引擎对传统的LRU算法做了一些优化，在InnoDB中加入了midpoint。新读到的页，虽然是最新访问的页，但并不是直接插入到LRU列表的首部，而是插入LRU列表的midpoint位置。这个算法称之为midpoint insertion stategy。默认配置插入到列表长度的5/8处。midpoint由参数innodb_old_blocks_pct控制。

midpoint之前的列表称之为new列表，之后的列表称之为old列表。可以简单的将new列表中的页理解为最为活跃的热点数据。

同时InnoDB存储引擎还引入了innodb_old_blocks_time来表示页读取到mid位置之后需要等待多久才会被加入到LRU列表的热端。可以通过设置该参数保证热点数据不轻易被刷出。

5. Flush list

好了，基本拿下了LRU list后，我们继续。前面我们讲到页面更新是在缓存池中先进行的，那它就和磁盘上的页不一致了，这样的缓存页也被称为脏页（英文名：dirty page）。所以需要考虑这些被修改的页面什么时候刷新到磁盘？以什么样的顺序刷新到磁盘？当然，最简单的做法就是每发生一次修改就立即同步到磁盘上对应的页上，但是频繁的往磁盘中写数据会严重的影响程序的性能（毕竟磁盘慢的像乌龟一样）。所以每次修改缓存页后，我们并不着急立即把修改同步到磁盘上，而是在未来的某个时间点进行同步，由后台刷新线程依次刷新到磁盘，实现修改落地到磁盘。

但是如果不立即同步到磁盘的话，那之后再同步的时候我们怎么知道Buffer Pool中哪些页是脏页，哪些页从来没被修改过呢？总不能把所有的缓存页都同步到磁盘上吧，假如Buffer Pool被设置的很大，比方说300G，那一次性同步这么多数据岂不是要慢死！

所以，我们不得不再创建一个存储脏页的链表，凡是在LRU链表中被修改过的页都需要加入这个链表中，因为这个链表中的页都是需要被刷新到磁盘上的，所以也叫FLUSH链表，有时候也会被简写为FLU链表。链表的构造和Free链表差不多，这就不赘述了。这里的脏页修改指的此页被加载进Buffer Pool后第一次被修改，只有第一次被修改时才需要加入FLUSH链表（代码中是根据Page头部的oldest_modification == 0来判断是否是第一次修改），如果这个页被再次修改就不会再放到FLUSH链表了，因为已经存在。需要注意的是，脏页数据实际还在LRU链表中，而FLUSH链表中的脏页记录只是通过指针指向LRU链表中的脏页。并且在FLUSH链表中的脏页是根据oldest_lsn（这个值表示这个页第一次被更改时的lsn号，对应值oldest_modification，每个页头部记录）进行排序刷新到磁盘的，值越小表示要最先被刷新，避免数据不一致。

注意：脏页既存在于LRU列表中，也存在与Flush列表中。LRU列表用来管理缓冲池中页的可用性，Flush列表用来管理将页刷新回磁盘，二者互不影响。

6. Free List、LRU list和Flush list 总结

这三个重要列表（LRU list， free list，flush list）的关系可以用下图表示：

Free链表跟LRU链表的关系是相互流通的，页在这两个链表间来回置换。而FLUSH链表记录了脏页数据，也是通过指针指向了LRU链表，所以图中FLUSH链表被LRU链表包裹。

7.4 CheckPoint技术

说完缓冲池，下面说CheckPoint技术。 CheckPoint技术是用来解决如下几个问题：

• 缩短数据库恢复时间
• 缓冲池不够用时，将脏页刷新到磁盘
• 重做日志不可用时，刷新脏页

缩短数据库恢复时间，重做日志中记录了的checkpoint的位置，这个点之前的页已经刷新回磁盘，只需要对checkpoint之后的重做日志进行恢复。这样就大大缩短了恢复时间。

缓冲池不够用时，根据LRU算法，溢出最近最少使用的页，如果页为脏页，强制执行checkpoint，将脏页刷新回磁盘。

重做日志不可用，是指重做日志的这部分不可以被覆盖，为什么？因为：由于重做日志的设计是循环使用的。这部分对应的数据还未刷新到磁盘上。数据库恢复时，如果不需要这部分日志，即可被覆盖；如果需要，必须强制执行checkpoint，将缓冲池中的页至少刷新到当前重做日志的位置。

问题：checkpoint每次刷新多少页到磁盘？每次从哪里取脏页？什么时间触发checkpoint？

InnoDB存储引擎内部，两种checkpoint，分别为:

• Sharp Checkpoint
• Fuzzy Checkpoint

Sharp Checkpoint发生在数据库关闭时，将所有的脏页都刷新回磁盘，这是默认的工作方式，即参数：innodb_fast_shutdown=1。不适用于数据库运行时的刷新。

在数据库运行时，InnoDB存储引擎内部采用Fuzzy Checkpoint，只刷新一部分脏页。几种发生Fuzzy Checkpoint的情况如下：

• MasterThread Checkpoint

  • 异步刷新，每秒或每10秒从缓冲池脏页列表刷新一定比例的页回磁盘。异步刷新，即此时InnoDB存储引擎可以进行其他操作，用户查询线程不会受阻。

• FLUSH_LRU_LIST Checkpoint

  • InnoDB存储引擎需要保证LRU列表中差不多有100个空闲页可供使用。在InnoDB 1.1.x版本之前，用户查询线程会检查LRU列表是否有足够的空间操作。如果没有，根据LRU算法，溢出LRU列表尾端的页，如果这些页有脏页，需要进行checkpoint。因此叫：flush_lru_list checkpoint。
  • InnoDB 1.2.x开始，这个检查放在了单独的进程（Page Cleaner）中进行。好处：1.减少master Thread的压力 2.减轻用户线程阻塞。
  • 设置参数：innodb_lru_scan_dept：控制LRU列表中可用页的数量，该值默认1024

• Async/Sync Flush Checkpoint

  • 指重做日志不可用的情况，需要强制刷新页回磁盘，此时的页时脏页列表选取的。

  • 这种情况是保证重做日志的可用性，说白了就是，重做日志中可以循环覆盖的部分空间太少了，换种说法，就是极短时间内产生了大量的redo log。

  • 接下来会有几个变量，图解也不难，仔细看看。

    • InnoDB存储引擎，通过LSN（Log Sequence Number）来标记版本，LSN是8字节的数字。每个页有LSN，重做日志有LSN，checkpoint有LSN。
    • 写入日志的LSN:redo_lsn
    • 刷新回磁盘的最新页LSN:checkpoint_lsn
    • 有如下定义:
    • checkpoint_age = redo_lsn - checkpoint_lsn
    • async_water_mark = 75% * total_redo_file_size
    • sync_water_mark = 90% * total_redo_file_size
    • 刷新过程如下图所示：

    

• Dirty Page too much Checkpoint

  • 即脏页太多，强制checkpoint.保证缓冲池有足够可用的页。
  • 参数设置：innodb_max_dirty_pages_pct = 75 表示：当缓冲池中脏页的数量占75%时，强制checkpoint。1.0.x之后默认75

7.5 InnoDB关键特性

7.5.1插入缓冲

Insert Buffer是InnoDB存储引擎关键特性中最令人激动与兴奋的一个功能。不过这个名字可能会让人认为插入缓冲是缓冲池中的一个组成部分。其实不然，InnoDB缓冲池中有Insert Buffer信息固然不错，但是Insert Buffer和数据页一样，也是物理页的一个组成部分。

一般情况下，主键是行唯一的标识符。通常应用程序中行记录的插入顺序是按照主键递增的顺序进行插入的。因此，插入聚集索引一般是顺序的，不需要磁盘的随机读取。因为，对于此类情况下的插入，速度还是非常快的。（如果主键类是UUID这样的类，那么插入和辅助索引一样，也是随机的。）

如果索引是非聚集的且不唯一。在进行插入操作时，数据的存放对于非聚集索引叶子节点的插入不是顺序的，这时需要离散地访问非聚集索引页，由于随机读取的存在而导致了插入操作性能下降。这是因为B+树的特性决定了非聚集索引插入的离散性。

Insert Buffer的设计，对于非聚集索引的插入和更新操作，不是每一次直接插入到索引页中，而是先判断插入非聚集索引页是否在缓冲池中，若存在，则直接插入，不存在，则先放入一个Insert Buffer对象中。数据库这个非聚集的索引已经插到叶子节点，而实际并没有，只是存放在另一个位置。然后再以一定的频率和情况进行Insert Buffer和辅助索引页子节点的merge（合并）操作，这时通常能将多个插入合并到一个操作中（因为在一个索引页中），这就大大提高了对于非聚集索引插入的性能。

需要满足的两个条件：

• 索引是辅助索引；
• 索引不是唯一的。

辅助索引不能是唯一的，因为在插入缓冲时，数据库并不去查找索引页来判断插入的记录的唯一性。如果去查找肯定又会有离散读取的情况发生，从而导致Insert Buffer失去了意义。

7.5.2 两次写

如果说插入缓冲是为了提高写性能的话，那么两次写是为了提高可靠性。

介绍两次写之前，说一下部分写失效： 想象这么一个场景，当数据库正在从内存向磁盘写一个数据页时，数据库宕机，从而导致这个页只写了部分数据，这就是部分写失效，它会导致数据丢失。这时是无法通过重做日志恢复的，因为重做日志记录的是对页的物理修改，如果页本身已经损坏，重做日志也无能为力。

从上面分析我们知道，在部分写失效的情况下，我们在应用重做日志之前，需要原始页的一个副本，两次写就是为了解决这个问题，下面是它的原理图：

两次写需要额外添加两个部分：

• 内存中的两次写缓冲（doublewrite buffer），大小为2MB
• 磁盘上共享表空间中连续的128页，大小也为2MB

其原理是这样的：

• 当刷新缓冲池脏页时，并不直接写到数据文件中，而是先拷贝至内存中的两次写缓冲区。
• 接着从两次写缓冲区分两次写入磁盘共享表空间中，每次写入1MB
• 待第2步完成后，再将两次写缓冲区写入数据文件

这样就可以解决上文提到的部分写失效的问题，因为在磁盘共享表空间中已有数据页副本拷贝，如果数据库在页写入数据文件的过程中宕机，在实例恢复时，可以从共享表空间中找到该页副本，将其拷贝覆盖原有的数据页，再应用重做日志即可。

其中第2步是额外的性能开销，但由于磁盘共享表空间是连续的，因此开销不是很大。可以通过参数skip_innodb_doublewrite禁用两次写功能，默认是开启的，强烈建议开启该功能。

7.5.3 自适应哈希索引

哈希是一种非常快的查找方法，在一般情况时间复杂度为O(1)。而B+树的查找次数，取决于B+树的高度，在生成环境中，B+树的高度一般为3-4层，不需要查询3-4次。

InnoDB存储引擎会监控对表上各索引页的查询。如果观察到建立哈希索引可以提升速度，就建立哈希索引，称之为自适应哈希索引(Adaptive Hash Index, AHI)。AHI是通过缓冲池的B+树页构造而来的。因此建立的速度非常快，且不要对整张表构建哈希索引。InnoDB存储引擎会自动根据访问的频率和模式来自动的为某些热点页建立哈希索引。

AHI有一个要求，对这个页的连续访问模式(查询条件)必须一样的。例如联合索引(a,b)其访问模式可以有以下情况:

• WHERE a=XXX;
• WHERE a=xxx AND b=xxx。 若交替进行上述两张查询，InnoDB存储引擎不会对该页构造AHI。此外AHI还有如下要求：
• 以该模式访问了100次；
• 页通过该模式访问了N次，其中N=页中记录/16。 根据官方文档显示，启用AHI后，读取和写入的速度可以提高2倍，负责索引的链接操作性能可以提高5倍。其设计思想是数据库自由化的，无需DBA对数据库进行人为调整。

7.5.4 异步IO(AIO)

为了提高磁盘操作性能，当前的数据库系统都采用异步IO的方式来处理磁盘操作。InnoDB也是如此。

与AIO对应的是Sync IO，即每进行一次IO操作，需要等待此次操作结束才能继续接下来的操作。但是如果用户发出的是一条索引扫描的查询，那么这条SQL语句可能需要扫描多个索引页，也就是需要进行多次IO操作。在每扫描一个页并等待其完成再进行下一次扫描，这是没有必要的。用户可以在发出一个IO请求后立即再发出另外一个IO请求，当全部IO请求发送完毕后，等待所有IO操作完成，这就是AIO。

AIO的另外一个优势是进行IO Merge操作，也就是将多个IO合并为一个IO操作，这样可以提高IOPS的性能。

在InnoDB 1.1.x之前，AIO的实现是通过InnoDB存储引擎中的代码来模拟的。但是从这之后，提供了内核级别的AIO的支持，称为Native AIO。Native AIO需要操作系统提供支持。Windows和Linux都支持，而Mac则未提供。在选择MySQL数据库服务器的操作系统时，需要考虑这方面的因素。

MySQL可以通过参数innodb_use_native_aio来决定是否启用Native AIO。在InnoDB存储引擎中，read ahead方式的读取都是通过AIO完成，脏页的刷新，也是通过AIO完成。

7.5.5 刷新邻接页

InnoDB存储引擎在刷新一个脏页时，会检测该页所在区(extent)的所有页，如果是脏页，那么一起刷新。这样做的好处是通过AIO可以将多个IO写操作合并为一个IO操作。该工作机制在传统机械磁盘下有显著优势。但是需要考虑下面两个问题:

• 是不是将不怎么脏的页进行写入，而该页之后又会很快变成脏页？
• 固态硬盘有很高IOPS，是否还需要这个特性？

为此InnoDB存储引擎1.2.x版本开始提供参数·innodb_flush_neighbors·来决定是否启用。对于传统机械硬盘建议使用，而对于固态硬盘可以关闭。

7.6 InnoDB 架构

1. 缓冲池 缓冲池是主内存中的一部分空间，用来缓存已使用的表和索引数据。缓冲池使得经常被使用的

数据能够直接在内存中获得，从而提高速度。

2. 更改缓存 更改缓存是一个特殊的数据结构，当受影响的索引页不在缓存中时，更改缓存会缓存辅助索

引页的更改。索引页被其他读取操作时会加载到缓存池，缓存的更改内容就会被合并。不同于集群索 引，辅助索引并非独一无二的。当系统大部分闲置时，清除操作会定期运行，将更新的索引页刷入磁 盘。更新缓存合并期间，可能会大大降低查询的性能。在内存中，更新缓存占用一部分InnoDB缓冲池。 在磁盘中，更新缓存是系统表空间的一部分。更新缓存的数据类型由innodb_change_buffering配置项管 理。

3. 自适应哈希索引 自适应哈希索引将负载和足够的内存结合起来，使得InnoDB像内存数据库一样运行，

不需要降低事务上的性能或可靠性。这个特性通过innodb_adaptive_hash_index选项配置，或者通过-- skip-innodb_adaptive_hash_index命令行在服务启动时关闭。

4. 重做日志缓存 重做日志缓存存放要放入重做日志的数据。重做日志缓存大小通过

innodb_log_buffer_size配置项配置。重做日志缓存会定期地将日志文件刷入磁盘。大型的重做日志缓存 使得大型事务能够正常运行而不需要写入磁盘。

5.** 系统表空间** 系统表空间包括InnoDB数据字典、双写缓存、更新缓存和撤销日志，同时也包括表和索引 数据。多表共享，系统表空间被视为共享表空间。

6. 双写缓存 双写缓存位于系统表空间中，用于写入从缓存池刷新的数据页。只有在刷新并写入双写缓存

后，InnoDB才会将数据页写入合适的位置。

7. 撤销日志 撤销日志是一系列与事务相关的撤销记录的集合，包含如何撤销事务最近的更改。如果其他

事务要查询原始数据，可以从撤销日志记录中追溯未更改的数据。撤销日志存在于撤销日志片段中，这 些片段包含于回滚片段中。

8. 每个表一个文件的表空间 每个表一个文件的表空间是指每个单独的表空间创建在自身的数据文件中，

而不是系统表空间中。这个功能通过innodb_file_per_table配置项开启。每个表空间由一个单独的.ibd数 据文件代表，该文件默认被创建在数据库目录中。

9. 通用表空间 使用CREATE TABLESPACE语法创建共享的InnoDB表空间。通用表空间可以创建在MySQL数

据目录之外能够管理多个表并支持所有行格式的表。

10. 撤销表空间 撤销表空间由一个或多个包含撤销日志的文件组成。撤销表空间的数量由

innodb_undo_tablespaces配置项配置。

11. 临时表空间 用户创建的临时表空间和基于磁盘的内部临时表都创建于临时表空间。

innodb_temp_data_file_path配置项定义了相关的路径、名称、大小和属性。如果该值为空，默认会在 innodb_data_home_dir变量指定的目录下创建一个自动扩展的数据文件。

12. 重做日志 重做日志是基于磁盘的数据结构，在崩溃恢复期间使用，用来纠正数据。正常操作期间，

重做日志会将请求数据进行编码，这些请求会改变InnoDB表数据。遇到意外崩溃后，未完成的更改会自 动在初始化期间重新进行

参考文章

MySQL从入门到精通
MySQL是怎样运行的 从根儿上理解MySQL
《MySQL技术内幕：InnoDB存储引擎（第2版）》 第1章和第2章
一文了解InnoDB存储引擎
《数据库索引设计与优化》
MySQL InnoDB特性：两次写（DoubleWrite）
InnoDB特性之-两次写