前言

MySQL 的版本众多，目前最新版本为 MySQL 8，考虑到实际的情况，MySQL系列文章将以 CentOS 7下MySQL5.7.32 社区版本进行学习交流。

MySQL基础入门：MySQL的体系架构大纲

MySQL体系架构

My SQL 体系架构，自上往下大致可分为连接层、服务层、存储引擎层和系统文件层。

MySQL 体系架构图

1.网络连接层

客户端连接器(Connectors)，负责与客户端打交道，提供与MySQL服务器建立连接的支持，目前几乎支持所有主流编程语言。例如： JDBC 、.NET、 Python 、 Ruby 、 VB 等。

连接层包括通信协议、 线程 处理、用户名密码认证3部分。

MySQL链接示意图

2.服务层

主要包含系统管理和控制工具、连接池、SQL接口、解析器、查询优化器、缓存六大部分。

• 系统管理和控制工具(Management Services & Utilities)： 提供如备份恢复、安全管理、集群管理等基础服务
• 连接池 (Connection Pool)： 客户端每次与服务端建立连接都需要耗费大量的时间，而连接池就负责存储和管理客户端与数据库的连接，下次使用，直接从连接池中获取，提升服务器性能。可以通过下面免命令查看MySQL服务器连接池配置的最大连接数

 mysql> show VARIABLES like '%max_connections%';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 500   |
+-----------------+-------+
1 row in set (0.00 sec)  

• SQL接口(SQL Interface)： 用于接受客户端发送的各种SQL命令，并且返回用户需要查询的结果。比如 DML 、 DDL 、存储过程、视图、触发器等
• 解析器(Parser)： SQL 命令传递到解析器的时候会被解析器解析和验证

1. 将 SQL语句 按照语法规则分解成特定的数据结构( 解析树 )，并将这个数据结构向后传递。经过解析器之后的SQL语句的传递和处理都是基于这个数据结构的。
2. 如果在解析过程中遇到错误，则说明这个SQL语句是不合法的

• 查询优化器(Optimizer)： SQL语句会在执行查询之前，进行一系列的优化，例如重写查询，决定表的读取顺序，以及选择需要的 索引 等，这个阶段客户是可以通过特定的命令查询到优化器是如果进行优化的，然后继续向后传递，交由存储引擎
• 缓存(Cache & Buffers)： 当然在执行查询之前，会判断是否开启缓存，如果开启还会检查当前SQL语句是否命中缓存，如果命中，则直接从缓存中获取数据，直接返回。这个缓存机制由一系列的小缓存构成。比如表缓存，记录缓存，key 缓存，权限缓存等。

 mysql> show variables like '%query_cache_type%'; 
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| query_cache_type | OFF   |
+------------------+-------+
1 row in set (0.00 sec)  

是否开启缓存，默认OFF关闭查询缓存，ON 表示开启查询缓存，DEMAND 表示用户自定义查询缓存。

Query _ Cache _type只能配置在 my.cnf 文件中，无法直接通过命令开启或关闭缓存。在配置文件的[mysqld]下，增加配置：

 [mysqld]
query_cache_type = 1  

配置参数：

0：关闭缓存

1：开启缓存，但是默认缓存，放弃缓存需要增加sql-no-cache提示

 SELECT sql_no_cache * FROM table_name WHERE id=1;  

2：开启缓存，但是默认不缓存，执行缓存需要增加sql-cache提示

 SELECT sql_cache * FROM table_name WHERE id=1;  

缓存大小(单位：字节)，默认值 1M

 mysql> show variables like '%query_cache_size%';
+------------------+----------+
| Variable_name    | Value    |
+------------------+----------+
| query_cache_size | 33554432 |
+------------------+----------+
1 row in set (0.00 sec)  

是否支持查询缓存：

 mysql> show variables like '%have_query_cache%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| have_query_cache | YES   |
+------------------+-------+
1 row in set (0.00 sec)  

生产环境一般不建议开启。Query Cache严格要求2次 SQL 请求要完全一样，包括SQL语句，连接的数据库、协议版本、 字符集 等因素都会有影响。

MySQL在其最新的8.0版本中，删除了查询缓存(Query Cache)区域，就此，MySQL的Query Cache彻底的退出了历史舞台。在5.7版本中，MySQL已经将Query Cache的选项(query_cache_type)的缺省值设为了关闭，并在5.7.20版本中，将该配置标记为了Deprecated。

3.存储引擎层

数据库保存数据的核心技术，存储引擎服务于存储服务，是数据库中的底层套件，在创建表中使用，指定通过何种引擎存储数据，MySQL V5.1之后默认使用的存储引擎为 InnoDB 。不同的存储引擎有不同的存储机制，并且支持的功能也不相同。对于存储引擎的选择，基本上都是根据需求来定的。

MySQL 数据库 区别于其他数据库的最重要的一个特点就是其插件式的表存储引擎。MySQL 插件式的存储引擎架构提供了一系列标准的管理和服务支持，这些标准与存储引擎本身无关，可能是每个数据库系统本身都必需的，如 SQL 分析器和优化器等，而存储引擎是底层物理结构和实际文件读写的实现，每个存储引擎开发者可以按照自己的意愿来进行开发。需要特别注意的是，存储引擎是基于表的，而不是数据库。

MySQL存储引擎概要

• InnoDB存储引擎

InnoDB 是 MySQL 的默认事务型引擎，也是最重要、使用最广泛的存储引擎。它被设计用来处理大量的短期(short-lived)事务，短期事务大部分情况是正常提交的，很少会被回滚。InnoDB 的性能和自动崩溃恢复特性，使得它在非事务型存储的需求中也很流行。

• MyISAM 存储引擎

在 MySQL 5.1 及之前的版本，MyISAM是默认的存储引擎。MyISAM提供了大量的特性，包括 全文索引 、压缩、空间函数（GIS）等，但是MyISAM不支持事务和行级锁，而且有一个致命的缺陷就是崩溃后无法安全恢复。

尽管MyISAM引擎不支持事务、不支持崩溃后的安全恢复，但它绝不是一无是处的。对于只读的数据，或者表比较小、可以忍受修复（repair）操作，则依然可以继续使用MyISAM。

除此之外，MyISAM 对整张表加锁，而不是针对行。读取时会对需要读到的所有表加共享锁,写入时则对表加排他锁。所以，MyISAM很容易因为表锁的问题导致典型的的性能问题。

• Mrg_MyISAM存储引擎

Merge 存储引擎，也被称为Mrg_MyISAM引擎，是一组MyIsam表的集合，也就是说，他将MyIsam 引擎的多个相同的表聚合起来，但是他的内部没有数据，真正的数据依然是 MyIsam 引擎的表中，但是可以直接进行查询、删除更新等操作。”相同”意味着所有表具有同样的列和索引信息。

• Archive存储引擎

Archive存储引擎只支持INSERT和SELECT操作，且在MySQL 5.1之前不支持索引。Archive 引擎会缓存所有的写并利用 zlib 对插入的行进行压缩，所以比MyISAM 表的磁盘 I/O 更少。但是每次 SELECT 查询都需要执行全表扫描。所以Archive 表适合日志和数据采集类应用，这类应用做数据分析时往往需要全表扫描。或者在一些需要更快速的 INSERT 操作的场合下也可以使用。Archive 引擎 不是一个事务型的引擎 ，而是一个针对高速插入和压缩做了优化的简单引擎。

• Blackhole存储引擎

MySQL在5.x系列提供了Blackhole引擎–“黑洞”。其作用正如其名字一样：任何写入到此引擎的数据均会被丢弃掉，不做实际存储，Select语句的内容永远是空。

Blackhole虽然不存储数据，但是MySQL还是会正常的记录下Binlog（ MySQL 最重要的日志，主要用于主从复制和数据恢复）。所以可以用于复制数据到备库，或者只是简单地记录到日志。这种特殊的存储引擎可以在一些特殊的复制架构和日志审核时发挥作用。

• CSV 存储引擎

CSV引擎可以将普通的CSV文件(以逗号分割的文件)作为MySQL的表来处理，但是这种表不支持索引。CSV 引擎可以在数据库运行时拷入或者拷出文件。可以将 Excel 等的数据存储为 CSV 文件，然后复制到 MySQL数据目录下，就能在MySQL 中打开使用。同样，如果将数据写人到一个 CSV 引擎表，其他的外部程序也能立即从表的数据文件中读取 CSV 格式的数据。因此 CSV 引擎可以作为一种数据交换的机制，非常有用。

• Federated存储引擎

Federated引擎是访问其他 MySQL 服务器的一个代理，它会创建一个到远程MySQL 服务器的客户端连接，并将查询传输到远程服务器执行，然后提取或者发送需要的数据（类似于 Oracle 的 dblink ）。

当我们创建一个以Federated为存储引擎的表时，服务器在数据库目录只创建一个表定义文件。文件由表的名字开始，并有一个frm扩展名。无其它文件被创建，因为实际的数据在一个远程数据库上。这不同于为本地表工作的存储引擎的方式。

• MEMORY 存储引擎

Memory 类型的表访问数据非常快，因为它的数据是存放在内存中的，并且默认使用HASH索引，但是一旦服务关闭，表中的数据就会丢失。

Memory表至少比MyISAM表要快一个数量级，因为每个基于MEMORY存储引擎的表实际对应一个磁盘文件。该文件的文件名与表名相同，类型为frm类型。该文件中只存储表的结构。而其数据文件，都是存储在内存中，这样有利于数据的快速处理，提高整个表的效率，不需要进行磁盘 I/O。所以 Memory 表的结构在重启以后还会保留，但数据会丢失。

Memroy 表在很多场景可以发挥好的作用：

1. 用于查找(lookup）或者映射(mapping）表，例如将邮编和州名映射的表。
2. 用于缓存周期性聚合数据(periodically aggregated data)的结果。
3. 用于保存数据分析中产生的中间数据。

虽然 Memory 表的速度非常快，但还是无法取代传统的基于磁盘的表。Memroy表是表级锁，因此并发写入的性能较低。它不支持 BLOB 或TEXT类型的列，并且每行的长度是固定的，所以即使指定了 VARCHAR 列，实际存储时也会转换成 CHAR ，这可能导致部分内存的浪费。

• DNB集群引擎

使用 MySQL 服务器、NDB 集群存储引擎，以及分布式的、share-nothing 的、容灾的、高可用的 NDB 数据库的组合，被称为 MySQL 集群（(MySQL Cluster)。

常用存储引擎的选择和比较

在使用 MySQL数据库 时，选择一个合适的存储引擎是一个非常复杂的问题。不同的存储引擎都有各自的特性、优势和使用的场合，正确的选择存储引擎可以提高应用的使用效率。

下面介绍三种常用的存储引擎，它们对各种特性的支持如下表所示：

最后，除非万不得已，否则建议 不要混合使用多种存储引擎 ，否则可能带来一系列复杂的问题，以及一些潜在的 bug 和边界问题。存储引擎层和服务器层的交互已经比较复杂，更不用说混合多个存储引擎了。至少，混合存储对一致性备份和服务器参数配置都带来了一些困难。

查看MySQL存储引擎

可以通过如下命令查看当前MySQL数据库提供的存储引擎：

 show engines;  

MySQL提供的存储引擎

查看MySQL当前默认的存储引擎：

 show variables like '%storage_engine%';  

MySQL默认存储引擎(5.7.x)

系统文件层

系统文件层主要包括MySQL中存储数据的底层文件，与上层的存储引擎进行交互，是文件的物理存储层。其存储的文件主要有：日志文件、数据文件、配置文件、MySQL的进程pid文件和 socket 文件等。

结束语

你知道的越多，不知道的就越多。

程序员 的修养就是对技术发自内心的欣赏和敬畏！倘若文中表述有误，还请谅解，并欢迎与我讨论，自主思考永远比被动接受更有效！