Mysql架构演变
- 单机架构
- 主从架构
- 分库分表
- 云数据库
体系架构
- 网络连接层
- 服务层
- 连接池:负责存储和管理客户端与数据库的连接,一个线程负责管理一个连接。
- 系统管理喝控制工具 : 例如备份恢复、安全管理、集群管理等
- Sql接口:用于接受客户端发送的各种SQL命令,并且返回用户需要查询的结果。比如DML、DDL、存储过程、视图、触发器等。
- 解析器:负责将请求的SQL解析生成一个"解析树"。然后根据一些MySQL规则进一步检查解析树是否合法。
- 查询优化器:当“解析树”通过解析器语法检查后,将交由优化器将其转化成执行计划,然后与存储引擎交互。
- 缓存:缓存机制是由一系列小缓存组成的。比如表缓存,记录缓存,权限缓存,引擎缓存等。如果查询缓存有命中的查询结果,查询语句就可以直接去查询缓存中取数据。
- 存储引擎层: 存储引擎负责MySQL中数据的存储与提取,与底层系统文件进行交互MySQL存储引擎是插件式的,服务器中的查询执行引擎通过接口与存储引擎进行通信,接口屏蔽了不同存储引擎之间的差异 。现在有很多种存储引擎,各有各的特点,最常见的是MyISAM和InnoDB。
- 系统文件层:该层负责将数据库的数据和日志存储在文件系统之上,并完成与存储引擎的交互,是文件的物理存储层。主要包含日志文件,数据文件,配置文件,pid 文件,socket 文件等。
- 日志文件
-
错误日志:
show variables like '%log_error%'
-
通用查询日志:
show variables like '%general%';
-
二进制日志:记录了对MySQL数据库执行的更改操作,并且记录了语句的发生时间、执行时长;但是它不记录select、show等不修改数据库的SQL。主要用于数据库恢复和主从复制。
show variables like '%log_bin%'; //是否开启
show variables like '%binlog%'; //参数查看
show binary logs;//查看日志文件 -
慢查询日志: 记录所有执行时间超时的查询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运行机制
- 建立连接:通过客户端/服务器通信协议与MySQL建立连接。MySQL 客户端与服务端的通信方式是 “ 半双工 ”。对于每一个 MySQL 的连接,时刻都有一个线程状态来标识这个连接正在做什么。
通信机制:全双工: 同时发送接收数据 (打电话)
半双工:指的某一时刻,要么发送数据,要么接收数据,不能同时。例如早期对讲机
-
单双工:只能发送数据或只能接收数据。例如单行道
线程状态://查看用户正在运行的线程信息,root用户能查看所有线程,其他用户只能看自己的
show full processlist;
- id: 线程Id 可以使用 kill id
- user: 启动这个线程的用户
- host:发送请求的ip和端口
- db: 当前线程咋哪个库执行
- Command: 当前线程正在执行的操作命令
- create db: 正在创建库操作
- drop db: 正在删除库操作
- Execute: 正在执行一个 prepared statement
- Close stmt:正在关闭一个PreparedStatement
- sleep:正在等待客户端发送语句
- quit:正在退出
- shutdown: 正在关闭服务器
- time:线程处于当前状态的时间 单位秒
- state: 线程状态
- Updating:正在搜索匹配记录,进行修改
- Sleeping:正在等待客户端发送新请求
- Starting:正在执行请求处理
- Checking table:正在检查数据表
- Closing table : 正在将表中数据刷新到磁盘中
- Locked:被其他查询锁住了记录
- Sending Data:正在处理Select查询,同时将结果发送给客户端
- info: 线程正在执行的语句
- 查询缓存:这是MySQL的一个可优化查询的地方,如果开启了查询缓存且在查询缓存过程中查询到完全相同的SQL语句,则将查询结果直接返回给客户端;如果没有开启查询缓存或者没有查询到完全相同的 SQL 语句则会由解析器进行语法语义解析,并生成“解析树”
- 缓存Select查询的结果和SQL语句
- 执行Select查询时,先查询缓存,判断是否存在可用的记录集,要求是否完全相同(包括参数值),这样才会匹配缓存数据命中。
- 即使开启查询缓存,以下SQL也不能缓存
- 查询语句使用SQL_NO_CACHE
- 查询的结果大于query_cache_limit设置
- 查询中有一些不确定的参数,比如now()
- show variables like '%query_cache%'; //查看查询缓存是否启用,空间大小,限制等
- show status like 'Qcache%'; //查看更详细的缓存参数,可用缓存空间,缓存块,缓存多少等
- 解析器(Parser):将客户端发送的SQL进行语法解析,生成"解析树"。预处理器根据一些MySQL规则进一步检查“解析树”是否合法,例如这里将检查数据表和数据列是否存在,还会解析名字和别
名,看看它们是否有歧义,最后生成新的“解析树” - 查询优化器(Optimizer)根据“解析树”生成最优的执行计划。MySQL使用很多优化策略生成最优的执行计划,可以分为两类:静态优化(编译时优化)、动态优化(运行时优化)。
- 等价变换策略
- 5=5 and a>5 改成 a > 5
- a < b and a=5 改成b>5 and a=5
- 基于联合索引,调整条件位置等
- 优化count、min、max等函数
1. InnoDB引擎min函数只需要找索引最左边
2. InnoDB引擎max函数只需要找索引最右边
3. MyISAM引擎count(*),不需要计算,直接返回 - 提前终止查询
1. 使用了limit查询,获取limit所需的数据,就不在继续遍历后面数据 - in的优化
1. MySQL对in查询,会先进行排序,再采用二分法查找数据。比如where id in (2,1,3),变成 in (1,2,3)
- 等价变换策略
- 查询执行引擎:查询执行引擎负责执行 SQL 语句,此时查询执行引擎会根据 SQL 语句中表的存储引擎类型,以及对应的API接口与底层存储引擎缓存或者物理文件的交互,得到查询结果并返回给客户端。若开启用查询缓存,这时会将SQL 语句和结果完整地保存到查询缓存(Cache&Buffer)中,以后若有相同的 SQL 语句执行则直接返回结果。
- 如果开启了查询缓存,先将查询结果做缓存操作
- 返回结果过多,采用增量模式返回
Mysql存储引擎
show engines // 查看当前数据库支持引擎
- InnoDB:支持事务,具有提交,回滚和崩溃恢复能力,事务安全
- MyISAM:不支持事务和外键,访问速度快
- Memory:利用内存创建表,访问速度非常快,因为数据在内存,而且默认使用Hash索引,但是一旦关闭,数据就会丢失
- Archive:归档类型引擎,仅能支持insert和select语句
- Csv:以CSV文件进行数据存储,由于文件限制,所有列必须强制指定not null,另外CSV引擎也不支持索引和分区,适合做数据交换的中间表
- BlackHole: 黑洞,只进不出,进来消失,所有插入数据都不会保存
- Federated:可以访问远端MySQL数据库中的表。一个本地表,不保存数据,访问远程表内容。
- MRG_MyISAM:一组MyISAM表的组合,这些MyISAM表必须结构相同,Merge表本身没有数据,对Merge操作可以对一组MyISAM表进行操作。
Innodb 和 MyISAM 的区别 (*)
- 事务与外键
- Innodb支持事务和外键,具有安全性与完整性,适合大量的插入与更新操作
- myisam不支持事务和外键,它提供高速检索,适合大量的查询操作
- 锁的机制
- Innodb支持行级锁,锁定指定记录,基于索引加锁实现
- myisam支持表级锁,锁定的是整张表
- 索引结构
- Innodb使用聚集索引 ,将索引与表存储在一起
- myisam使用非聚集索引, 索引与表分开存储
- 并发处理能力
- InnoDB读写阻塞可以与隔离级别有关,可以采用多版本并发控(MVCC)来支持高并发
- MyISAM使用表锁,会导致写操作并发率低,读之间并不阻塞,读写阻塞。
- 存储文件
- Innodb表对应两个文件,一个.frm表结构文件,一个.ibd数据文件。InnoDB表最大支持64TB;
- MyISAM表对应三个文件,一个.frm表结构文件,一个MYD表数据文件,一个.MYI索引文件。从MySQL5.0开始默认限制是256TB。
适用场景
-
MyISAM
不需要事务支持(不支持) 并发相对较低(锁定机制问题) 数据修改相对较少,以读为主 数据一致性要求不高
-
Innodb
需要事务支持(具有较好的事务特性) 行级锁定对高并发有很好的适应能力 数据更新较为频繁的场景 数据一致性要求较高 硬件设备内存较大,可以利用InnoDB较好的缓存能力来提高内存利用率,减少磁盘IO
-
如何选择
是否需要事务?有,InnoDB 是否存在并发修改?有,InnoDB 是否追求快速查询,且数据修改少?是,MyISAM 在绝大多数情况下,推荐使用InnoDB
Innodb存储结构
1. Innodb内存结构
Innodb的内存结构主要包括 Buffer Pool、Channel Buffer、Adapter Hash Index、Log Buffer 四大组件。
-
Buffer Pool (BP):缓冲池。以page页为单位,默认大小16k, 底层采用链表结构管理page。在Innodb中访问表记录和索引时会在page中缓存,以后使用可以减少磁盘IO,提升效率。
- Page的管理机制
可以分为三种状态:
1. free page:空闲状态
2. clean page:被使用的page,没有被修改
3. dirty page: 脏页,数据被修改过,页中数据与磁盘不一致
针对三种状态,Innodb使用三种链表维护处理
1. free list:空闲缓冲区
2. flush list: 处理 dirty page ,按照修改时间排序,脏页即中flush list中也在lru list中,俩个list互不干扰。 flush list负责脏页的刷盘动作, LRU负责管理可用性与释放
3. lru list:表示正在使用的缓冲区,管理clean page和dirty page,缓冲区以midpoint为基点,前面链表称为new列表区,存放经常访问的数据,占63%;后面的链表称为old列表区,存放使用较少数据,占37%。 - LUR算法
- 普通LRU:末尾淘汰法,新数据从链表头部加入,释放空间时从末尾淘汰
- 改性LRU: 链表分为new和old两个部分,加入元素时并不是从表头插入,而是从中间midpoint位置插入,如果数据很快被访问,那么page就会向new列表头部移动,如果数据没有被访问,会逐步向old尾部移动,等待淘汰。
每当有新的page数据读取到buffer pool时,InnoDb引擎会判断是否有空闲页,是否足够,如果有就将free page从free list列表删除,放入到LRU列表中。没有空闲页,就会根据LRU算法淘汰LRU链表默认的页,将内存空间释放分配给新的页。
- Buffer Pool配置参数
-- 查看page页大小 默认 16 k show variables like '%innodb_page_size%'; -- 查看lru list中old列表参数 show variables like '%innodb_old%'; -- 查看 buffer pool参数 show VARIABLES like '%innodb_buffer%';
- Page的管理机制
建议:将innodb_buffer_pool_size设置为总内存大小的60%-80%,innodb_buffer_pool_instances可以设置为多个,这样可以避免缓存争夺。
- Change Buffer (CB) :写缓冲区,进行DML操作时,如果BP中没有页数据,并不会立即将磁盘页加载到缓冲池,而是这CB中记录变更,等未来数据被读取时再将数据合并变更到BP中。
Change Buffer 占用的是Buffer pool的空间 默认占用25% 最大占用 50%,可以根据系统读写到业务量进行调整 innodb_channge_buffer_max_size;
当更新一条记录时,该记录在BufferPool存在,直接在BufferPool修改,一次内存操作。如果该记录在BufferPool不存在(没有命中),会直接在ChangeBuffer进行一次内存操作,不用再去磁盘查询数据,避免一次磁盘IO。当下次查询记录时,会先进性磁盘读取,然后再从ChangeBuffer中读取信息合并,最终载入BufferPool中。
写缓冲区,仅适用于非唯一普通索引页,为什么?
如果在索引设置唯一性,在进行修改时,InnoDB必须要做唯一性校验,因此必须查询磁盘,做一次IO操作。会直接将记录查询到BufferPool中,然后在缓冲池修改,不会在ChangeBuffer操作。
Adapter Hash Index ::自适应哈希索引,用于优化对BP数据的查询。InnoDB存储引擎会监控对表索引的查找,如果观察到建立哈希索引可以带来速度的提升,则建立哈希索引,所以称之为自适应。InnoDB存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引。
Log Buffer:日志缓冲区,用来保存要写入磁盘上log文件(Redo/Undo)的数据,日志缓冲区的内容定期刷新到磁盘log文件中。日志缓冲区满时会自动将其刷新到磁盘,当遇到BLOB或多行更新的大事务操作时,增加日志缓冲区可以节省磁盘I/O。
LogBuffer主要是用于记录InnoDB引擎日志,在DML操作时会产生Redo和Undo日志。
LogBuffer空间满了,会自动写入磁盘。可以通过将innodb_log_buffer_size参数调大,减少磁盘IO频率
show variable like '%innodb_flush_log%'
innodb_flush_log_at_trx_commit参数控制日志刷新行为,默认为1
- 0 : 每隔1秒写日志文件和刷盘操作(写日志文件LogBuffer-->OS cache,刷盘OScache-->磁盘文件),最多丢失1秒数据
- 1:事务提交,立刻写日志文件和刷盘,数据不丢失,但是会频繁IO操作
- 2:事务提交,立刻写日志文件,每隔1秒钟进行刷盘操作
2. 磁盘结构
InnoDB磁盘主要包含Tablespaces,InnoDB Data Dictionary,Doublewrite Buffer、Redo Log和Undo Logs。
- 系统表空间(The System Tablespace): 包含InnoDB数据字典,Doublewrite Buffer,Change Buffer,Undo Logs的存储区域。系统表空间也默认包含任何用户在系统表空间创建的表数据和索引数据。系统表空
间是一个共享的表空间因为它是被多个表共享的。该空间的数据文件通过参数innodb_data_file_path控制,默认值是ibdata1:12M:autoextend(文件名为ibdata1、12MB、自动扩展)。 - 独立表空间(File-Per-Table Tablespaces):默认开启,独立表空间是一个单表表空间,该表创建于自己的数据文件中,而非创建于系统表空间中。当innodb_file_per_table选项开启时,表将被创建于表空间中。否则,innodb将被创建于系统表空间中。每个表文件表空间由一个.ibd数据文件代表,该文件默认被创建于数据库目录中。表空间的表文件支持动态(dynamic)和压缩(commpressed)行格式。
- 通用表空间(General Tablespaces):通用表空间为通过create tablespace语法创建的共享表空间。通用表空间可以创建于mysql数据目录外的其他表空间,其可以容纳多张表,且其支持所有的行格式。
CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd Engine=InnoDB; //创建表空间ts1
CREATE TABLE t1 (c1 INT PRIMARY KEY) TABLESPACE ts1; //将表添加到ts1表空间
- 撤销表空间(Undo Tablespaces):撤销表空间由一个或多个包含Undo日志文件组成。在MySQL 5.7版本之前Undo占用的是System Tablespace共享区,从5.7开始将Undo从System Tablespace分离了出来。InnoDB使用的undo表空间由innodb_undo_tablespaces配置选项控制,默认为0。参数值为0表示使用系统表空间ibdata1;大于0表示使用undo表空间undo_001、undo_002等。
- 临时表空间(Temporary Tablespaces):分为session temporary tablespaces 和global temporary tablespace两种。sessiontemporary tablespaces 存储的是用户创建的临时表和磁盘内部的临时表。global
temporary tablespace储存用户临时表的回滚段(rollback segments )。mysql服务器正常关闭或异常终止时,临时表空间将被移除,每次启动时会被重新创建。 - 数据字典(InnoDB Data Dictionary):InnoDB数据字典由内部系统表组成,这些表包含用于查找表、索引和表字段等对象的元数据。元数据物理上位于InnoDB系统表空间中。由于历史原因,数据字典元数据在一定程度上与InnoDB表元数据文件(.frm文件)中存储的信息重叠。
- 双写缓冲区(Doublewrite Buffer): 位于系统表空间,是一个存储区域。在BufferPage的page页刷新到磁盘真正的位置前,会先将数据存在Doublewrite 缓冲区。如果在page页写入过程中出现操作系统、存储子系统或mysqld进程崩溃,InnoDB可以在崩溃恢复期间从Doublewrite 缓冲区中找到页面的备份。在大多数情况下,默认情况下启用双写缓冲区,要禁用Doublewrite 缓冲区,可以将innodb_doublewrite设置为0。使用Doublewrite 缓冲区时建议将innodb_flush_method设置为O_DIRECT。
MySQL的innodb_flush_method这个参数控制着innodb数据文件及redo log的打开、刷写模式。有三个值:fdatasync(默认),O_DSYNC,O_DIRECT。设置O_DIRECT表示数据文件写入操作会通知操作系统不要缓存数据,也不要用预读,直接从InnodbBuffer写到磁盘文件。
默认的fdatasync意思是先写入操作系统缓存,然后再调用fsync()函数去异步刷数据文件与redo log的缓存信息。
- 重做日志(Redo Log):重做日志是一种基于磁盘的数据结构,用于在崩溃恢复期间更正不完整事务写入的数据。MySQL以循环方式写入重做日志文件,记录InnoDB中所有对Buffer Pool修改的日志。当出现实例故障(像断电),导致数据未能更新到数据文件,则数据库重启时须redo,重新把数
据更新到数据文件。读写事务在执行的过程中,都会不断的产生redo log。默认情况下,重做日志在磁盘上由两个名为ib_logfile0和ib_logfile1的文件物理表示。 - 撤销日志(Undo Logs):撤消日志是在事务开始之前保存的被修改数据的备份,用于例外情况时回滚事务。撤消日志属于逻辑日志,根据每行记录进行记录。撤消日志存在于系统表空间、撤消表空间和临时表空间中。
3. InnoDB线程模型
- IO Thread:在InnoDB中使用了大量的AIO来做读写处理,极大的提升了数据库的性能。在Innodb1.0之后共有4个IO Thread。
1. write Thread 共4个:负责写操作,将缓存脏页刷新到磁盘。
2. Read Thread 共4个:负责读取操作,将数据从磁盘加载到缓存page页。
3. log Thread 共1个: 负责将日志缓冲区内容刷新到磁盘。
4. insert buffer thread 共1个: 负责将写缓冲内容刷新到磁盘。(Change Buffer) - Purge Thread :事务提交后清除已经分配的undo页
show variables like '%innodb_purge_threads%'; 查看分配清除分配线程
- Page Cleaner Thread :将脏页刷到磁盘,覆盖对应的redo log,同步数据 (redo Log 循环使用)。其调用 write Thread 处理
show variables like '%innodb_page_cleaners%';
- Master Thread : Innodb的主线程,负责调度其他线程。作用是将缓冲池中的数
据异步刷新到磁盘 ,保证数据的一致性。包含:脏页的刷新(page cleaner thread)、undo页回收(purge thread)、redo日志刷新(log thread)、合并写缓冲等。内部有两个主处理,分别是每隔1秒和10秒处理。
每隔1秒:
1. 刷新日志缓冲区,刷到磁盘
2. 合并写缓冲区数据,根据IO读写压力来决定是否操作 (Change Buffer)
3. 刷新脏页数据到磁盘,根据脏页比例达到75%才操作
>innodb_max_dirty_pages_pct
innodb_io_capacity
每隔10秒:
1. 刷新脏页数据到磁盘
2. 合并写缓冲区数据
3. 刷新日志缓冲区
4. 删除无用的undo页