目录
学习SQL的时候,查询数据的时候简单的用到就是下面的这SQL语句:
select * from tbl_1 where id = 100;
有没有想过,MYSQL执行一条select查询语句,在MYSQL中期间发生了什么?
带着这个问题,我们可以很好的理解MYSQL内部的架构,下面我们具体看看内部的流程。
下面就是 MySQL 执行一条 SQL 查询语句的流程,也从图中可以看到 MySQL 内部架构里的各个功能模块

MySQL 的架构共分为两层:Server 层和存储引擎层
如果你要使用MySQL,那么第一步是要先连接数据库服务,然后才能才能执行SQL语句。
mysql -h$ip -u$user -P$port -p$password
连接的过程需要先经过TCP三次握手,因为MySQL是基于TCP协议进行传输。
如何查看MySQL服务当前有多少个客户端连接?
可以执行执行下面的SQL命令进行查看
show processlist

上图结果:有两个用户名为root的用户连接了MYSQL服务,其中id为42的用户的Command状态为Sleep,这意味着该用户连接完MSQL服务就没有执行过任何命令,也就是个空闲的连接,空闲时长是81秒
空闲连接会一直占用吗?
不会,MySQL定义了空闲连接的最大空闲时长,由wait_timeout参数控制,默认值是28800秒(8小时),如果空闲连接超过了这个时间,连接器就会自动将它断开。

当然,我们也可以手动断开空闲连接,使用kill connection + id 命令

一个处于空闲状态的连接被服务端主动断开后,这个客户端并不会马上知道,等到客户端再发起下一个请求的时候,才会收到"Lost connection"

MySQL的连接数有限制吗?
MySQL服务支持的最大连接数由max_connections参数控制。默认值是151个,超过这个值,系统就会拒绝接下来的连接请求,并提示报错“Too many connections”。

MySQL的连接也有长连接和短连接的概念,区别如下:
- // 短连接
- 连接 mysql 服务 (TCP 三次握手)
- 执行sql
- 断开 mysql 服务 (TCP 四次挥手)
-
- // 长连接
- 连接 mysql 服务 (TCP 三次握手)
- 执行sql
- 执行sql
- 执行sql
- ...
- 断开 mysql 服务 (TCP 四次挥手)
可以发现,使用长连接的好处就是可以减少建立连接和断开连接的过程,所以一般推荐使用长连接。
但是长连接后可能会占用内存增多,因为MySQL执行查询过程中临时使用内存管理连接对象,这些连接对象资源只有在连接断开时才会释放。如果长连接累计很多,将导致MySQL服务占用内存太大,有可能会被系统强制杀掉,这样会发生MySQL服务异常重启的现象。
怎么解决长连接占用内存的问题?
两种解决方式:
数据库连接池简单的实现方式:
GitHub - maokeyang/SimpleDataSourcePool
至此,连接器的工作做完了,简单的总结一下:
连接器的工作完成以后,客户端可以向MySQL服务发送SQL语句,服务端收到SQL语句后,就会解析SQL语句第一个字段,分析是什么类型的语句
如果SQL语句是查询select语句,MySQL就会先去缓存里查询找数据,看看之前有没有执行过这一条命令。这个缓存是以key-value方式保存在内存中,key为SQL查询语句,value是SQL语句的查询结果。
其实缓存比较鸡肋。
对于更新比较频繁的表,查询缓存的命中率很低。因为只要表有一个更新操作,那么这个表的查询缓存就会被清空。如果刚缓存了一个查询结果很大的数据,还没被使用的时候,刚好这个表触发了更新操作,那么查询缓存就会被清空,相当于干了个寂寞。所以MySQL8.0版本中直接将查询缓存删掉了,也就是说从8.0版本开始,执行一条SQL查询语句,不会再走查询缓存这个阶段了。
执行SQL之前,MySQL会先对SQL语句解析,这个工作交给「解析器」来处理
第一步:词法分析
| 关键字 | 非关键字 | 关键字 | 非关键字 |
| select | name | from | tbl_1 |
第二步:语法分析

如果我们输入的 SQL 语句语法不对,就会在解析器这个阶段报错。比如,我下面这条查询语句,把 from 写成了 form,这时 MySQL 解析器就会给报错。

经过解析器后,接着就要进入执行SQL查询语句的流程,每条select查询语句流程主要可以分为下面三个阶段
预处理都做了什么事情呢?
经过预处理阶段后,还需要为SQL查询语句先制定一个执行计划,这个工作是由「优化器」完成的。
优化器主要负责将SQL查询语句的执行方案确定下来,比如表里面有多个索引的时候,优化器会基于查询成本的考虑,来决定选择使用哪个索引
经历完优化器后,就确定了执行方案,接下来就真正开始执行语句了 ,这个工作是由「执行器」完成的。在执行的过程中,执行器就会和存储引擎交互了,交互是以记录为单位的。
以下以三种方式描述执行过程
索引下推是MySQL5.6推出的查询优化策略,索引下推能够减少二级索引在查询时的回表操作,提高查询的效率,因为它将Server层部分负责的事情,交给存储引擎层去处理了。
下面以一个例子说明:
- CREATE TABLE `tbl_score` (
- `id` bigint NOT NULL AUTO_INCREMENT,
- `name` varchar(30) NOT NULL comment '名字',
- `age` int NOT NULL comment '年龄',
- `score` int NOT NULL comment '分数',
- PRIMARY KEY (`id`),
- KEY `index_age_score` (`age`,`score`) USING BTREE
- ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
下面这条查询语句:
select * from tbl_score where age < 18 and score = 80;
联合索引当遇到范围查询就会停止匹配,也就是age字段能用到联合索引,但是score字段则无法利用到索引。
无索引下推(5.6版本之前)时,执行器与存储引擎的执行流程会如下:
可以看到,没有索引下推的时候,每查询到一条二级索引记录,都要进行回表操作,然后将记录返回给 Server,接着 Server 再判断该记录的 score 是否等于80。
使用索引下推时,执行器与存储引擎的执行流程:
可以看到,使用了索引下推后,虽然 score 列无法使用到联合索引,但是因为它包含在联合索引(age,score)里,所以直接在存储引擎过滤出满足 score = 80 的记录后,才去执行回表操作获取整个记录。相比于没有使用索引下推,节省了很多回表操作。
如果发现执行计划里的 Extr 部分显示了 “Using index condition”,说明使用了索引下推。
