MySQL是目前使用最广的开源数据库，不管从装机量、使用人群、专职人员、社区发展，还是基于MySQL的其他分支，都是当之无愧的No.1。

本文将从以下4个方面，带你搞透MySQL体系结构与存储引擎。

主要包括：

1、MySQL数据库的体系结构；

2、MySQL支持的存储引擎；

3、InnoDB能够取代MyISAM的原因；

4、InnoDB几大核心特性。

其中将重点介绍InnoDB存储的原理和特点，以MySQL5.6版本为例介绍体系结构组成，以及MySQL5.7和MySQL8.0版本做了哪些优化和改进。

*阅读本文需要10分钟*

MySQL的体系结构

如下为MySQL数据库的体系结构图：

上面client connector部分负责处理客户端的连接请求，与客户端创建连接，目前MySQL几乎支持所有的连接类型，例如常见的JDBC、Python、GO等。

下面就是MySQL Server部分，这里包括connection pool，数据库给客户端创建的连接都在这里处理和存储，用一个线程管理一个连接，包括了用户认证：也就是用户登录身份的认证和鉴权和安全管理：就是用户执行操作权限校验。

service utilities是管理服务&工具集，包括备份恢复、安全管理、集群管理服务和工具。

旁边是SQL处理所需要的功能模块了，包括SQL interface，负责接收客户端来的各种SQL语句比如DML、DDL和存储过程等；Parser是SQL解析器会对SQL进行语法解析生成解析树；还有optimizer，查询优化器，它会根据解析树生成执行计划，选择合适的索引，之后会按照执行计划去执行SQL与各个存储引擎交互；Caches缓存包括各个存储引擎的缓存部分，比如InnoDB存储有buffer pool，MyISAM存储引擎有key buffer等，也会缓存一些权限，也包括一些session级别的缓存。

再下面是MySQL所支持的各个存储引擎，这里只是举例写了一些。有最原始的MyISAM，以及InnoDB、支持归档的Archive和内存的Memory等。MySQL是插件式的存储引擎，只要写好跟MySQL Server的接口，任何引擎都可以进入MySQL里来，这也是MySQL流行的原因之一，如极数云舟的ArkDB 本质上也是了MySQL的一个引擎，在使用的时候可以用Alter table engines=ArkDB来修改之前的表为ArkDB。

最下面是物理存储层，是文件的物理存储，包括二进制日志、数据文件、错误日志、慢查询日志、全日志，redo/undo日志等。

例：用一个SQL的执行轨迹来说明客户端与MySQL的交互过程。

客户端发起一个Select语句：

第1步会通过客户端/服务器通信协议与MySQL建立连接；

第2步查询缓存，这是MySQL的一个优化查询的地方；

• 如果开启了query cache且在查询缓存中有完全相同的SQL，则会直接返回查询结果给客户端；
• 如果没有开启query cache或者没有找到完全相同的SQL则会经历解析器进行语法语义解析，生成解析树；

第3步会到预处理器生成新的解析树；

第4步查询优化器，生成执行计划；

第5步查询执行引擎去真正执行SQL，此时会根据SQL中表的存储引擎类型，对应的API接口与底层存储引擎缓存或者物理文件交互，得到查询结果，由MySQL Server过滤后缓存起来并返回给客户端。若开启了query cache，这时也会将SQL语句和结果完完全全的保存到query cache中，以后若有相同SQL执行会直接返回结果。

同理可思考， insert和update语句的执行流程是怎么样的，有哪些不同。当然，这类DML语句可能会复杂一些。

MySQL支持的存储引擎

存储引擎就是MySQL中具体与文件打交道的子系统，它是根据MySQL AB公司提供的文件访问层抽象接口来定制的一种文件访问机制，这种机制就叫存储引擎。

1.常用的存储引擎

下图是常用的一些存储引擎：

有远古时期的MyISAM、支持事务的InnoDB、内存类型的Memory、以及归档类型的Archive、列式存储的Infobright，以及一些新兴的存储引擎，以rocksdb为底层基础的MyRocks和RocksDB，和以分形树索引组织存储的TokuDB，当然现在还有极数云舟出品的分布式存储引擎ArkDB。

在MySQL5.6版本之前，默认的存储引擎都是MyISAM，但5.6之后默认的存储引擎就是InnoDB了。

2.MySQL InnoDB存储引擎的大体架构

下图为是InnoDB存储引擎的具体架构图：

上半部分是实例层（计算层），在内存里，下半部分是物理层，位于文件系统中。

1）实例层

分为线程和内存。InnoDB重要的线程有master thread，是InnoDB的主线程，负责调度其他各线程。

Master thread优先级最高, 其内部包含几个循环：主循环(loop),后台循环(background loop),刷新循环(flush loop),暂停循环(suspend loop)。master thread会根据其内部运行的相关状态在各循环间中进行切换。

大部分操作在主循环(loop)中完成,其包含有1s和10s两种操作。

1s操作主要包括：

1. 日志缓冲刷新到磁盘(这个会总是操作，即使事务还没有提交)；
2. 最多可能刷100个新脏页到磁盘；
3. 执行和并改变缓冲的操作；
4. 若当前没有用户活动，可能切换到后台循环（background loop）等。

10s操作主要包括：

1. 刷新可能最多100个脏页到磁盘；
2. 合并至多5个改变缓冲(总是)；
3. 日志缓冲刷新到磁盘(总是)；
4. 删除无用的undo页(总是)；
5. 刷新100个或者10个脏页到磁盘(总是)产生一个检查点(总是)等。

• buf dump thread负责将buffer pool中的内容dump到物理文件中，以便再次启动MySQL时加载进来，快速加热数据；
• page cleaner thread负责将buffer pool中的脏页刷新到磁盘，在5.6版本之前没有这个线程，刷新操作都是由主线程完成的，所以在刷新脏页时会非常影响MySQL的处理能力，在5.7版本之后可以通过参数设置开启多个page cleaner线程工作；
• purge thread负责将不再使用的undo日志进行回收；
• read thread处理用户的读请求，并负责将数据页从磁盘上读出来，可以通过参数设置线程数量；
• write thread负责将数据页从缓冲区写出到磁盘，也可以通过参数设置线程数量，page cleaner线程发起刷脏页操作后write thread就开始工作了；
• redo log thread负责把日志缓冲中的内容刷新到redo log文件中；
• insert buffer thread负责把insert buffer中的内容刷新到磁盘。

内存部分主要有InnoDB buffer pool，这里包含InnoDB最重要的缓存内容。数据和索引页、undo页、insert buffer页、自适应hash索引页、数据字典页和锁信息等。additional memory pool后续已不再使用。redo buffer里面存储数据修改所产生的redo log。double write buffer是double write所需的buffer，主要解决由于宕机引起物理写入操作中断，数据页不完整的情况。

2）物理层

逻辑上分为系统表空间、用户表空间和redo日志。系统表空间里有文件ibdata，和一些undo，ibdata文件里有insert buffer段、double write段、回滚段、索引段、数据字典段和undo信息段。

用户表空间是指.ibd后缀的文件，里面有insert buffer的bitmap页、叶子页（这里存储真正的用户数据）、非叶子页，InnoDB表是索引组织表，采用B+树组织存储，数据都存储在叶子节点中，分支节点（即非叶子页）存储索引分支查找的数据值。

redo中包括多个redo文件，这些文件循环使用，当达到一定存储阈值时会触发checkpoint刷脏页操作，同时也在MySQL实例异常宕机后重启，InnoDB表数据自动还原恢复过程中使用。

3.MySQL InnoDB存储引擎的内存和物理结构

以MySQL 5.6为例，InnoDB存储引擎体系结构如下图：

用户读取或者写入的最新数据都在buffer pool中，如果buffer pool中没有会读取物理文件查找，之后放到buffer pool中并返回给MySQL Server。buffer pool采用LRU机制，具体的内存队列和刷新机制不详细描述。

buffer pool决定了一个SQL执行的快慢，如果查询结果页都在内存中则返回很快，否则会产生物理读（磁盘读），性能远不如内存，则返回时间变长。但又不能将所有数据页都放到buffer pool中，比如物理文件ibd文件有500GB，机器不可能配置能容得下500GB数据页的内存，成本很高而且也没必要。单机单实例情况下，可以配置buffer pool为物理内存的60%-80%，剩余内存用于session产生的sort和join等以及运维管理使用。如果是单机多实例，所有实例的buffer pool总量也不要超过物理内存的80%。开始时可以通过经验设置一个buffer pool的经验值比如16GB，之后业务在MySQL运行一段时间后可以根据show global status like '%buffer_pool_wait%'的值来看是否需要调整buffer pool的大小。

redo log是一个循环复用的文件集，负责记录InnoDB中所有对Buffer Pool的物理修改日志，当redo log文件空间中，检查点位置的LSN和最新写入的LSN差值（checkpoint_age）达到redo log文件总空间的75%后，InnoDB会进行异步刷新操作，直到降到75%一下，并释放出redo log的空间；当checkpoint_age达到文件总量大小的90%后，会触发同步刷新，此时InnoDB是挂起的无法操作。

这样就得出redo log的大小直接影响了数据库的处理能力，如果设置太小会导致强行checkpoint操作频繁刷新脏页，那就需要设置的大一些，5.6版本之前redo log总大小不能超过3.8GB，5.7之后放开了这个限制。

事务提交时log buffer会刷新到redo log文件中，具体刷新机制由参数控制，可以根据自身业务特点配置。

• 若参数innodb_file_per_table=ON，则表示用户建表采用用户独立表空间，即一个表对应一组物理文件，.frm表定义文件和.ibd表数据文件。
• 若这个参数设置为OFF，则用户建表就存储在ibdata文件中，不建议采用共享表空间，这样会导致ibdata文件过大，而且当表删除后空间无法回收。独立表空间可以在用户删除大量数据后回收物理空间，执行一个DDL就可以将表空间的高水位降下来了。

4. 关于MySQL 5.7和8.0的一些新特点

• 5.7中将undo从共享表空间ibdata文件中分离出来，可以在安装MySQL时由用户自行指定文件大小和数量；
• 5.7中还增加了temporary临时表空间，里面存储着临时表或者临时查询结果集的数据；
• 5.7版本开始，buffer pool大小可以动态修改，无需重启数据库实例，这是DBA的福音；
• 8.0中将InnoDB表的数据字典和undo都从共享表空间ibdata中彻底分离出来了，以前需要ibdata文件中数据字典与独立表空间ibd文件中数据字典一致才行，8.0中就不需要了；
• temporary临时表空间也可以配置多个物理文件了，而且均为InnoDB存储引擎并能创建索引，这样加快了处理的速度；
• 现在用户还可以像oracle数据库那样设置一些表空间，每个表空间对应多个物理文件，每个表空间都可以给多个表使用，但一个表只能存储在一个表空间中。

InnoDB能取代MyISAM的原因

对比几个主流的存储引擎，本文主要讲解MyISAM和InnoDB的对比。

1、功能对比

InnoDB和MyISAM的对比如下图表：

• InnoDB支持ACID的事务4个特性，而MyISAM不支持；
• InnoDB支持4种事务隔离级别，默认是可重复读repeatable read，MyISAM不支持；
• InnoDB支持crash安全恢复，MyISAM不支持；InnoDB支持外键，MyISAM不支持；
• InnoDB支持行级别的锁粒度，MyISAM不支持，只支持表级别的锁粒度；
• InnoDB支持MVCC，MyISAM不支持。
• InnoDB特性上，InnoDB表最大可以64TB，支持聚簇索引、支持压缩数据存储，支持数据加密，支持查询/索引/数据高速缓存，支持自适应hash索引、空间索引，支持热备份和恢复等。

2、性能对比

InnoDB也完胜MyISAM

读写混合模式下，随着CPU核数的增加，InnoDB的读写能力呈线性增长，在这个测试用例里，最高可达近9000的TPS，但MyISAM因为读写不能并发，它的处理能力跟核数没关系，呈一条水平线，TPS低于500。

只读模式下，随着CPU核数的增加，InnoDB的读写能力呈线性增长，最高可达近14000的TPS，但MyISAM的处理能力不到3000。

以上测试仅为说明InnoDB比MyISAM的处理能力强大，具体TPS测试数据跟硬件和测试条件不同而有很大差异。

InnoDB的几大核心性能

InnoDB存储引擎的核心特性包括这些：MVCC、锁、锁算法和分类、事务、表空间和数据页、内存线程以及状态查询。

具体思维导图如下，建议多下功夫重点研究：

重点说明ARIES三原则。它是指Write Ahead Logging（WAL），即先写日志后写磁盘，日志成功写入后事务就不会丢，后续由checkpoint机制来保证磁盘物理文件与redo日志达到一致性；

利用Redo来记录变更后的数据，即redo里记录事务数据变更后的值；

利用Undo来记录变更前的数据，即undo里记录事务数据变更前的值，用于回滚和其他事务多版本读。

show engine innodb statusG的结果里面有详细的InnoDB运行态信息，分段记录的，包括内存、线程、信号、锁、事务等，请你多多使用，出现问题时从中能分析出具体原因和解决方案。