MySQL数据库|MySQL数据库一（MySQL体系结构与存储引擎） mysql|java|数据库

一、MySQL体系架构

文章图片

MySQL Server架构自顶向下大致可以分网络连接层、服务层、存储引擎层和系统文件层。
1. 网络连接层

客户端连接器（Client Connectors）：提供与MySQL服务器建立连接的支持。目前几乎支持所有主流的服务端编程技术，例如常见的 Java、C、Python、.NET等，它们通过各自API技术与MySQL建立连接。

2. 服务层（MySQL Server）服务层是MySQL Server的核心，主要包含系统管理和控制工具、连接池、SQL接口、解析器、查询优化器和缓存六个部分。

连接池（Connection Pool）：负责存储和管理客户端与数据库的连接，一个线程负责管理一个连接。
系统管理和控制工具（Services & Utilities）：例如备份恢复、安全管理、集群管理等
SQL接口（SQL Interface）：用于接受客户端发送的各种SQL命令，并且返回用户需要查询的结果。比如DML、DDL、存储过程、视图、触发器等。
解析器（Parser）：负责将请求的SQL解析生成一个"解析树"。然后根据一些MySQL规则进一步检查解析树是否合法。
查询优化器（Optimizer）：当“解析树”通过解析器语法检查后，将交由优化器将其转化成执行计划，然后与存储引擎交互
缓存（Caches）：缓存机制是由一系列小缓存组成的。比如表缓存，记录缓存，权限缓存，引擎缓存等。如果查询缓存有命中的查询结果，查询语句就可以直接去查询缓存中取数据。

3. 存储引擎层（Pluggable Storage Engines）存储引擎负责MySQL中数据的存储与提取，与底层系统文件进行交互。MySQL存储引擎是插件式的，服务器中的查询执行引擎通过接口与存储引擎进行通信，接口屏蔽了不同存储引擎之间的差异。现在有很多种存储引擎，各有各的特点，最常见的是MyISAM和InnoDB。
4. 系统文件层（File System）该层负责将数据库的数据和日志存储在文件系统之上，并完成与存储引擎的交互，是文件的物理存储层。主要包含日志文件，数据文件，配置文件，pid 文件，socket 文件等。

日志文件层
- 错误日志（Error log）：默认开启，show variables like ‘%log_error%’
- 通用查询日志（General query log）：记录一般查询语句，show variables like ‘%general%’;
- 二进制日志（binary log）：记录了对MySQL数据库执行的更改操作，并且记录了语句的发生时间、执行时长；但是它不记录select、show等不修改数据库的SQL。主要用于数据库恢复和主从复制。show variables like ‘%log_bin%’; //是否开启；show variables like ‘%binlog%’; //参数查看；show binary logs; //查看日志文件
- 慢查询日志（Slow query log）：记录所有执行时间超时的查询SQL，默认是10秒。show variables like ‘%slow_query%’; //是否开启；show variables like ‘%long_query_time%’; //时长
配置文件
- 用于存放MySQL所有的配置信息文件，比如my.cnf、my.ini等。
数据文件
- db.opt 文件：记录这个库的默认使用的字符集和校验规则。
- frm 文件：存储与表相关的元数据（meta）信息，包括表结构的定义信息等，每一张表都会有一个frm 文件。
- MYD 文件：MyISAM 存储引擎专用，存放 MyISAM 表的数据（data)，每一张表都会有一个.MYD 文件。
- MYI 文件：MyISAM 存储引擎专用，存放 MyISAM 表的索引相关信息，每一张 MyISAM 表对应一个 .MYI 文件。
- ibd文件和 IBDATA 文件：存放 InnoDB 的数据文件（包括索引）。InnoDB 存储引擎有两种表空间方式：独享表空间和共享表空间。独享表空间使用 .ibd 文件来存放数据，且每一张InnoDB 表对应一个 .ibd 文件。共享表空间使用 .ibdata 文件，所有表共同使用一个（或多个，自行配置）.ibdata 文件。
- ibdata1 文件：系统表空间数据文件，存储表元数据、Undo日志等。
- ib_logfile0、ib_logfile1 文件：Redo log 日志文件。
pid 文件
- pid 文件是 mysqld 应用程序在 Unix/Linux 环境下的一个进程文件，和许多其他 Unix/Linux 服务端程序一样，它存放着自己的进程 id。
socket 文件
- socket 文件也是在 Unix/Linux 环境下才有的，用户在 Unix/Linux 环境下客户端连接可以不通过TCP/IP 网络而直接使用 Unix Socket 来连接 MySQL。

二、MySQL运行机制

文章图片

1. 建立连接（Connectors&Connection Pool），通过客户端/服务器通信协议与MySQL建立连接。MySQL 客户端与服务端的通信方式是 “ 半双工 ”。对于每一个 MySQL 的连接，时刻都有一个线程状态来标识这个连接正在做什么。
- 通讯机制：
  - 全双工：能同时发送和接收数据，例如平时打电话。
  - 半双工：指的某一时刻，要么发送数据，要么接收数据，不能同时。例如早期对讲机
  - 单工：只能发送数据或只能接收数据。例如单行道
2. 查询缓存（Cache&Buffer），这是MySQL的一个可优化查询的地方，如果开启了查询缓存且在查询缓存过程中查询到完全相同的SQL语句，则将查询结果直接返回给客户端；如果没有开启查询缓存或者没有查询到完全相同的 SQL 语句则会由解析器进行语法语义解析，并生成“解析树”。
- 要求完全相同（包括参数值），这样才会匹配缓存数据命中。
- 即使开启查询缓存，以下SQL也不能缓存
  - 查询语句使用SQL_NO_CACHE
  - 查询的结果大于query_cache_limit设置
  - 查询中有一些不确定的参数，比如now()
3. 解析器（Parser）将客户端发送的SQL进行语法解析，生成"解析树"。预处理器根据一些MySQL规则进一步检查“解析树”是否合法，例如这里将检查数据表和数据列是否存在，还会解析名字和别名，看看它们是否有歧义，最后生成新的“解析树”。
4. 查询优化器（Optimizer）根据“解析树”生成最优的执行计划。MySQL使用很多优化策略生成最优的执行计划
- 等价变换策略
  - 5=5 and a>5 改成 a > 5
  - a < b and a=5 改成b>5 and a=5
  - 基于联合索引，调整条件位置等
- 优化count、min、max等函数
  - InnoDB引擎min函数只需要找索引最左边
  - InnoDB引擎max函数只需要找索引最右边
  - MyISAM引擎count(*)，不需要计算，直接返回
- 提前终止查询
  - 使用了limit查询，获取limit所需的数据，就不在继续遍历后面数据
- in的优化
  - MySQL对in查询，会先进行排序，再采用二分法查找数据。比如where id in (2,1,3)，变成 in (1,2,3)
4. 查询优化器（Optimizer）查询执行引擎负责执行 SQL 语句，此时查询执行引擎会根据 SQL 语句中表的存储引擎类型，以及对应的API接口与底层存储引擎缓存或者物理文件的交互，得到查询结果并返回给客户端。若开启用查询缓存，这时会将SQL 语句和结果完整地保存到查询缓存（Cache&Buffer）中，以后若有相同的 SQL 语句执行则直接返回结果。
- 如果开启了查询缓存，先将查询结果做缓存操作
- 返回结果过多，采用增量模式返回

三、MySQL存储引擎
使用show engines命令，就可以查看当前数据库支持的引擎信息。
MySQL在5.5版本之前默认采用MyISAM存储引擎，从5.5开始采用InnoDB存储引擎。
1. 常见存储引擎

InnoDB：支持事务，具有提交，回滚和崩溃恢复能力，事务安全
MyISAM：不支持事务和外键，访问速度快
Memory：利用内存创建表，访问速度非常快，因为数据在内存，而且默认使用Hash索引，但是一旦关闭，数据就会丢失
Archive：归档类型引擎，仅能支持insert和select语句
Csv：以CSV文件进行数据存储，由于文件限制，所有列必须强制指定not null，另外CSV引擎也不支持索引和分区，适合做数据交换的中间表
BlackHole: 黑洞，只进不出，进来消失，所有插入数据都不会保存
Federated：可以访问远端MySQL数据库中的表。一个本地表，不保存数据，访问远程表内容。
MRG_MyISAM：一组MyISAM表的组合，这些MyISAM表必须结构相同，Merge表本身没有数据，对Merge操作可以对一组MyISAM表进行操作

2. InnoDB和MyISAM对比 InnoDB和MyISAM是使用MySQL时最常用的两种引擎类型，两者的区别如下：

事务和外键
- InnoDB支持事务和外键，具有安全性和完整性，适合大量insert或update操作
- MyISAM不支持事务和外键，它提供高速存储和检索，适合大量的select查询操作
锁机制
- InnoDB支持行级锁，锁定指定记录。基于索引来加锁实现。
- MyISAM支持表级锁，锁定整张表。
索引结构
- InnoDB使用聚集索引（聚簇索引），索引和记录在一起存储，既缓存索引，也缓存记录。
- MyISAM使用非聚集索引（非聚簇索引），索引和记录分开。
并发处理能力
- MyISAM使用表锁，会导致写操作并发率低，读之间并不阻塞，读写阻塞。
- InnoDB读写阻塞可以与隔离级别有关，可以采用多版本并发控制（MVCC）来支持高并发
存储文件
- InnoDB表对应两个文件，一个.frm表结构文件，一个.ibd数据文件。InnoDB表最大支持64TB；
- MyISAM表对应三个文件，一个.frm表结构文件，一个MYD表数据文件，一个.MYI索引文件。从MySQL5.0开始默认限制是256TB。

【MySQL数据库|MySQL数据库一（MySQL体系结构与存储引擎）】这两种引擎如何选择呢？

是否需要事务？有，InnoDB
是否存在并发修改？有，InnoDB
是否追求快速查询，且数据修改少？是，MyISAM
在绝大多数情况下，推荐使用InnoDB

四、InnoDB存储引擎
1. InnoDB线程模型 InnoDB存储引擎是多线程的模型，所以有多个不同的后台线程，负责处理不同的任务。主要有：Master Thread、IO Thread、Purge Thread、Page Cleaner Thread四种。

文章图片

a. IO Thread
在InnoDB中使用了大量的AIO（Async IO）来做读写处理，这样可以极大提高数据库的性能。在InnoDB1.0版本之前共有4个IO Thread，分别是write，read，insert buffer和log thread，后来版本将read thread和write thread分别增大到了4个，一共有10个了。

read thread ：负责读取操作，将数据从磁盘加载到缓存page页。4个
write thread：负责写操作，将缓存脏页刷新到磁盘。4个
log thread：负责将日志缓冲区内容刷新到磁盘。1个
insert buffer thread ：负责将写缓冲内容刷新到磁盘。1个

b. Purge Thread
事务提交之后，其使用的undo日志将不再需要，因此需要Purge Thread回收已经分配的undo页。
c. Page Cleaner Thread
作用是将脏数据刷新到磁盘，脏数据刷盘后相应的redo log也就可以覆盖，即可以同步数据，又能达到redo log循环使用的目的。会调用write thread线程处理。
d. Master Thread
Master thread是InnoDB的主线程，负责调度其他各线程，优先级最高。作用是将缓冲池中的数据异步刷新到磁盘，保证数据的一致性。包含：脏页的刷新（page cleaner thread）、undo页回收（purge thread）、redo日志刷新（log thread）、合并写缓冲等。内部有两个主处理，分别是每隔1秒和10秒处理。
每1秒的操作：

刷新日志缓冲区，刷到磁盘
合并写缓冲区数据，根据IO读写压力来决定是否操作
刷新脏页数据到磁盘，根据脏页比例达到75%才操作（innodb_max_dirty_pages_pct，innodb_io_capacity）

每10秒的操作：

刷新脏页数据到磁盘
合并写缓冲区数据
刷新日志缓冲区
删除无用的undo页

2. Undo Log Undo Log：数据库事务开始之前，会将要修改的记录存放到 Undo 日志里，当事务回滚时或者数据库崩溃时，可以利用 Undo 日志，撤销未提交事务对数据库产生的影响。
Undo Log产生和销毁：Undo Log在事务开始前产生；事务在提交时，并不会立刻删除undolog，innodb会将该事务对应的undo log放入到删除列表中，后面会通过后台线程purge thread进行回收处理。Undo Log属于逻辑日志，记录一个变化过程。例如执行一个delete，undolog会记录一个insert；执行一个update，undolog会记录一个相反的update。
Undo Log作用:

实现事务的原子性：事务处理过程中，如果出现了错误或者用户执行了 ROLLBACK 语句，MySQL 可以利用 Undo Log 中的备份将数据恢复到事务开始之前的状态
实现多版本并发控制（MVCC）：Undo Log 在 MySQL InnoDB 存储引擎中用来实现多版本并发控制。事务未提交之前，Undo Log保存了未提交之前的版本数据，Undo Log 中的数据可作为数据旧版本快照供其他并发事务进行快照读。

3. Redo Log Redo Log：指事务中修改的任何数据，将最新的数据备份存储的位置（Redo Log），被称为重做日志。
Redo Log 的生成和释放：随着事务操作的执行，就会生成Redo Log，在事务提交时会将产生Redo Log写入Log Buffer，并不是随着事务的提交就立刻写入磁盘文件。等事务操作的脏页写入到磁盘之后，Redo Log 的使命也就完成了，Redo Log占用的空间就可以重用（被覆盖写入）。
Redo Log写入机制：Redo Log 文件内容是以顺序循环的方式写入文件，写满时则回溯到第一个文件，进行覆盖写。

文章图片

write pos 是当前记录的位置，一边写一边后移，写到最后一个文件末尾后就回到 0 号文件开头；
checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件；
write pos 和 checkpoint 之间还空着的部分，可以用来记录新的操作。如果 write pos 追上checkpoint，表示写满，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint推进一下。

4. Binlog Redo Log 是属于InnoDB引擎所特有的日志，而MySQL Server也有自己的日志，即 Binarylog（二进制日志），简称Binlog。
Binlog是记录所有数据库表结构变更以及表数据修改的二进制日志，不会记录SELECT和SHOW这类操作。Binlog日志是以事件形式记录，还包含语句所执行的消耗时间。
开启Binlog日志有以下两个最重要的使用场景：