数据库
首页 > 数据库> > 20200129 2. MySQL 架构原理 - 拉勾教育

20200129 2. MySQL 架构原理 - 拉勾教育

作者:互联网

MySQL 架构原理

MySQL 体系架构

img

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

网络连接层

服务层(MySQL Server)

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

存储引擎层(Pluggable Storage Engines)

系统文件层(File System)

该层负责将数据库的数据和日志存储在文件系统之上,并完成与存储引擎的交互,是文件的物理存储层。主要包含日志文件,数据文件,配置文件,pid 文件,socket 文件等。

MySQL 运行机制

img

  1. 建立连接( Connectors & Connection Pool ),通过客户端 / 服务器通信协议与 MySQL 建立连接。 MySQL 客户端与服务端的通信方式是 半双工。对于每一个 MySQL 的连接,时刻都有一个线程状态来标识这个连接正在做什么。

    通讯机制:

    • 全双工:能同时发送和接收数据,例如平时打电话。
    • 半双工:指的某一时刻,要么发送数据,要么接收数据,不能同时。例如早期对讲机
    • 单工:只能发送数据或只能接收数据。例如单行道

    线程状态:

    show processlist; 	#	查看用户正在运行的线程信息,root用户能查看所有线程,其他用户只能看自己的
    
    • id:线程ID,可以使用 kill xx
    • user:启动这个线程的用户
    • Host:发送请求的客户端的IP和端口号
    • db:当前命令在哪个库执行
    • Command:该线程正在执行的操作命令
      • Create DB:正在创建库操作
      • Drop DB:正在删除库操作
      • Execute:正在执行一个PreparedStatement
      • Close Stmt:正在关闭一个PreparedStatement
      • Query:正在执行一个语句
      • Sleep:正在等待客户端发送语句
      • Quit:正在退出
      • Shutdown:正在关闭服务器
    • Time:表示该线程处于当前状态的时间,单位是秒
    • State:线程状态
      • Updating:正在搜索匹配记录,进行修改
      • Sleeping:正在等待客户端发送新请求
      • Starting:正在执行请求处理
      • Checking table:正在检查数据表
      • Closing table : 正在将表中数据刷新到磁盘中
      • Locked:被其他查询锁住了记录
      • Sending Data:正在处理Select查询,同时将结果发送给客户端
    • Info:一般记录线程执行的语句,默认显示前100个字符。想查看完整的使用 show full processlist;
  2. 查询缓存(Cache&Buffer),这是 MySQL 的一个可优化查询的地方,如果开启了查询缓存且在查询缓存过程中查询到完全相同的 SQL 语句,则将查询结果直接返回给客户端;如果没有开启查询缓存或者没有查询到完全相同的 SQL 语句则会由解析器进行语法语义解析,并生成 解析树

    • 缓存 Select 查询的结果和 SQL 语句

    • 执行 Select 查询时,先查询缓存,判断是否存在可用的记录集,要求是否完全相同(包括参数值),这样才会匹配缓存数据命中。

    • 即使开启查询缓存,以下 SQL 也不能缓存:

      • 查询语句使用 SQL_NO_CACHE
      • 查询的结果大于 query_cache_limit 设置
      • 查询中有一些不确定的参数,比如 now()
   show variables like '%query_cache%'; 	#	查看查询缓存是否启用,空间大小,限制等
   show status like 'Qcache%';		#	查看更详细的缓存参数,可用缓存空间,缓存块,缓存多少等
  1. 解析器( Parser )将客户端发送的 SQL 进行语法解析,生成 解析树 。预处理器根据一些 MySQL 规则进一步检查 解析树 是否合法,例如这里将检查数据表和数据列是否存在,还会解析名字和别名,看看它们是否有歧义,最后生成新的 解析树 。

  2. 查询优化器(Optimizer)根据“解析树”生成最优的执行计划。MySQL 使用很多优化策略生成最优的执行计划,可以分为两类:静态优化(编译时优化)、动态优化(运行时优化)。

    • 等价变换策略

      • 5=5 and a>5 改成 a > 5
      • a < b and a=5 改成 b>5 and a=5
      • 基于联合索引,调整条件位置等
    • 优化 countminmax 等函数

      • InnoDB 引擎 min 函数只需要找索引最左边
      • InnoDB 引擎 max 函数只需要找索引最右边
      • MyISAM 引擎 count(*),不需要计算,直接返回
    • 提前终止查询

      使用了 limit 查询,获取 limit 所需的数据,就不再继续遍历后面数据

    • in 的优化

      MySQL 对 in 查询,会先进行排序,再采用二分法查找数据。比如 where id in (2,1,3),变
      in (1,2,3)

  3. 查询执行引擎负责执行 SQL 语句,此时查询执行引擎会根据 SQL 语句中表的存储引擎类型,以及对应的 API 接口与底层存储引擎缓存或者物理文件的交互,得到查询结果并返回给客户端。若开启用查询缓存,这时会将 SQL 语句和结果完整地保存到查询缓存( Cache & Buffer )中,以后若有相同的 SQL 语句执行则直接返回结果。

    • 如果开启了查询缓存,先将查询结果做缓存操作
    • 返回结果过多,采用增量模式返回

MySQL 存储引擎

存储引擎在 MySQL 的体系架构中位于第三层,负责 MySQL 中的数据的存储和提取,是与文件打交道的子系统,它是根据 MySQL 提供的文件访问层抽象接口定制的一种文件访问机制,这种机制就叫作存储引擎。

使用 show engines; 命令,就可以查看当前数据库支持的引擎信息。

img

在 5.5 版本之前默认采用 MyISAM 存储引擎,从 5.5 开始默认采用 InnoDB 存储引擎。

InnoDB 和 MyISAM对比

InnoDB 和 MyISAM 是使用 MySQL 时最常用的两种引擎类型,我们重点来看下两者区别:

扩展资料:各个存储引擎特性对比

img

InnoDB 存储结构

从 MySQL 5.5 版本开始默认使用 InnoDB 作为引擎,它擅长处理事务,具有自动崩溃恢复的特性,在日常开发中使用非常广泛。

下面是官方的 InnoDB 引擎架构图,主要分为内存结构磁盘结构两大部分。

img

InnoDB 内存结构

内存结构主要包括 Buffer Pool、Change Buffer、Adaptive Hash Index 和 Log Buffer 四大组件。

InnoDB 磁盘结构

InnoDB磁盘主要包含 Tablespaces,InnoDB Data Dictionary,Doublewrite Buffer、Redo Log 和 Undo Logs。

新版本结构演变

MySQL 8.0 版本:

img

InnoDB 线程模型

img

InnoDB 数据文件

InnoDB 文件存储结构

img

InnoDB数据文件存储结构:

分为一个 ibd 数据文件 --> Segment(段)--> Extent(区)--> Page(页)--> Row(行)

Page 是文件最基本的单位,无论何种类型的 page ,都是由 page header , page trailer 和 page body 组成。如下图所示:

img

InnoDB 文件存储格式

File文件格式(File-Format)

在早期的 InnoDB 版本中,文件格式只有一种,随着 InnoDB 引擎的发展,出现了新文件格式,用于支持新的功能。目前 InnoDB 只支持两种文件格式: Antelope 和 Barracuda 。

通过 innodb_file_format 配置参数可以设置 InnoDB 文件格式,之前默认值为 Antelope,5.7版本开始改为Barracuda

Row行格式(Row_format)

表的行格式决定了它的行是如何物理存储的,这反过来又会影响查询和 DML 操作的性能。如果在单个 page 页中容纳更多行,查询和索引查找可以更快地工作,缓冲池中所需的内存更少,写入更新时所需的 I/O 更少。

InnoDB 存储引擎支持四种行格式: REDUNDANT 、 COMPACT 、 DYNAMIC 和 COMPRESSED 。

img

DYNAMIC 和 COMPRESSED 新格式引入的功能有:数据压缩、增强型长列数据的页外存储和大索引前缀。

每个表的数据分成若干页来存储,每个页中采用 B 树结构存储;

如果某些字段信息过长,无法存储在 B 树节点中,这时候会被单独分配空间,此时被称为溢出页,该字段被称为页外列。

在创建表和索引时,文件格式都被用于每个 InnoDB 表数据文件(其名称与 *.ibd 匹配)。修改文件格式的方法是重新创建表及其索引,最简单方法是对要修改的每个表使用以下命令:

ALTER TABLE 表名 ROW_FORMAT=格式类型;  

Undo Log

Undo Log 介绍

Undo:意为撤销或取消,以撤销操作为目的,返回指定某个状态的操作。

Undo Log:数据库事务开始之前,会将要修改的记录存放到 Undo 日志里,当事务回滚时或者数据库崩溃时,可以利用 Undo 日志,撤销未提交事务对数据库产生的影响。

Undo Log 产生和销毁: Undo Log 在事务开始前产生;事务在提交时,并不会立刻删除 undo log , InnoDB 会将该事务对应的 undo log 放入到删除列表中,后面会通过后台线程 purge thread 进行回收处理。

Undo Log 属于逻辑日志,记录一个变化过程。例如执行一个 delete , undo log 会记录一个 insert ;执行一个 update , undo log 会记录一个相反的 update 。

Undo Log 存储: undo log 采用段的方式管理和记录。在 InnoDB 数据文件中包含一种 rollback segment 回滚段,内部包含 1024 个 undo log segment 。可以通过下面一组参数来控制 Undo log 存储:

show variables like '%innodb_undo%';

Undo Log 作用

Redo Log 和 Binlog

Redo Log 和 Binlog 是 MySQL 日志系统中非常重要的两种机制,也有很多相似之处,下面介绍下两者细节和区别。

Redo Log 日志

Binlog 日志

Binlog 日志

标签:文件,存储,Log,拉勾,20200129,InnoDB,MySQL,日志
来源: https://www.cnblogs.com/huangwenjie/p/14346307.html