MYSQL 架构

MYSQL 架构_第1张图片

Connectors

连接器,指的是不同语言中与SQL的交互

 

Management Serveices & Utilities

系统管理和控制工具

 

Connection Pool: 连接池

用于管理并且缓冲用户连接以及线程处理等需要缓存的需求。

负责监听 Mysql Server的各种请求,接收、转发请求到线程的管理模块。每一个连接Mysql Server 的客户端请求都会被分配一个连接线程为其单独服务。

SQL Interface: SQL接口

接受用户的SQL命令,并且返回用户需要查询的结果。比如select from就是调用SQL Interface

Parser: 解析器

SQL命令传递到解析器的时候会被解析器验证和解析。 主要功能:

a . 将SQL语句进行语义和语法的分析,分解成数据结构,然后按照不同的操作类型进行分类,然后做出针对性的转 发到后续步骤,以后SQL语句的传递和处理就是基于这个结构的。

b. 如果在分解过程中遇到错误,那么就说明这个sql语句是不合理的。

Optimizer: 查询优化器

SQL语句在查询之前会使用查询优化器对查询进行优化。explain语句查看的SQL语句执行计划,就是由查询优化器生成的。

Cache和Buffer: 查询缓存

他的主要功能是将客户端提交给MySQL的 select请求的返回结果集 cache 到内存中,与该 query 的一个 hash 值 做 一个对应。该 Query 所取数据的基表发生任何数据的变化之后, MySQL 会自动使该 query 的Cache 失效。在读写 比例非常高的应用系统中, Query Cache 对性能的提高是非常显著的。当然它对内存的消耗也是非常大的。 如果查询缓存有命中的查询结果,查询语句就可以直接去查询缓存中取数据。这个缓存机制是由一系列小缓存组成 的。比如表缓存,记录缓存,key缓存,权限缓存等

Pluggable Storage Engines:存储引擎

与其他数据库例如Oracle 和SQL Server等数据库中只有一种存储引擎不同的是,MySQL有一个被称为“Pluggable Storage Engine Architecture”(可插拔的存储引擎架构)的特性,也就意味着MySQL数据库提供了多种存储引擎。 而且存储引擎是针对表的,用户可以根据不同的需求为数据表选择不同的存储引擎,用户也可以根据自己的需要编写 自己的存储引擎。也就是说,同一数据库不同的表可以选择不同的存储引擎

creat table xxx()engine=InnoDB/Memory/MyISAM

简而言之,存储引擎就是如何存储数据、如何为存储的数据建立索引和如何更新、查询数据等技术的实现方法。

 

InnoDB和MyISAM存储引擎区别:

MyISAM:拥有较高的查询、插入速度不支持事务,不支持行锁,支持3种不同的存储格式。

InnoDB:5.5版本后默认数据库引擎,支持事务,行锁,多版本并发控制的事务安全,比MyISAM处理速度稍慢,支持外键

存储引擎的选型:

MyISAM:主要用于插入新纪录和读取记录,如果应用完整性、并发性要求比较低也可以使用。

InnoDB:对事务完整性要求高要求实现并发控制

 

简化版执行流程图

MYSQL 架构_第2张图片

 

查询缓存

mysql拿到一个查询请求后,会先去查询缓存中查找是否存在,在查询缓存中之前执行过的语句会以key-value的形式存储起来。key为查询语句hash之后的值,value是查询结果,如果在缓存中查找到了(命中缓存),将会直接返回结果,而不会执行其他步骤。

注意:查询缓存失效非常频繁,只要其中一个表进行了更新,这个表上的所有查询缓存都会被清空。因此查询缓存命中率很低,在经常更新的数据库中并不适用。在mysql 8.0中已经将该模块删除

 

分析器

对sql语句进行解析,先进行词法分析,再进行词法分析

优化器

优化器是在表中有多个索引时,决定适用哪个索引;多表关联时,决定各个表的连接顺序。

执行器

执行阶段,需要先判断用户对表是否有权限,如果没有权限,则返回没有权限错误,有的话则打开表继续执行。

 

物理结构

MySQL是通过文件系统对数据和索引进行存储的。

MySQL从物理结构上可以分为日志文件和数据索引文件。

日志文件

MySQL通过日志记录了数据库操作信息和错误信息。常用的日志文件包括错误日志、二进制日志、查询日志、慢查 询日志和事务Redo 日志、中继日志等。 可以通过命令查看当前数据库中的日志使用信息:

mysql> show variables like 'log_%';

错误日志(errorlog)

默认是开启的,而且从5.5.7以后无法关闭错误日志,该日志记录了mysql运行时遇到的严重错误信息,已经每次启动和关闭的详细信息

二进制日志(bin log)

默认是关闭的,binlog记录了数据库所有的ddl语句和dml语句,但不包括select语句内容,语句以事件的形式保存,描述了数据的 变更顺序,binlog还包括了每个更新语句的执行时间信息。如果是DDL语句,则直接记录到binlog日志,而DML语句,必须通过事务提交才能记录到binlog日志中。 binlog主要用于实现mysql主从复制、数据备份、数据恢复

通用查询日志(general query log)

默认是关闭的,该日志会记录用户所有操作,包括增删改查等信息,在并发情况下会产生大量不必要的磁盘IO,建议生产环境不要开启该日志。

慢查询日志(slow query log)

默认是关闭的,需要通过以下设置进行开启:

#开启慢查询日志

slow_query_log=ON

#慢查询的阈值

long_query_time=3

#日志记录文件如果没有给出file_name值, 默认为主机名,后缀为-slow.log。如果给出了文件名,但不是绝对路径 名,文件则写入数据目录。

slow_query_log_file=file_name

记录执行时间超过long_query_time秒的所有查询,便于收集查询时间比较长的SQL语句。

 

重做日志(redo log) 

作用:确保事务持久性。mysql如果发生故障,重启之后会从 redo log日志中进行重做。

内容:是物理格式的日志,记录的是物理数据页面的修改信息。

产生时间:事务开始之后。

释放时间:对应事务的脏页写入到磁盘后。

重做日志缓冲区:Innodb_log_buffer,默认大小为8M,innodb先将重做日志写入缓冲区,然后通过3种方式写入到磁盘:

1.Mater Thread 每秒刷新执行写入磁盘。

2.事务提交之后。

3.当缓冲区可用空间少于一半时。

回滚日志(undo log)

作用:保证了事务发生之前可以读取到之前的版本,提供多版本并发控制读(MVCC)。

内容:逻辑格式日志

产生时间:事务开始之前,同时也会产生redo log保证undo log的可靠性。

释放时间:事务提交以后,由purge线程判断是否有其他事务在使用undo段中表的上一个事务版本信息来决定是否清理空间。

对应的物理文件: MySQL5.6之前,undo表空间位于共享表空间的回滚段中,共享表空间的默认的名称是 ibdata,位于数据文件目录中。 MySQL5.6之后,undo表空间可以配置成独立的文件,但是提前需要在配置文 件中配置,完成数据库初始化后生效且不可改变undo log文件的个数   如果初始化数据库之前没有进行相关 配置,那么就无法配置成独立的表空间了。   关于MySQL5.7之后的独立undo 表空间配置参数如下   innodb_undo_directory = /data/undospace/ --undo独立表空间的存放目录   innodb_undo_logs = 128 -回滚段为128KB   innodb_undo_tablespaces = 4 --指定有4个undo log文件

 

 

 

你可能感兴趣的:(mysql,数据库)