MySQL架构

MySQL架构：

• Connectors：MySQL向外提供的交互接口：

  Java等语言可以通过该接口实现和SQL的交互，操作SQL语句。

• Management Service & Utilities：管理服务组件和工具组件：

  提供对MySQL的集成管理，包括：备份，恢复，安全管理等。

• Connection Pool：连接池组件：

  负责监听客户端到MySQL的请求，创建线程负责之间的通信。

• SQL Interface：SQL接口组件：

  接收客户端的SQL命令，将结果返回客户端。

• Parser：查询分析器组件：

  分析SQL的合法性，并解析SQL的数据结构。

• Optimizer：优化器组件：

  对SQL进行优化分析。

• Caches & Buffers：缓存组件：

  SQL结果等缓存。

• Pluggable Storage Engine：插拔式存储引擎：

  可插拔式的存储引擎，用于表的创建，数据检索，索引创建等；也可满足自定义的存储引擎开发。

• File System：物理文件：

  实际存储数据的文件。

• Files & Logs：文件和日志：

  存储各式各样的日志文件。

其中MySQL的关键特点就是可插拔的存储引擎；其中InnoDB是MySQL的默认存储引擎，也是应用最为广泛的存储存储引擎，本文主要介绍InnoDB存储引擎的关键特性以及这些特性的一些思考。

数据库和数据实例的区别：

• 数据库是文件的集合，是依照某种数据模型组织起来并存放于二级存储器中的数据集合；

• 数据库实例是程序，是位于用户与操作系统之间的一层数据管理软件；

InnoDB关键特性

InnoDB有以下关键特性，其中前三个是数据库最通用的特性：

• Change Buffer（写缓存）

• Double Write（二次写）

• Adaptive Hash Index（自适应哈希索引）

• Async IO（异步IO）

• Flush Neighbor Page（属性邻接页）

1. Change Buffer

Change Buffer是InnoDB中最特殊的一个特性。Change Buffer是从InnoDB 1.0.x版本之后的引入的概念，在1.0.x版本之前叫Insert Buffer（插入缓存）。Insert Buffer顾名思义是针对Insert的缓存。

1.1 问题诞生背景

对于InnoDB，所有的数据，索引等都是以文件的形式存储，以B+树的形式存储。 InnoDB的索引分为两种：聚簇索引（Primary Index）和非聚簇索引（Secondary Index）；其中聚簇索引的B+树叶子节点存放的是真实的数据；而非聚簇索引的叶子节点存放的是聚簇索引的主键值。

我们先从索引的角度来描述下问题的背景：

• 对于聚簇索引，主键是唯一的；当插入新的数据时，需要检查下磁盘是否有主键冲突，这步磁盘访问必不可少；此外，一般对于主键的插入是顺序的（比如id自增列），这样磁盘是顺序读写的，有较好的性能。

• 对于非聚簇索引，列值不唯一；当插入新的数据时，插入的数据很难是按递增的顺序插入的，这时候对于插入操作都是随机的；如果有大量的插入操作，则会有大量的随机IO，会严重影响磁盘的性能。

因此Insert Buffer诞生的问题背景是： 大量的非聚簇索引插入操作？？？

产生的问题背景也反映了Insert Buffer需要满足两点：

• 必须是非聚簇索引；

• 索引的数据不是唯一的；（后面也会有介绍）

1.2 内部实现

1. MySQL数据存储包含内存和磁盘两部分；

2. 内存缓冲池以页（Page）为单位，缓存最热的是：数据页和索引页；

3. InnoDB以变种LRU（加了mid位置和时间的概念，非常类似于JVM的内存管理）的算法来管理缓冲池，解决了“预读失效”和“缓冲池污染”的问题；

（1）情况一 当要插入的数据已经在缓冲池了，则只需要插入redo日志文件一次磁盘操作；但redo的磁盘是顺序写，效率很高；因此这种情况不需要Insert Buffer。

缓冲池会定期的刷新到磁盘上，而不是每次都刷新，这样会降低磁盘的IO，提升性能，说白了就是批量写（可能会有同一个数据页的合并操作）。

（2）情况二 当要插入的数据不再缓冲池中，这时候需要怎么办？ 为了避免大量的随机IO，提出了Insert Buffer的概念；当插入数据时，先把数据插入到Insert Buffer中；当需要回刷磁盘时，会把Insert Buffer中的数据进行merge后写入磁盘（因为有merge，为了表示现有页的空闲空间，还需要一个特殊的页来保存每个非聚簇索引页的空闲空间），降低了磁盘随机IO。Insert Buffer也是B+树的结构，插入数据时也是按照页来组织聚簇索引和非聚簇索引数据。

举个形象的例子来说明Insert Buffer的具体作用： 图书管理员进行书籍整理，有两种做法：

• 每归还一本书，就去对应的书架上归还这本书；

• 先把书放在柜台，等书达到一定量的时候，进行批量的放回对应的书架；

正常人都会选择第二种做法；而柜台就是Insert Buffer，归还的书会先在柜台上进行整理，合并，然后一起放回书架，减少了书架的随机访问。

在MySQL5.5之后，不仅针对insert操作，还针对update和delete操作，改名为Change Buffer,原理是一致的。

Change Buffer还有一个细节点，当Change Buffer中的有数据没有写到磁盘前，数据库宕机了，这个时候Change Buffer的数据就恢复不了了，因此鉴于这种情况，InnoDB会把Change Buffer中的数据定期通过merge操作刷回表空间中的索引文件。

Change Buffer

从图中可以看出，Change Buffer并不仅仅指的是内存中的一块，还包含了物理磁盘上的共享表空间。

1.3 缺点

• 如果有大量的DML变更操作，数据宕机后，会导致恢复的时间较长；

• 有大量插入的时候，会导致占用较多的Buffer Pool内存，会影响其他数据的空间；

• 对于不同的硬件配置和负载，Change Buffer无法进行控制，比如磁盘和SSD；

2. Double Write

从IO的角度来看，InnoDB是以页为维度来读取数据，正常InnoDB的页可以配置为4K，8K，16K;而文件系统的IO读写最小单位是4K，也有些是1K；磁盘的读写最小单位是扇区（512KB）。

由于各系统以及硬件IO读写的单位不一致，往往底层的单位要小于上层的单位，因此上层就会存在部分写的场景：当写一部分数据的时候，机器宕机了，这样就会导致部分写的场景。（磁盘是由硬件保证，要么512KB全部写成功，要么都失败，不存在部分写的场景）

2.1 问题诞生背景

由上述知道，InnoDB的IO最小单位是页,正常大小为16K（可以配置为4K，8K等）；当缓冲池中的脏页回写磁盘时，磁盘的页和缓冲池的页是对等的，也就是要回写16K的数据到磁盘；而文件系统的读写单位可能是4K；这样就需要写入4次，才能完整的把脏页刷回去；如果在写2次的时候，机器断电宕机了，这个时候磁盘的页就被污染了。

基于这种场景，InnoDB诞生了Double Write的特性，用于解决partial page write（部分写）的问题。

2.2 内部实现

Double Write

Double Write的步骤：

1. 当触发脏页刷新时，先把脏页拷贝到Double Write内存中；

2. 接着把Double Write中的脏页顺序的写到共享表空间中，这部分是顺序写入磁盘，性能很高；

3. 异步的将共享表空间的数据离散的写入到各个表空间中；

Double Write如何宕机恢复的？？？

• 如果写入Double Write Buffer时失败，这个时候页还没有刷新回磁盘，也就没有发生部分写的问题，因此直接从磁盘加载原始数据，并通过事务日志重新计算写入Double Write Buffer。

• 如果写入磁盘时，宕机，由于共享表空间中副本数据恢复，重新写入磁盘即可。

为啥不用redo log解决部分写的问题？？？ 这个涉及到redo log的数据设计；如果redo log中保存了所有的数据和操作，那么redo log的size会非常大，不利于日志文件存储；因此InnoDB对于redo log的设计是保存页的指针之类的数据；因此redo log无法恢复物理页，因为redo log中不保存真实的数据。

2.3 缺点

虽然共享表空间的写入是磁盘顺序写，但依然会影响MySQL的性能；尤其是InnoDB为了保证写入共享表空间数据的完整性，在每次写入后都会调用fsync操作等待磁盘操作结束，硬盘的fsync性能比较慢；

3. Adaptive Hash Index

自适应哈希索引是InnoDB内部的一个优化特性，一般不需要开发人员关注。

3.1 问题诞生背景

首先了解下InnoDB的数据存储，InnoDB的数据和主键索引一起存储，主键索引的叶子节点存放的是数据；非主键索引叶子节点存放的是主键的key值。

当通过非聚簇索引来查询数据时，根据B+索引树查询叶子节点的主键key,然后根据主键key再去主键索引的B+树上找到对应的叶子节点的数据。

可以看出来通过非聚簇索引来查询数据时，需要访问两个B+树，而自适应哈希索引就是为了解决这个问题，直接构造非聚簇索引key到真实数据的哈希索引，哈希的时间复杂度是O（1）；因此减少了两次B+树的查询操作。

自适应哈希索引是索引的索引 ！！！

3.2 内部实现

自适应哈希索引的难点在于信息统计，要统计出查询的热点数据，为这些热点数据建立哈希索引。比如对于同一条件的频繁访问，可以构造出哈希索引，下次同样的条件可以直接获取结果。

自适应哈希索引

自适应哈希索引实现的条件：

1. 精确条件查询，以该条件查询超过100次；

2. 页访问的次数N=页记录数/16； (内部具体的信息统计涉及很多参数，后续分析)

3.3 缺点

1. 自适应哈希索引也是占用Buffer Pool的空间，会影响其他类型数据的空间容量；

2. 自适应哈希索引只支持精确条件查询，不支持范围查找；

3. 自适应哈希索引只有在极端的情况下（大量固定条件的查询），才有意义，降低逻辑读时间；

4. Async IO

为了提供磁盘操作性能，现在的数据库系统都是采用异步IO的方式来处理磁盘操作。异步IO还支持批量操作，把多个页进行整合一起进行IO操作，如果是同一页的数据，或者连续的数据，会提高磁盘的IO性能。

5. Flush Neighbor Page

刷新邻接页是根据“局部性”原理，其工作原理是： 当刷新一个脏页时，InnoDB存储引擎会检测该页所在区（extent）的所有页，如果是脏页，那么一起进行刷新。这样做的好处显而易见，通过AIO可以将多个IO写入操作合并为一个IO操作，故该工作机制在传统机械磁盘下有着显著的优势。

InnoDB文件的格式是idb后缀，其中存放了表的数据，又称为表空间Tablespace，表空间又分为多个段Segment；一个Segment又分为多个区Extent；一个区又分为多个页Page；一个页包含了多个行Row。

后记

InnoDB的关键特性和文件的存储结果密切相关，后面会分析下InnoDB表数据的文件存储结构。