Mysql高级之Mysql结构及Sql执行过程分析

1.Mysql结构

整个MySQL 由以下组成:
包括客户端、服务端server、存储引擎

1.1 客户端

navicat,mysql,jdbc,SQLyog等都属于客户端。

1.2 服务端

主要包括连接器、查询缓存、分析器、优化器、执行器等，涵盖 MySQL 的大多数核心服务功能，以及所有的内置函数（如日期、时间、数学和加密函数等），所有跨存储引擎的功能都在这一层实现，比如存储过程、触发器、视图等。

1.2.1 连接器

上面说了mysql有很多的客户端，这些客户端要向mysql发起通信必须跟server端建立连接，这个工作就是连接器来完成的。

-- 可以通过这个命令查看sql的连接
show processlist

1.2.1.1 关于mysql的长连接短连接

1.长连接：是指一个连接建立后，后续客户端持续有请求都是用这个连接

2.短连接：每次执行完很少的几次查询就断开连接
开发中我们大多使用长连接，把长连接放在Pool内进行管理，但是长连接有些时候会导致MySQL占用内存涨的特别快，这是因为MySQL在执行过程中临时使用的内存是管理在长连接对象中的。这些资源会在长连接断开时 才释放，如果长连接积累下来，可能会导致内存占用过大，被系统强行杀掉（OOM），从现象看就是MySQL重启了。

以下是几种可能导致MySQL通过长连接临时占用过多内存的情况：

• 大量并发查询：当多个查询同时发生时，每个查询都可能分配一部分临时内存用于处理数据。如果查询量非常大，这些临时内存累积起来可能导致显著的内存占用。

• 复杂查询：复杂的查询，尤其是涉及大量JOIN操作、子查询或临时表的查询，通常需要更多的临时内存来存储中间结果和计算数据。

• 大数据集处理：处理大量数据时，MySQL可能需要更多的内存来缓存和排序数据。例如，排序操作可能使用排序缓冲区来存储待排序的数据，如果数据量很大，这个缓冲区也会很大。

• 长时间运行的事务：长时间运行的事务可能会累积大量的临时表和查询缓存，这些都会占用内存。

• 连接数过多：虽然长连接有助于减少连接和断开连接的开销，但如果连接数过多，每个连接都可能占用一定的内存，累积起来可能导致内存占用过高。

怎么解决这类问题：

• 如果你用的是 MySQL 5.7 或更新版本，可以在每次执行一个比较大的操作后，通过执行 mysql_reset_connection 来重新初始化连接资源。这个过程不需要重连和重新做权限验证，但是会将连接恢复到刚刚创建完时的状态。

1.2.2 查询缓存

MySQL 拿到一个查询请求后，会先到查询缓存看看，之前是不是执行过这条语句。之前执行过的语句及其结果可能会以 key-value 对的形式，被直接缓存在内存中。key 是查询的语句，value 是查询的结果。如果你的查询能够直接在这个缓存中找到 key，那么这个 value 就会被直接返回给客户端。
如果语句不在查询缓存中，就会继续后面的执行阶段。执行完成后，执行结果会被存入查询缓存中。你可以看到，如果查询命中缓存，MySQL 不需要执行后面的复杂操作，就可以直接返回结果，这个效率会很高。
大多数情况查询缓存就是个鸡肋，为什么呢？
因为查询缓存往往弊大于利。查询缓存的失效非常频繁，只要有对一个表的更新，这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来，还没使用呢，就被一个更新全清空了。对于更新压力大的数据库来说，查询缓存的命中率会非常低。
一般建议大家在静态表里使用查询缓存，什么叫静态表呢？就是一般我们极少更新的表。比如，一个系统配置表、字典表，那这张表上的查询才适合使用查询缓存。好在 MySQL 也提供了这种“按需使用”的方式。你可以将my.cnf参数 query_cache_type 设置成 DEMAND。

1.2.3 词法分析器

如果没有命中查询缓存，就要开始真正执行语句了。首先，MySQL 需要知道你要做什么，因此需要对 SQL 语句做解析。
分析器先会做“词法分析”。你输入的是由多个字符串和空格组成的一条 SQL 语句，MySQL 需要识别出里面的字符串分别是什么，代表什么。
MySQL 从你输入的"select"这个关键字识别出来，这是一个查询语句。它也要把字符串“T”识别成“表名 T”，把字符串“ID”识别成“列 ID”。
做完了这些识别以后，就要做“语法分析”。根据词法分析的结果，语法分析器会根据语法规则，判断你输入的这个 SQL 语句是否满足 MySQL 语法。

1.2.4 优化器

经过了分析器，MySQL 就知道你要做什么了。在开始执行之前，还要先经过优化器的处理。
优化器是在表里面有多个索引的时候，决定使用哪个索引；或者在一个语句有多表关联（join）的时候，决定各个表的连接顺序。

1.2.5 执行器

开始执行的时候，要先判断一下你对这个表 T 有没有执行查询的权限，如果没有，就会返回没有权限的错误
如果有权限，就打开表继续执行。打开表的时候，执行器就会根据表的引擎定义，去使用这个引擎提供的接口。

1.3 存储引擎

存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Memory 等多个存储引擎。现在最常用的存储引擎是 InnoDB，它从 MySQL 5.5.5 版本开始成为了默认存储引擎。也就是说如果我们在create table时不指定表的存储引擎类型,默认会给你设置存储引擎为InnoDB。

可以通过指定 show engines ， 来查询当前数据库支持的存储引擎 ：

创建新表时如果不指定存储引擎，那么系统就会使用默认的存储引擎，MySQL5.5之前的默认存储引擎是MyISAM，5.5之后就改为了InnoDB。

查看Mysql数据库默认的存储引擎 ， 指令 ：

 show variables like '%storage_engine%' ； 

1.3.1 各种存储引擎特性

下面重点介绍几种常用的存储引擎， 并对比各个存储引擎之间的区别， 如下表所示 ：

特点	InnoDB	MyISAM	MEMORY	MERGE	NDB
存储限制	64TB	有	有	没有	有
事务安全	支持
锁机制	行锁(适合高并发)	表锁	表锁	表锁	行锁
B树索引	支持	支持	支持	支持	支持
哈希索引			支持
全文索引	支持(5.6版本之后)	支持
集群索引	支持
数据索引	支持		支持		支持
索引缓存	支持	支持	支持	支持	支持
数据可压缩		支持
空间使用	高	低	N/A	低	低
内存使用	高	低	中等	低	高
批量插入速度	低	高	高	高	高
支持外键	支持

下面我们将重点介绍最长使用的两种存储引擎： InnoDB、MyISAM 。

1.3.2 InnoDB

​ InnoDB存储引擎是Mysql的默认存储引擎。InnoDB存储引擎提供了具有提交、回滚、崩溃恢复能力的事务安全。但是对比MyISAM的存储引擎，InnoDB写的处理效率差一些，并且会占用更多的磁盘空间以保留数据和索引。

InnoDB存储引擎不同于其他存储引擎的特点 ：

事务控制

create table goods_innodb(
	id int NOT NULL AUTO_INCREMENT,
	name varchar(20) NOT NULL,
    primary key(id)
)ENGINE=innodb DEFAULT CHARSET=utf8;

start transaction;

insert into goods_innodb(id,name)values(null,'Meta20');

commit;

测试，发现在InnoDB中是存在事务的 ；

外键约束

​ MySQL支持外键的存储引擎只有InnoDB ， 在创建外键的时候， 要求父表必须有对应的索引 ， 子表在创建外键的时候， 也会自动的创建对应的索引(实际项目中并不推荐创建外键，所以这里不做详细说明)。

存储方式
InnoDB定义的表在磁盘上存储成2个文件

• .frm (存储表定义)； .ibd(InnoDB Data , 存储数据;InnoDB Index 存储索引)；
• 索引和数据存储在一个文件

1.3.3 MyISAM

​ MyISAM 不支持事务、也不支持外键，其优势是访问的速度快，对事务的完整性没有要求或者以SELECT、INSERT为主的应用基本上都可以使用这个引擎来创建表 。有以下两个比较重要的特点：

不支持事务

create table goods_myisam(
	id int NOT NULL AUTO_INCREMENT,
	name varchar(20) NOT NULL,
    primary key(id)
)ENGINE=myisam DEFAULT CHARSET=utf8;

文件存储方式

每个MyISAM在磁盘上存储成3个文件，其文件名都和表名相同，但拓展名分别是 ：

• .frm (存储表定义)；

• .MYD(MYData , 存储数据)；

• .MYI(MYIndex , 存储索引)；

1.3.4 存储引擎的选择

​ 在选择存储引擎时，应该根据应用系统的特点选择合适的存储引擎。对于复杂的应用系统，还可以根据实际情况选择多种存储引擎进行组合。以下是几种常用的存储引擎的使用环境。

• InnoDB : 是Mysql的默认存储引擎，用于事务处理应用程序，支持外键。如果应用对事务的完整性有比较高的要求，在并发条件下要求数据的一致性，数据操作除了插入和查询意外，还包含很多的更新、删除操作，那么InnoDB存储引擎是比较合适的选择。InnoDB存储引擎除了有效的降低由于删除和更新导致的锁定， 还可以确保事务的完整提交和回滚，对于类似于计费系统或者财务系统等对数据准确性要求比较高的系统，InnoDB是最合适的选择。
• MyISAM ： 如果应用是以读操作和插入操作为主，只有很少的更新和删除操作，并且对事务的完整性、并发性要求不是很高，那么选择这个存储引擎是非常合适的。
• MEMORY：将所有数据保存在RAM中，在需要快速定位记录和其他类似数据环境下，可以提供几块的访问。MEMORY的缺陷就是对表的大小有限制，太大的表无法缓存在内存中，其次是要确保表的数据可以恢复，数据库异常终止后表中的数据是可以恢复的。MEMORY表通常用于更新不太频繁的小表，用以快速得到访问结果。
• MERGE：用于将一系列等同的MyISAM表以逻辑方式组合在一起，并作为一个对象引用他们。MERGE表的优点在于可以突破对单个MyISAM表的大小限制，并且通过将不同的表分布在多个磁盘上，可以有效的改善MERGE表的访问效率。这对于存储诸如数据仓储等VLDB环境十分合适。

2.Sql执行过程分析

sql的执行过程（使用update语句做示例）：
1.开启一个事务
2.执行一个更新操作
3.先从磁盘文件加载对应的数据到Buffer Pool
4.将旧值写入到undo日志中（事务的回滚会使用）
5.更新Buffer Pool的值
6.写redo log(保证事务的一致性，已提交的事务必然存在redo log,那怕发生系统宕机，也可以使用redo log恢复磁盘ibd文件数据)
7.返回客户端更新结果
8.提交事务
9.写bin log日志文件（主从同步，数据丢失时恢复数据）
10.返回客户端事务提交成功