Mysql高级部分系列（一）

1、Mysql逻辑架构剖析

1.1、服务器处理客户端请求

服务器进程对客户端进程发送的请求做了什么处理，才能产生最后的处理结果呢？这里以查询请求为
例展示：

更具体一些则是

当一个客户端请求向mysql服务器发起请求的时候，会先与服务器建立 TCP 连接，经过三次握手建立连接成功后， MySQL 服务器对 TCP 传输过来的账号密码做身份认证、权限获取，TCP 连接收到请求后，从连接池中分配给一个线程专门与这个客户端的交互。接着会进入sql接口部分，接收用户的SQL命令，并且返回用户需要查询的结果，在查询结果的时候，会先出去缓存中查询，如果缓存中没有，则会进入到解析器，在解析器中对 SQL 语句进行词法分析、语法分析，生成语法树，然后在进入到优化器，对查询的sql进行优化，生成一个执行计划，交给执行器去执行，最后来到存储引擎，在执行器调用存储引擎中的api，对数据进行存储和提取，并且将结果进行缓存。

1.2、第1层：连接层

系统（客户端）访问MySQL服务器前，做的第一件事就是建立TCP连接。

经过三次握手建立连接成功后，MySQL服务器对TCP传输过来的账号密码做身份认证、权限获取。

• 用户名或密码不对，会收到一个Access denied for user错误，客户端程序结束执行
• 用户名密码认证通过，会从权限表查出账号拥有的权限与连接关联，之后的权限判断逻辑，都将依赖于此时读到的权限

TCP连接收到请求后，必须要分配给一个线程专门与这个客户端的交互。所以还会有个线程池，去走后面的流程。每一个连接从线程池中获取线程，省去了创建和销毁线程的开销。

1.2、第2层：服务层

1.2.1、SQL Interface: SQL接口

• 接收用户的SQL命令，并且返回用户需要查询的结果。比如SELECT … FROM就是调用SQL Interface
• MySQL支持DML（数据操作语言）、DDL（数据定义语言）、存储过程、视图、触发器、自定义函数等多种SQL语言接口

1.2.2、Parser:解析器

• 在解析器中对 SQL 语句进行语法分析、语义分析。将SQL语句分解成数据结构，并将这个结构传递到后续步骤，以后SQL语句的传递和处理就是基于这个结构的。如果在分解构成中遇到错误，那么就说明这个SQL语句是不合理的。
• 在SQL命令传递到解析器的时候会被解析器验证和解析，并为其创建语法树，并根据数据字典丰富查询语法树，会验证该客户端是否具有执行该查询的权限。创建好语法树后，MySQL还会对SQL查询进行语法上的优化，进行查询重写。

1.2.3、Optimizer:查询优化器

• SQL语句在语法解析之后、查询之前会使用查询优化器确定 SQL 语句的执行路径，生成一个执行计划。
• 这个执行计划表明应该使用哪些索引进行查询（全表检索还是使用索引检索），表之间的连接顺序如何，最后会按照执行计划中的步骤调用存储引擎提供的方法来真正的执行查询，并将查询结果返回给用户。
• 它使用“选取-投影-连接”策略进行查询。例如：

SELECT id,name FROM student WHERE gender = '女';

这个SELECT查询先根据WHERE语句进行选取，而不是将表全部查询出来以后再进行gender过滤。 这个SELECT查询先根据id和name进行属性投影，而不是将属性全部取出以后再进行过滤，将这两个查询条件连接起来生成最终查询结果。

1.2.4、Caches & Buffers： 查询缓存组件

• MySQL内部维持着一些Cache和Buffer，比如Query Cache用来缓存一条SELECT语句的执行结果，如果能够在其中找到对应的查询结果，那么就不必再进行查询解析、优化和执行的整个过程了，直接将结果反馈给客户端。
• 这个缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，key缓存，权限缓存等 。
• 这个查询缓存可以在不同客户端之间共享。
• 从MySQL 5.7.20开始，不推荐使用查询缓存，并在MySQL 8.0中删除。

1.3、第3层：引擎层

插件式存储引擎层（ Storage Engines），真正的负责了MySQL中数据的存储和提取，对物理服务器级别维护的底层数据执行操作，服务层通过API与存储引擎进行通信。不同的存储引擎具有的功能不同，这样我们可以根据自己的实际需要进行选取。

MySQL 8.0.25默认支持的存储引擎如下：

1.4、存储层

所有的数据，数据库、表的定义，表的每一行的内容，索引，都是存在 文件系统 上，以 文件 的方式存在的，并完成与存储引擎的交互。当然有些存储引擎比如InnoDB，也支持不使用文件系统直接管理裸设备，但现代文件系统的实现使得这样做没有必要了。在文件系统之下，可以使用本地磁盘，可以使用DAS、NAS、SAN等各种存储系统。

1.5、小结

简化为三层结构：

1. 连接层：客户端和服务器端建立连接，客户端发送 SQL 至服务器端；
2. SQL 层（服务层）：对 SQL 语句进行查询处理；与数据库文件的存储方式无关；
3. 存储引擎层：与数据库文件打交道，负责数据的存储和读取。

2、SQL执行流程

2.1、MySQL 中的 SQL执行流程

MySQL的查询流程：

2.1.1、查询缓存

查询缓存：Server 如果在查询缓存中发现了这条 SQL 语句，就会直接将结果返回给客户端；如果没有，就进入到解析器阶段。需要说明的是，因为查询缓存往往效率不高，所以在 MySQL8.0 之后就抛弃了这个功能。

查询缓存是提前把查询结果缓存起来，这样下次不需要执行就可以直接拿到结果。需要说明的是，在MySQL 中的查询缓存，不是缓存查询计划，而是查询对应的结果。这就意味着查询匹配的鲁棒性大大降低，只有相同的查询操作才会命中查询缓存。两个查询请求在任何字符上的不同（例如：空格、注释、大小写），都会导致缓存不会命中。因此 MySQL 的 查询缓存命中率不高 。

同时，如果查询请求中包含某些系统函数、用户自定义变量和函数、一些系统表，如 mysql、 information_schema、 performance_schema 数据库中的表，那这个请求就不会被缓存。

此外，既然是缓存，那就有它缓存失效的时候。MySQL的缓存系统会监测涉及到的每张表，只要该表的结构或者数据被修改，如对该表使用了INSERT、UPDATE、DELETE、TRUNCATE TABLE、ALTER TABLE、DROP TABLE或DROP DATABASE语句，那使用该表的所有高速缓存查询都将变为无效并从高速缓存中删除！对于更新压力大的数据库来说，查询缓存的命中率会非常低。

2.1.2、解析器

解析器：在解析器中对 SQL 语句进行语法分析、语义分析。

分析器先做“ 词法分析 ”。你输入的是由多个字符串和空格组成的一条 SQL 语句，MySQL 需要识别出里面的字符串分别是什么，代表什么。 MySQL 从你输入的"select"这个关键字识别出来，这是一个查询语句。它也要把字符串“T”识别成“表名 T”，把字符串“ID”识别成“列 ID”。
接着，要做“ 语法分析 ”。根据词法分析的结果，语法分析器（比如：Bison）会根据语法规则，判断你输入的这个 SQL 语句是否 满足 MySQL 语法 。

select department_id,job_id,avg(salary) from employees group by department_id;

如果SQL语句正确，则会生成一个这样的语法树：

2.1.3、优化器

优化器：在优化器中会确定 SQL 语句的执行路径，比如是根据全表检索，还是根据索引检索等。
举例：如下语句是执行两个表的 join：

 select * from test1 join test2 using(ID) where test1.name='zhangwei' and test2.name='mysql高级课程'; 

• 方案1：可以先从表 test1 里面取出 name='zhangwei’的记录的 ID 值，再根据 ID 值关联到表 test2，再判 断 test2 里面 name的值是否等于 ‘mysql高级课程’。
• 方案2：可以先从表 test2 里面取出 name=‘mysql高级课程’ 的记录的 ID 值，再根据 ID 值关联到 test1， 再判断 test1 里面 name的值是否等于 zhangwei。 这两种执行方法的逻辑结果是一样的，但是执行的效率会有不同，而优化器的作用就是决定选择使用哪一个方案。优化 器阶段完成后，这个语句的执行方案就确定下来了，然后进入执行器阶段。 如果你还有一些疑问，比如优化器是怎么选择索引的，有没有可能选择错等。后面讲到索引我们再谈。

在查询优化器中，可以分为逻辑查询优化阶段和物理查询优化阶段。

2.1.4、执行器

在执行之前需要判断该用户是否具备权限。如果没有，就会返回权限错误。如果具备权限，就执行 SQL查询并返回结果。在 MySQL8.0 以下的版本，如果设置了查询缓存，这时会将查询结果进行缓存。

select * from test where id=1;

比如：表 test 中，ID 字段没有索引，那么执行器的执行流程是这样的：

• 调用 InnoDB 引擎接口取这个表的第一行，判断 ID 值是不是1，如果不是则跳过，如果是则将这行存在结果集中； 调用引擎接口取“下一行”，重复相同的判断逻辑，直到取到这个表的最后一行。
• 执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户端。

至此，这个语句就执行完成了。对于有索引的表，执行的逻辑也差不多。

SQL 语句在 MySQL 中的流程是： SQL语句→查询缓存→解析器→优化器→执行器 。

3、数据库缓冲池(buffer pool)

InnoDB 存储引擎是以页为单位来管理存储空间的，我们进行的增删改查操作其实本质上都是在访问页面（包括读页面、写页面、创建新页面等操作）。而磁盘 I/O 需要消耗的时间很多，而在内存中进行操作，效率则会高很多，为了能让数据表或者索引中的数据随时被我们所用，DBMS 会申请 占用内存来作为 数据缓冲池 ，在真正访问页面之前，需要把在磁盘上的页缓存到内存中的 Buffer Pool 之后才可以访
问。
这样做的好处是可以让磁盘活动最小化，从而 减少与磁盘直接进行 I/O 的时间 。要知道，这种策略对提升 SQL 语句的查询性能来说至关重要。如果索引的数据在缓冲池里，那么访问的成本就会降低很多。

3.1、缓冲池 vs 查询缓存

• 缓冲池和查询缓存是一个东西吗？
  不是。

3.1.1、缓冲池（Buffer Pool）

首先我们需要了解在 InnoDB 存储引擎中，缓冲池都包括了哪些，在 InnoDB 存储引擎中有一部分数据会放到内存中，缓冲池则占了这部分内存的大部分，它用来存储各种数据的缓存，如下图所示：

从图中，你能看到 InnoDB 缓冲池包括了数据页、索引页、插入缓冲、锁信息、自适应 Hash 和数据字典信息等。

3.1.1.1、缓存池的重要性

• 缓存原则**：“ 位置 * 频次 ”**这个原则，可以帮我们对 I/O 访问效率进行优化。

1. 首先，位置决定效率，提供缓冲池就是为了在内存中可以直接访问数据。
2. 其次，频次决定优先级顺序。因为缓冲池的大小是有限的，比如磁盘有 200G，但是内存只有 16G，缓冲池大小只有 1G，就无法将所有数据都加载到缓冲池里，这时就涉及到优先级顺序，会优先对使用频次高 的热数据进行加载 。

3.1.1.2、缓冲池如何读取数据

缓冲池管理器会尽量将经常使用的数据保存起来，在数据库进行页面读操作的时候，首先会判断该页面是否在缓冲池中，如果存在就直接读取，如果不存在，就会通过内存或磁盘将页面存放到缓冲池中再进行读取。

缓存在数据库中的结构和作用如下图所示：

• 如果我们执行 SQL 语句的时候更新了缓存池中的数据，那么这些数据会马上同步到磁盘上吗？
  不会，具体的同步磁盘的方式按照刷盘的策略进行同步数据到磁盘，同步数据的方式是以页为基本单位进行同步的。

3.1.1.3、查看/设置缓冲池的大小

如果你使用的是 InnoDB 存储引擎，可以通过查看 innodb_buffer_pool_size 变量来查看缓冲池的大小。命令如下：

show variables like 'innodb_buffer_pool_size';

你能看到此时 InnoDB 的缓冲池大小只有 134217728/1024/1024=128MB。我们可以修改缓冲池大小，比如改为256MB，方法如下：

set global innodb_buffer_pool_size = 268435456;

或者在配置文件中修改

[server] 
innodb_buffer_pool_size = 268435456

然后再来看下修改后的缓冲池大小，此时已成功修改成了 256 MB：

3.1.1.4、多个Buffer Pool实例

[server] 
innodb_buffer_pool_instances = 2

这样就表明我们要创建2个 Buffer Pool 实例。我们看下如何查看缓冲池的个数，使用命令：

show variables like 'innodb_buffer_pool_instances';

那每个 Buffer Pool 实例实际占多少内存空间呢？其实使用这个公式算出来的：

innodb_buffer_pool_size / innodb_buffer_pool_instances

也就是总共的大小除以实例的个数，结果就是每个 Buffer Pool 实例占用的大小

• Buffer Pool更新数据流程
  
• 我更新到一半突然发生错误了，想要回滚到更新之前的版本，该怎么办？连数据持久化的保证、事务回滚都做不到还谈什么崩溃恢复？
  答案：Redo Log & Undo Log

3.1.2、查询缓存

查询缓存是提前把 查询结果缓存 起来，这样下次不需要执行就可以直接拿到结果。需要说明的是，在MySQL 中的查询缓存，不是缓存查询计划，而是查询对应的结果。因为命中条件苛刻，而且只要数据表发生变化，查询缓存就会失效，因此命中率低。

4、存储引擎

4.1、查看存储引擎

show engines;

show engines\G

4.2、设置系统默认的存储引擎

4.2.1、查看默认的存储引擎：

show variables like '%storage_engine%'; 
#或
SELECT @@default_storage_engine;

4.2.2、修改默认的存储引擎

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

SET DEFAULT_STORAGE_ENGINE=MyISAM;

或者修改 my.cnf 文件：

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

4.3、设置表的存储引擎

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

4.3.1、创建表时指定存储引擎

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

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

4.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 的表结构：

SET DEFAULT_STORAGE_ENGINE=MyISAM; default-storage-engine=MyISAM 
#重启服务 
systemctl restart mysqld.service 

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、引擎介绍

4.4.1、InnoDB 引擎

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

4.4.2、MyISAM 引擎

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

4.4.3、Archive 引擎：用于数据存档

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

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

4.4.6、Memory 引擎：置于内存的表

4.4.6.1、概述：

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

4.4.6.2、主要特征：

• Memory同时 支持哈希（HASH）索引 和 B+树索引 。
• Memory表至少比MyISAM表要 快一个数量级 。
• MEMORY 表的大小是受到限制 的。表的大小主要取决于两个参数，分别是 max_rows 和 max_heap_table_size 。其中，max_rows可以在创建表时指定max_heap_table_size的大小默认为16MB，可以按需要进行扩大。
• 数据文件与索引文件分开存储。
• 缺点：其数据易丢失，生命周期短。基于这个缺陷，选择MEMORY存储引擎时需要特别小心。

4.4.6.3、使用Memory存储引擎的场景：

• 目标数据比较小 ，而且非常 频繁的进行访问 ，在内存中存放数据，如果太大的数据会造成 内存溢 出 。可以通过参数 max_heap_table_size 控制Memory表的大小，限制Memory表的最大的大小。
• 如果 数据是临时的 ，而且 必须立即可用 得到，那么就可以放在内存中。
• 存储在Memory表中的数据如果突然间 丢失的话也没有太大的关系 。

4.4.7、Federated 引擎

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

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

4.4.9、NDB引擎

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

4.4.10、 MyISAM和InnoDB引擎对比

MySQL中同一个数据库，不同的表可以选择不同的存储引擎。MySQL5.5之前的默认存储引擎是MyISAM，5.5之后改为了InnoDB。

总结：
InnoDB引擎：mysql5.5之后的默认存储引擎，具备支持外键、支持事务功能、支持行级锁和表级锁，默认是行锁
MyISAM引擎：mysql5.5之前的默认存储引擎，不支持外键、不支持事务功能、支持表级锁、不支持行锁

InnoDB和MyISAM的索引都是使用B+树结构，InnoDB使用的是 “聚簇索引（clustered index） + 辅助索引（secondary index）”，其中聚集索引的叶子结点存储的是数据本身，数据文件直接存储在主键索引这棵B+树上，辅助索引的叶子节点存储的是主键的值，需要通过回表到主键B+树上才能找到数据，需要两次索引；
MyISAM是非聚簇索引，数据文件和索引是完全分离开的，所有索引树的叶子结点存储的都是 数据文件的地址指针。

InnoDB的存储文件有 frm、idb： frm是表定义文件， ibd 是数据文件；
MyISAM的存储文件有 frm、myd、myi： frm是表定义文件， myd 是数据文件， myi 是索引文件。

4.4.10.1、InnoDB表的优势

• InnoDB存储引擎在实际应用中拥有诸多优势，比如操作便利、提高了数据库的性能、维护成本低等。
• 如果由于硬件或软件的原因导致服务器崩溃，那么在重启服务器之后不需要进行额外的操作。InnoDB崩溃恢复功能自动将之前提交的内容定型，然后撤销没有提交的进程，重启之后继续从崩溃点开始执行。
• InnoDB存储引擎在主内存中维护缓冲池，高频率使用的数据将在内存中直接被处理。这种缓存方式应用于多种信息，加速了处理进程。在专用服务器上，物理内存中高达80%的部分被应用于缓冲池。
• 如果需要将数据插入不同的表中，可以设置外键加强数据的完整性。更新或者删除数据，关联数据将会被自动更新或删除。如果试图将数据插入从表，但在主表中没有对应的数据，插入的数据将被自动移除。如果磁盘或内存中的数据出现崩溃，在使用脏数据之前，校验和机制会发出警告。当每个表的主键都设置合理时，与这些列有关的操作会被自动优化。插入、更新和删除操作通过做改变缓冲自动机制进行优化。 InnoDB不仅支持当前读写，也会 缓冲改变的数据到数据流磁盘 。
• InnoDB的性能优势不只存在于长时运行查询的大型表。在同一列多次被查询时，自适应哈希索引会提高查询的速度。
• 使用InnoDB可以压缩表和相关的索引，可以 在不影响性能和可用性的情况下创建或删除索引 。对于大型文本和BLOB数据，使用动态行形式，这种存储布局更高效。
• 通过查询INFORMATION_SCHEMA库中的表可以监控存储引擎的内部工作。在同一个语句中，InnoDB表可以与其他存储引擎表混用。即使有些操作系统限制文件大小为2GB，InnoDB仍然可以处理。 当处理大数据量时， InnoDB兼顾CPU，以达到最大性能 。

4.4.10.2、InnoDB和ACID模型

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

下面讲解InnoDB存储引擎与ACID模型相同作用的四个方面。

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

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

4.4.10.2.2、 一致性方面

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

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

4.4.10.2.3、隔离方面

隔离是应用于事务的级别，与MySQL相关的特性主要包括：自动提交设置。SET ISOLATION LEVEL语句。InnoDB锁的低级别信息。

4.4.10.2.4、 耐久性方面

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

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

4.4.10.3、InnoDB架构

4.4.10.3.1、缓冲池

缓冲池是主内存中的一部分空间，用来缓存已使用的表和索引数据。缓冲池使得经常被使用的数据能够直接在内存中获得，从而提高速度。

4.4.10.3.2、更改缓存

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

4.4.10.3.3、自适应哈希索引

自适应哈希索引将负载和足够的内存结合起来，使得InnoDB像内存数据库一样运行，不需要降低事务上的性能或可靠性。这个特性通过innodb_adaptive_hash_index选项配置，或者通过-- skip-innodb_adaptive_hash_index命令行在服务启动时关闭。

4.4.10.3.4、重做日志缓存

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

4.4.10.3.5、系统表空间

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

4.4.10.3.6、双写缓存

双写缓存位于系统表空间中，用于写入从缓存池刷新的数据页。只有在刷新并写入双写缓存后，InnoDB才会将数据页写入合适的位置。

4.4.10.3.7、撤销日志

撤销日志是一系列与事务相关的撤销记录的集合，包含如何撤销事务最近的更改。如果其他事务要查询原始数据，可以从撤销日志记录中追溯未更改的数据。撤销日志存在于撤销日志片段中，这些片段包含于回滚片段中。

4.4.10.3.8、 每个表一个文件的表空间

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

4.4.10.3.9、通用表空间

使用CREATE TABLESPACE语法创建共享的InnoDB表空间。通用表空间可以创建在MySQL数据目录之外能够管理多个表并支持所有行格式的表。

4.4.10.3.10、撤销表空间

撤销表空间由一个或多个包含撤销日志的文件组成。撤销表空间的数量由innodb_undo_tablespaces配置项配置。

4.4.10.3.11、 临时表空间

用户创建的临时表空间和基于磁盘的内部临时表都创建于临时表空间。innodb_temp_data_file_path配置项定义了相关的路径、名称、大小和属性。如果该值为空，默认会在innodb_data_home_dir变量指定的目录下创建一个自动扩展的数据文件。

4.4.10.3.12、重做日志

重做日志是基于磁盘的数据结构，在崩溃恢复期间使用，用来纠正数据。正常操作期间，重做日志会将请求数据进行编码，这些请求会改变InnoDB表数据。遇到意外崩溃后，未完成的更改会自动在初始化期间重新进行。