MySQL总结(四)——MySQL中sql语句的执行过程
MySQL 基本架构
- 连接器: 身份认证和权限相关(登录 MySQL 的时候)。
- 查询缓存: 执行查询语句的时候,会先查询缓存(MySQL 8.0 版本后移除,因为这个功能不太实用)。
- 分析器: 没有命中缓存的话,SQL 语句就会经过分析器,分析器说白了就是要先看你的 SQL 语句要干嘛,再检查你的 SQL 语句语法是否正确。
- 优化器: 按照 MySQL 认为最优的方案去执行。经过了优化器之后可以说这个语句具体该如何执行就已经定下来。
- 执行器: 当选择了执行方案后,MySQL 就准备开始执行了,首先执行前会校验该用户有没有权限,如果没有权限,就会返回错误信息,如果有权限,就会去调用引擎的接口,返回接口执行的结果。
简单来说 MySQL 主要分为 Server 层和存储引擎层:
- Server 层:主要包括连接器、查询缓存、分析器、优化器、执行器等,所有跨存储引擎的功能都在这一层实现,比如存储过程、触发器、视图,函数等,还有一个通用的日志模块 binglog 日志模块。
- 存储引擎: 主要负责数据的存储和读取,采用可以替换的插件式架构,支持 InnoDB、MyISAM、Memory 等多个存储引擎,其中 InnoDB 引擎有自有的日志模块 redolog 模块。现在最常用的存储引擎是 InnoDB,它从 MySQL 5.5.5 版本开始就被当做默认存储引擎了。
总结:
查询语句的执行流程如下:
权限校验(如果命中缓存)==》查询缓存 ==》分析器 ==》优化器 ==》权限校验 ==》执行器 ==》引擎
更新语句执行流程如下:
分析器 ==》权限校验 ==》执行器 ==》引擎 ==》redo log(prepare 状态 ==》binlog ==》redo log(commit状态)
一条SQL语句执行得很慢的原因
分类讨论
- 偶尔很慢的情况:大多数情况是正常的,只是偶尔会出现很慢的情况。
- 一直都这么慢的情况:在数据量不变的情况下,这条SQL语句一直以来都执行的很慢。
偶尔很慢的情况
首先,这条SQL语句的书写本身是没什么问题的。
一、 数据库在刷新脏页(flush)
当我们要往数据库插入一条数据、或者要更新一条数据的时候,我们知道数据库会在内存中把对应字段的数据更新了,但是更新之后,这些更新的字段并不会马上同步持久化到磁盘中去,而是把这些更新的记录写入到 redo log 日记中去,等到空闲的时候,在通过 redo log 里的日记把最新的数据同步到磁盘中去。
当内存数据页跟磁盘数据页内容不一致的时候,我们称这个内存页为“脏页”。
内存数据写入到磁盘后,内存和磁盘上的数据页的内容就一致了,称为“干净页”。
刷新脏页有下面4种场景:
- redolog写满了:redo log 里的容量是有限的,如果数据库一直很忙,更新又很频繁,这个时候 redo log 很快就会被写满了,这个时候就没办法等到空闲的时候再把数据同步到磁盘的,只能暂停其他操作,全身心来把数据同步到磁盘中去的,而这个时候,就会导致我们平时正常的SQL语句突然执行的很慢,所以说,数据库在在同步数据到磁盘的时候,就有可能导致我们的SQL语句执行的很慢了。
- 内存不够用了:如果一次查询较多的数据,恰好碰到所查数据页不在内存中时,需要申请内存,而此时恰好内存不足的时候就需要淘汰一部分内存数据页,如果是干净页,就直接释放,如果恰好是脏页就需要刷脏页。
- MySQL 认为系统“空闲”的时候:这时系统没什么压力。
- MySQL 正常关闭的时候:这时候,MySQL 会把内存的脏页都 flush 到磁盘上,这样下次 MySQL 启动的时候,就可以直接从磁盘上读数据,启动速度会很快。
二、拿不到锁
要执行的这条语句,刚好这条语句涉及到的表,别人在用,并且加锁了,我们拿不到锁,只能慢慢等待别人释放锁了。或者,表没有加锁,但要使用到的某个一行被加锁了。
一直都这么慢的情况(重要)
如果在数据量一样大的情况下,这条 SQL 语句每次都执行的这么慢,那就就要好好考虑下SQL语句的问题。
假如有一张表:
CREATE TABLE `t` (`id` int(11) NOT NULL,`num` int(11) DEFAULT NULL,`basy` int(11) DEFAULT NULL,PRIMARY KEY (`id`)
) ENGINE=InnoDB;
一、没用索引
- 字段没有索引
select * from t where 100 <num and num < 100000;
num字段上没有索引,所以只能走全表扫描了,这回导致这条查询语句很慢。
- 字段有索引,但却没有用索引查询
假如你给num字段加上了索引。
select * from t where num - 1 = 1000;
这样是不会用到索引查询的,如果我们在字段的左边做了运算,那么很抱歉,在查询的时候,就不会用上索引了,所以,要注意这种字段上有索引,但由于自己的疏忽,导致系统没有使用索引的情况了。
select * from t where pow(num ,2) = 1000;
如果我们在查询的时候,对字段进行了函数操作,也是会导致没有用上索引的。
二、数据库自己选错索引了
select * from t where 100 <num and num < 100000;
当查询这条sql语句时,系统也并不一定会走 num 这个字段上的索引,而是有可能会直接扫描扫描全表,找出所有符合 100<num and num <100000 的数据。
为什么会这样呢?
首先、系统在执行这条语句的时候,会进行预测:究竟是走 c 索引扫描的行数少,还是直接扫描全表扫描的行数少呢?显然,扫描行数越少当然越好了,因为扫描行数越少,意味着I/O操作的次数越少。
如果是扫描全表的话,那么扫描的次数就是这个表的总行数了,假设为 n;而如果走索引 num 的话,我们通过索引 num 找到主键之后,还得再通过主键索引来找我们整行的数据,也就是说,需要走两次索引。而且,我们也不知道符合 100 < num and num < 10000 这个条件的数据有多少行,万一这个表是全部数据都符合呢?这个时候意味着,走num 索引不仅扫描的行数是 n,同时还得每行数据走两次索引。
系统是有可能走全表扫描而不走索引的。那系统是怎么判断呢?
判断来源于系统的预测,也就是说,如果要走 num 字段索引的话,系统会预测走 c 字段索引大概需要扫描多少行。如果预测到要扫描的行数很多,它可能就不走索引而直接扫描全表了。
那么问题来了,系统是怎么预测判断的呢?这里我给你讲下系统是怎么判断的吧,虽然这个时候我已经写到脖子有点酸了。
系统是通过索引的区分度来判断的,一个索引上不同的值越多,意味着出现相同数值的索引越少,意味着索引的区分度越高。我们也把区分度称之为基数,即区分度越高,基数越大。所以呢,基数越大,意味着符合 100 < num and num < 10000 这个条件的行数越少。
所以呢,一个索引的基数越大,意味着走索引查询越有优势。
怎么知道这个索引的基数呢?
系统当然是不会遍历全部来获得一个索引的基数的,代价太大了,索引系统是通过遍历部分数据,也就是通过采样的方式,来预测索引的基数的。
扯了这么多,重点的来了,居然是采样,那就有可能出现失误的情况,也就是说,c 这个索引的基数实际上是很大的,但是采样的时候,却很不幸,把这个索引的基数预测成很小。例如你采样的那一部分数据刚好基数很小,然后就误以为索引的基数很小。然后就呵呵,系统就不走 num 索引了,直接走全部扫描了。
所以呢,说了这么多,得出结论:由于统计的失误,导致系统没有走索引,而是走了全表扫描,而这,也是导致我们 SQL 语句执行的很慢的原因。
解决处理:
我们有时候也可以通过强制走索引的方式来查询:
//可以通过强制走索引的方式
select * from t force index(a) where num < 100 and num < 100000;//来查询索引的基数和实际是否符合,如果和实际很不符合的话,我们可以重新来统计索引的基数
show index from t;//重新统计分析
analyze table t;
既然会预测错索引的基数,这也意味着,当我们的查询语句有多个索引的时候,系统有可能也会选错索引,这也可能是 SQL 执行的很慢的一个原因。
MySQL总结(四)——MySQL中sql语句的执行过程相关推荐
- 执行计划 分析一条sql语句的效率 mysql_MySQL中一条SQL语句的执行过程
MySQL中一条SQL语句的执行过程 发布时间:2018-11-24 18:35, 浏览次数:390 , 标签: MySQL SQL 查询语句的执行顺序: 1.客户端通过TCP连接发送连接请求到mys ...
- oracle+执行变量语句,ORACLE sql 语句的执行过程(SQL性能调整)
第1章 SQL语句处理的过程 在调整之前我们需要了解一些背景知识,只有知道这些背景知识,我们才能更好的去调整sql语句. 本节介绍了SQL语句处理的基本过程,主要包括: · 查询语句处理 · DML语 ...
- mysql pdo 获取最后一条sql_一条sql语句的执行过程-mysql
平时我们使用数据库,看到的通常都是一个整体.比如,你有个最简单的表,表里只有一个 ID 字段,在执行下面这个查询语句时: mysql> select * from T where ID=10: ...
- oracle数据库sql的执行过程,Oracle体系结构之SQL语句的执行过程
一般来说,数据库处理SQL都会经过三个过程:解析(parse).执行(exec).返回结果(fetch) 1.解析 当用户发起一个SQL语句时,Oracle通过Server Process 接收SQL ...
- sql语句的执行过程和优化
一.执行过程 二.优化 1.select查询优化 (1)保证不查询多余的列与行,应尽量避免全表扫描 尽量避免select * 的存在,使用具体的列代替*,避免多余的列. 使用where限定具体要查询的 ...
- SQL语句的执行过程
服务器接收到SQL语句之后,要经过如下步骤完成操作:Parse(解析)-> Bind(绑定)-> Execute(执行). 画个流程图比较明显的表示了这些过程: 下面说明执行的具体细节: ...
- mysql三高讲解(一):1.2 一个sql语句的执行过程
查询缓存: 之前执行过的语句会以KV的形式缓存在内存中.查询先前查找过的内容会快速的返回结果. 不推荐使用缓存:因为数据表修改后,会删除所有相关缓存. 分析器: 优化器: 执行器: 存储引擎:Inno ...
- 逻辑io 物理io oracle,Oracle体系结构之SQL语句的执行过程
命中率: 命中率在Oracle数据库的多个地方都会被提起 例如当一个进程需要访问数据时,首先确定数据是否存在Buffer Cache中,如果存在(称为高速缓存命中),则直接读取数据(逻辑IO/内存读) ...
- 一条SQL语句的执行过程
一:思维导图
最新文章
- 毕业论文中使用的技术—FileReader接口
- win10之dlib安装 c++调用
- Julia程序设计3 数组2 排序、复制、集合运算、字典
- python super 参数问题
- php ldap 创建用户,PHP LDAP获取作为组成员的成员的用户详细信息
- python3遍历选中文件夹下的文件【GUI编程】
- 电机串电阻会有什么影响?
- DS和[address]
- Asterisk权威指南/第六章 拨号计划基础
- 征战云时代,如何捍卫企业数据安全?
- 华农c语言实验1007答案,华农C语言题目及答案(完整版).docx
- mysql 多条记录判断相加减进行计算
- koa2+html模板,Koa2 路由
- 仿QQ聊天软件2.0版
- mq使用replyto队列进行消息回复
- 服务器智能阵列,HPE ProLiant Gen10 服务器智能阵列卡S100i SR Gen10 BIOS下开启阵列功能配置阵列并安装win2016系统...
- 集合类 Java中的集合类解析和一些有深入的面试题
- 根据先序序列与中序序列确定二叉树
- mysql性能优化与高可用_MySQL管理之道:性能调优、高可用与监控》迷你书
- spring oauth2 的error_description本地提示中文,线上提示英文。