MySQL我们可能是使用得最多的数据库了,但你知道你编写的SQL语句是怎么样执行的吗?这篇文章通俗易懂地告诉你! 一条查询SQL执行流程图如下 本文改编自《高性能Mysql》,烟哥用小说的形式来讲这个内容。序章 自我介绍我是一条sql,就是一条长长的字符串,不要问我长什么样,因为我比较傲娇。 额~~不是我不说啊,因为细说起来,我可以细分为DML (Update、Insert、Delete),DDL (表结构修改),DCL (权限操作),DQL (Select)操作,一个个去介绍,我怕大家嫌我烦! 嗯,大家没什么意见,我继续往下自我介绍了~ 由于种类太多,这里我只是一条查询SQL,也就是一句DQL。 客户端按照Mysql通信协议,把我发送到服务端。 当我到达服务端后,我会在一个单独的 线程里进行执行。服务端要先…万万没想到,我又被打断了~好吧,因为我在一个线程里执行,总要有办法能看到线程的执行状态吧。Mysql提供了下面的命令,给大家查看 SHOW [FULL] PROCESSLIST 出来的结果是长下面这样的 图里Command 这一列,反应的就是这个线程当前的执行状态啦。我在这个线程的执行过程中,状态是会变化很多次。 你看图里,有一个 Sleep ,这是在告诉你线程正在等待客户端发送新的请求。还有一个为Query ,这代表线程正在执行查询或者正在将结果发送给客户端。 至于其他的,还有 Locked 、Sending data 等等,分别代表…额,好吧,唠唠叨叨了一大堆,大家居然木有嫌我烦,嗯,至于其他状态的含义大家可以去Mysql官网查询哦。 嗯,回到刚才的话题。我到达服务端后,Mysql要判断我的前6个字符是否为select。并且,语句中不带有 SQL_NO_CACHE 关键字,如果符合条件,就进入查询缓存。第一章 我和查询缓存的那些事说到查询缓存,它其实是一个哈希表,它将执行过的语句及其结果会以 key-value 对的形式,被直接缓存在内存中。 当然,如果我要绕过查询缓存,也很简单。我可以像下面这么写: Select SQL_NO_CACHE * from table 也可以将参数query_cache_type 设置成DEMAND 来绕过查询缓存。可是,有一天查询缓存悲伤的对我说:'你将来再也看不到我了,我已经被历史淘汰了,Mysql8.0版本开始就没有我了!'
因此,我能想到用查询缓存的表,只有一种情况,那就是配置表。其他的业务表,根本是无法利用查询缓存的特性,或许Mysql团队也是觉得查询缓存的使用场景过于局限,就无情的将它剔除。 第二章 我和分析器的爱恨情仇(本文将解析器和预处理器统一称为分析器) select username from userinfo 解析器:'好,好,好。我有两个阶段,我先对你进行词法分析,我将你从左到右一个字符、一个字符地输入,然后根据构词规则识别单词。你将会生成4个Token,如下所示。' 解析器:'接下来呢,进行语法解析,判断你输入的这个 SQL 语句是否满足 MySQL 语法。然后生成下面这样一颗语法树。' 我:'如果语法不对呢?'解析器:'那你会收到一个提示如下!' You have an error in your SQL syntax 解析器:'顺利生成语法树以后,我就将你送往预处理器!' Unknown column xxx in ‘where clause’ 预处理器:'最后我再给你送去做权限验证,如果你没有操作这个表的权限,会报下面这个错误!' ERROR 1142 (42000): SELECT command denied to user 'root'@'localhost' for table 'xxx' (这个地方,大家可能有疑问,因为有些文章说是执行器做的权限验证,可以直接拉到本文底部看说明) 最后,这颗语法树会传递给优化器。 第三章 我和优化器的动人过往在告别了解析器后,我进入了优化器。 select t1.* 优化器大哥:'我的任务就是帮你判断一下怎么样执行更快,比如先查Table1 再查Table2 ,还是先查Table2 再查Table1 呢?判断完如何执行以后,生成执行计划就好啦!' 我很不信任的说道:“哼,你就不会判断失误么!” 优化器大哥:'那就要对SQL进行改写啦,比如你带了 STRAIGHT_JOIN 关键字,长下面这样'select t1.* '那我就知道强制先找Table1 再关联找Table2 啦,类似的例子还有很多,我就不一一列举了!' ( STRAIGHT_JOIN 功能同join类似,但能让左边的表来驱动右边的表,能改表优化器对于联表查询的执行顺序。)我说道:'哇塞,如何编写一个高效的SQL,真是一门学问啊!' 第四章 我和执行器的悲情经历我:'执行器大哥,你是用来做什么的?'执行器:'就是根据执行计划来进行执行查询啦。我就根据你的指令,逐条调用底层存储引擎,逐步执行。' MySQL 定义了一系列抽象存储引擎API,以支持插件式存储引擎架构。Mysql实现了一个抽象接口层,叫做handler(sql/handler.h) ,其中定义了接口函数,比如:,,ha_create 等等,存储引擎需要实现这些接口才能被系统使用。末章 一些感慨最后一个阶段,Mysql会将查询结果返回客户端。 一些疑问这里关于权限验证究竟在哪个阶段执行,大家可能会有一些疑问。 论点一:权限验证在执行器中判断从逻辑上说不通一条查询SQL经过查询缓存、分析器、优化器,执行器。如果到最后一个阶段执行器中才发现权限不足、那不是前面一系列流程白做了,Mysql应该不至于这么傻吧~ 论点二:同《高性能Mysql》一书内容不符该书209页有一句话如下图所示 该书也指明权限验证是在预处理器中执行。本文中将预处理和解析器统一划分为分析器的范畴。 论点三:同源码不符我翻看了Mysql5.7.25这个版本的源码,其在处理查询这段的核心代码如下在 sql_parse.cc 文件中,有这么一段代码如下case SQLCOM_SELECT: 其中是进行权限校验。而优化器和执行器是在execute_sqlcom_select 这个方法中。 当然,大家有新的见解,欢迎留言。最后转发到朋友圈是对我最大的支持! |
|
来自: 昵称16619343 > 《区块链》