MySQL架构解析
Mysql整体架构
MySQL整体架构如下图所示:
MySQL逻辑系统架构分为4层:
- 应用层
- MySQL服务层
- 存储引擎层
- 系统文件层
下面将对各层的功能和组件进行介绍,并探讨一条语句的执行过程。
应用层
应用层是MySQL体系架构的最上层,它处理与客户端的交互,主要包含连接处理、用户鉴权和安全管理。
- 连接处理:负责管理客户端与MySQL服务器之间的连接。它管理连接的建立、维护和关闭,并分配和释放连接资源以提高性能和可扩展性。
- 用户鉴权:用于验证客户端的身份。MySQL支持多种身份验证方法,如基于用户名和密码的验证、SSL/TLS证书验证等,以提高数据的安全性。
- 安全管理:涉及访问控制、权限管理和数据加密等措施。它定义用户的权限和访问级别,并防止未经授权的访问、网络攻击和数据泄露。
MySQL 服务层
该层是MySQL Server的核心层,提供了MySQL Server数据库系统的所有逻辑功能,该层可以分为如下不同的组件:
- NoSQL Interface(NoSQL 接口)
- SQL Interface(SQL 接口)
- SQL Parser(SQL 解析器)
- Optimizer (查询优化器)
- Caches & buffers(缓存)
-
NoSQL Interface(NoSQL 接口):通过NoSQL接口,MySQL Server可以像操作关系型数据一样操作非结构化数据,而不需要遵循传统的表格和列的模式。
-
SQL Interface(SQL 接口) SQL接口,接收用户的SQL命令并进行处理,得到用户所需要的结果,具体处理功能如下:
- Data Manipulation Language (DML).
- Data Definition Language (DDL).
- 存储过程
- 视图
- 触发器
-
SQL Parser(SQL 解析器) 解析器的作用主要是解析查询语句,最终生成语法树。首先解析器会对查询语句进行语法分析,如果语句语法有错误,则返回相应的错误信息。语法检查通过后,解析器会查询缓存,如果缓存中有对应的语句,就直接返回结果不进行接下来的优化执行操作。
-
Optimizer(查询优化器) 优化器的作用主要是对查询语句进行优化,包括选择合适的索引,数据的读取方式。
-
Caches & buffers(缓存) 包括全局和引擎特定的缓存,提高查询的效率。如果查询缓存中有命中的查询结果,则查询语句就可以从缓存中取数据,无须再通过解析和执行。这个缓存机制是由一系列小缓存组成,如表缓存、记录缓存、key缓存、权限缓存等。查询缓存默认是关闭的,可以通过
set query_cache_type=1
开启。
存储引擎层
存储引擎是MySQL中具体与文件打交道的子系统,也是MySQL最有特色的地方。MySQL区别于其他数据库的最重要特点是其插件式的表存储引擎。常用的四种存储引擎分别是:
- MyISAM存储引擎
- innoDB存储引擎
- MEMORY存储引擎
- ARCHIVE存储引擎
MySQL将这些存储引擎提供为可插拔的,可以在表级别使用各种存储引擎。一个数据库可以包含使用多个存储引擎的表。"SHOW ENGINES"命令将列出服务器支持的所有存储引擎。
mysql>SHOW ENGINES;
几种存储引擎的对比:
功能 | MYISAM | Memory | InnoDB | Archive |
---|---|---|---|---|
存储限制 | 256TB | RAM | 64TB | None |
支持事物 | No | No | Yes | No |
支持全文索引 | Yes | No | No | No |
支持数索引 | Yes | Yes | Yes | No |
支持哈希索引 | No | Yes | No | No |
支持数据缓存 | No | N/A | Yes | No |
支持外键 | No | No | Yes | No |
InnoDB:支持事务处理,支持外键,支持崩溃修复能力和并发控制。如果需要对事务的完整性要求比较高(比如银行),要求实现并发控制(比如售票),那选择InnoDB有很大的优势。如果需要频繁的更新、删除操作的数据库,也可以选择InnoDB,因为支持事务的提交(commit)和回滚(rollback)。
MyISAM:插入数据快,空间和内存使用比较低。如果表主要是用于插入新记录和读出记录,那么选择MyISAM能实现处理高效率。如果应用的完整性、并发性要求比 较低,也可以使用。如果数据表主要用来插入和查询记录,则MyISAM引擎能提供较高的处理效率
MEMORY:所有的数据都在内存中,数据的处理速度快,但是安全性不高。如果需要很快的读写速度,对数据的安全性要求较低,可以选择MEMOEY。它对表的大小有要求,不能建立太大的表。所以,这类数据库只使用在相对较小的数据库表。如果只是临时存放数据,数据量不大,并且不需要较高的数据安全性,可以选择将数据保存在内存中的Memory引擎,MySQL中使用该引擎作为临时表,存放查询的中间结果
Archive:如果只有INSERT和SELECT操作,可以选择Archive,Archive支持高并发的插入操作,但是本身不是事务安全的。Archive非常适合存储归档数据,如记录日志信息可以使用。
注意,同一个数据库也可以使用多种存储引擎的表。如果一个表要求比较高的事务处理,可以选择InnoDB。这个数据库中可以将查询要求比较高的表选择MyISAM存储。如果该数据库需要一个用于查询的临时表,可以选择MEMORY存储引擎。
物理文件层
物理文件包括:redolog、undolog、binlog、errorlog、querylog、slowlog、data、index等 MySQL的物理文件层包括以下文件:
- Redo log:用于事务的持久性和故障恢复,确保在发生故障时数据的一致性。
- Undo log:存储撤消日志,支持事务的回滚和多版本并发控制。
- Binlog:二进制日志,用于主从复制和数据恢复。
- 数据文件:存储表的数据和索引,不同存储引擎使用不同的数据文件格式。
- 表定义文件:存储表的元数据信息,包括表结构、字段定义、索引信息等。
- 参数文件:用于配置MySQL服务器的参数和选项。
- 锁文件:记录正在使用的表的锁信息。
- 错误日志文件:记录MySQL服务器的错误和警告信息。
- 查询日志文件:记录MySQL服务器接收到的查询语句。
- 慢查询日志文件:记录执行时间超过阈值的查询语句。
- 临时文件:存储临时数据和排序操作的中间结果。
- 其他日志文件:包括日志文件组合、日志索引文件等。
这些物理文件在MySQL中起着不同的作用,支持数据库的正常运行、故障恢复、备份和数据复制等功能。 需要注意的是,MySQL的物理文件层是存储引擎特定的,不同存储引擎可能使用不同的文件格式和组织方式。因此,具体的文件类型和文件组织方式可能因存储引擎而异。
一条语句的执行过程
结合整体架构,一条语句的执行过程如下所示:
InnoDB架构概述:
整体架构
通过Mysql架构解析我们了解了MySQL架构,下面我们看下Innodb架构。
innodb最早由Innobase Oy公司开发,5.5版本开始是MySQL默认存储引擎,该存储引擎是第一个完整支持ACID事务的MySQL存储引擎(BDB是第一个支持事务的MySQL存储引擎,现在已经停止开发),其特点是行锁设计、支持MVCC、支持外键、提供一致性非锁定读,同时被设计用来最有效地利用以及使用内存和CPU。下面我们详细看下innodb架构:
内存架构
-
Buffer Pool(缓冲池)是InnoDB存储引擎中的一个重要组件,用于高效地缓存数据库中的数据页。它是内存中的一块区域,用于存储从磁盘读取的数据页,以加快数据的访问速度。在专用服务器上,通常将物理内存的最多80%分配给缓冲池。
当InnoDB需要读取数据页时,首先会在缓冲池中查找该页是否已经被缓存。如果该页已经在缓冲池中,InnoDB可以直接从内存中获取数据,避免了磁盘IO的开销,从而提高数据访问的速度。如果该页不在缓冲池中,InnoDB会将其读取到缓冲池中,并进行相应的缓存管理。
Buffer Pool的大小是通过配置参数
innodb_buffer_pool_size
来指定的。较大的缓冲池可以容纳更多的数据页,提供更好的缓存效果,从而减少磁盘IO操作。合理配置缓冲池的大小对于数据库的性能至关重要,它应该根据数据库的大小、可用内存和访问模式来进行调整。Buffer Pool的作用在于:
- 提高数据访问性能:通过缓存数据页,减少磁盘IO,加快数据的读取速度。
- 减少磁盘访问:由于数据页已经在内存中,可以减少频繁的磁盘读取操作,降低IO开销。
- 优化查询性能:对于频繁访问的数据,可以直接从缓冲池中获取,减少查询的响应时间。
-
Change Buffer
-
Change Buffer是一种特殊的数据结构,用于在次要索引页不在缓冲池中时缓存对其进行的更改。这些缓冲的更改可能来自于插入(INSERT)、更新(UPDATE)或删除(DELETE)操作(DML),它们在后续的读操作将这些页加载到缓冲池时被合并。Change Buffer的目的是降低写操作的磁盘IO,提升数据库性能。
-
Log Buffer 当在MySQL中对InnoDB表进行更改时,这些更改首先存储在InnoDB日志缓冲区的内存中(Log Buffer),然后写入通常称为重做日志(redo logs)的InnoDB日志文件中。 日志缓冲区的大小由
innodb_log_buffer_size
变量定义,其默认大小为16MB。日志缓冲区的内容会定期刷新到磁盘。较大的日志缓冲区可以使大型事务在提交之前无需将重做日志数据写入磁盘,从而提供更好的性能。因此,如果存在更新、插入或删除大量行的事务,则增加日志缓冲区的大小可以减少磁盘IO操作。innodb_flush_log_at_trx_commit
变量控制日志缓冲区的内容如何写入和刷新到磁盘。innodb_flush_log_at_timeout
变量控制日志刷新的频率。
磁盘架构
InnoDB存储引擎使用页作为基本单位来管理存储空间,每个页的默认大小为16KB。对于每个索引,InnoDB使用B+树结构,其中每个节点都是一个数据页。数据页之间不必连续存储,而是通过双向链表来维护它们的顺序。
InnoDB的聚簇索引将完整的用户记录存储在叶子节点中,也就是说索引即数据,数据即索引。
为了更好地管理这些页,InnoDB引入了表空间(Tablespace)的概念。表空间是一个抽象的概念,可以对应于一个或多个实际的文件。每个表空间可以被划分为多个页,表的数据存放在特定表空间下的一些页中。 InnoDB将表空间划分为几种不同的类型:
-
系统表空间(System Tablespace):系统表空间可以对应文件系统上一个或多个实际的文件,默认情况下,InnoDB会在数据目录下创建一个名为ibdata1的文件,这个文件就是对应的系统表空间在文件系统上的表示。这个文件是自扩展文件,当不够用的时候它会自己增加文件大小。也可以把系统表空间对应的文件路径不配置到数据目录下,甚至可以配置到单独的磁盘分区上,涉及到的启动参数就是
innodb_data_file_path
和innodb_data_home_dir
。需要注意的一点是,在一个MySQL服务器中,系统表空间只有一份。 -
独立表空间(File-per-table Tablespace):在MySQL5.6.6以及之后的版本中,InnoDB并不会默认的把各个表的数据存储到系统表空间中,而是为每一个表建立一个独立表空间,也就是说我们创建了多少个表,就有多少个独立表空间。使用独立表空间来存储表数据的话,会在该表所属数据库对应的子目录下创建一个表示该独立表空间的文件,文件名和表名相同,只不过添加了一个.ibd的扩展名。我们也可以自己指定使用系统表空间还是独立表空间来存储数据,这个功能由启动参数
innodb_file_per_table
控制。 -
通用表空间(General Tablespace): 通用表空间是MySQL 8中引入的新特性,它允许将多个表存储在一个表空间中。通用表空间可以跨数据库和服务器共享,提供了更高的灵活性和资源利用率。
-
临时表空间(Temporary Tablespaces): 临时表空间用于存储临时表和临时文件。当执行排序、连接和其他需要临时存储的操作时,InnoDB会使用临时表空间来存储相关数据。
此外,InnoDB还使用其他文件和机制来支持数据管理和恢复:
-
双写缓冲文件(Doublewrite Buffer Files): 双写缓冲是一种机制,用于提高数据写入的可靠性。InnoDB将数据页首先写入双写缓冲文件中,然后再将其写入实际的数据文件。这样可以在发生故障时,通过双写缓冲文件恢复数据的一致性。
-
Undo表空间(Undo Tablespaces): 撤消表空间用于存储撤消日志(undo log),用于支持事务的回滚和MVCC(多版本并发控制)。每个事务对数据的修改都会生成相应的撤消日志,这些日志被存储在撤消表空间中。
-
重做日志(Redo Log): 重做日志是用于事务的持久性和故障恢复的重要组件。它记录了事务对数据的修改操作,包括插入、更新和删除。重做日志文件存储在磁盘上,并在事务提交时进行持久化。
这些组件和机制共同构成了InnoDB的磁盘架构,用于管理和存储数据。