让你搞懂MYSQL底层原理 - 内部结构

一、一条SQL执行过程

先看看一条查询SQL
在这里插入图片描述
(这里提供一下官方对各存储引擎的文档说明 Mysql存储引擎

一条 update SQL执行
update的执行 从客户端 => ··· => 执行引擎 是一样的流程,都要先查到这条数据,然后再去更新。要想理解 UPDATE 流程我们先来看看,Innodb的架构模型。
Innodb 架构
上一张 MYSQL 官方InnoDB架构图:
在这里插入图片描述
内部模块
连接器(JDBC、ODBC等) =>

[MYSQL 内部

[Connection Pool] (授权、线程复用、连接限制、内存检测等)
=>

[SQL Interface] (DML、DDL、Views等) [Parser] (Query Translation、Object privilege) [Optimizer] (Access Paths、 统计分析) [Caches & Buffers]
=>
[Pluggable Storage Engines] 

=> [File]

二、内存结构

这里有个关键点,当我们去查询数据时候会先 拿着我们当前查询的 page 去 buffer pool 中查询 当前page是否在缓冲池中。如果在,则直接获取。

而如果是update操作时,则会直接修改 Buffer中的值。这个时候,buffer pool中的数据就和我们磁盘中实际存储的数据不一致了,称为脏页。每隔一段时间,Innodb存储引擎就会把脏页数据刷入磁盘。一般来说当更新一条数据,我们需要将数据给读取到buffer中修改,然后写回磁盘,完成一次 落盘IO 操作。

为了提高update的操作性能,Mysql在内存中做了优化,可以看到,在架构图的缓冲池中有一块区域叫做:change buffer。顾名思义,给change后的数据,做buffer的,当更新一个没有 unique index 的数据时,直接将修改的数据放到 change buffer,然后通过 merge 操作完成更新,从而减少了那一次 落盘的IO 操作。

  • 我们上面说的有个条件:没有唯一索引的数据更新时,为什么必须要没有唯一索引的数据更新时才能直接放入changebuffer呢?如果是有唯一约束的字段,我们在更新数据后,可能更新的数据和已经存在的数据有重复,所以只能从磁盘中把所有数据读出来比对才能确定唯一性。
  • 所以当我们的数据是 写多读少 的时候,就可以通过 增加 innodb_change_buffer_max_size 来调整 change
    buffer在buffer pool 中所占的比例,默认25(即:25%)

问题又来了,merge是如何运作的
有四种情况:

  • 有其他访问,访问到了当前页的数据,就会合并到磁盘
  • 后台线程定时merge
  • 系统正常shut down之前,merge一次
  • redo log写满的时候,merge到磁盘
    在这里插入图片描述
    学习资料视频免费获取,学习直通车

你可能感兴趣的