SQL执行过程以及底层原理

一条查询SQL执行流程图如下:


6943526-fe170c1f50aff0ab.jpg

SQL可以细分为

DML(Update、Insert、Delete),

DDL(表结构修改),

DCL(权限操作)

DQL(Select)

一条查询SQL,也就是一句DQL。客户端按照Mysql通信协议,把我发送到服务端。
当SQL到达服务端后,会在一个单独的线程里进行执行
查看线程状态:

SHOW [FULL] PROCESSLIST
6943526-92750688bd981f3a.png

Sleep,这是在告诉你线程正在等待客户端发送新的请求。还有一个为
Query,这代表线程正在执行查询或者正在将结果发送给客户端。

查询缓存

Mysql要判断我的前6个字符是否为select。并且,语句中不带有SQL_NO_CACHE关键字,
如果符合条件,就进入查询缓存

//不通过缓存查询
Select SQL_NO_CACHE * from table

也可以将参数query_cache_type设置成DEMAND来绕过查询缓存。
后来缓存查询被去掉了!!!!
原因:
只要有对一个表的更新,这个表上所有的查询缓存都会被清空
SQL任何字符上的不同,如空格,注释,都会导致缓存不命中

分析器

SQL:

select username from userinfo

先对SQL进行词法分析,从左到右一个字符、一个字符地输入,然后根据构词规则识别单词。将会生成4个Token,如下所示。


6943526-1b29d67a44ed0d4c.png

解析器:"接下来呢,进行语法解析,判断你输入的这个 SQL 语句是否满足 MySQL 语法。然后生成下面这样一颗语法树。


6943526-b4036e816a2bccba.png

如果语法不对,解析器:"收到一个提示如下!"

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'

最后,这颗语法树会传递给优化器

优化器

这里优化的其实应该是语法树,针对语法树进行优化
根据语法里的
判断一下怎么样执行更快,比如先查Table1再查Table2,还是先查Table2再查Table1呢?判断完如何执行以后,生成执行计划就好啦!

优化器将语法树变身为一个执行计划,然后交给执行器

执行器

就是根据执行计划来进行执行查询啦。根据执行计划的指令,逐条调用底层存储引擎,逐步执行。
MySQL定义了一系列抽象存储引擎API,以支持插件式存储引擎架构。Mysql实现了一个抽象接口层,叫做 handler(sql/handler.h),其中定义了接口函数,比如:ha_open, ha_index_end, ha_create等等,存储引擎需要实现这些接口才能被系统使用

其他议论

如果是SELECT类型的SQL,Mysql会将查询结果缓存起来。至于其他的SQL,就将该表涉及到的查询缓存清空。

关于权限执行阶段:

论点一:权限验证在执行器中判断从逻辑上说不通
一条查询SQL经过查询缓存、分析器、优化器,执行器。如果到最后一个阶段执行器中才发现权限不足、那不是前面一系列流程白做了,Mysql应该不至于这么傻吧~

论点二:同《高性能Mysql》一书内容不符
该书209页有一句话如下图所示

image

该书也指明权限验证是在预处理器中执行。本文中将预处理和解析器统一划分为分析器的范畴。

论点三:同源码不符
我翻看了Mysql5.7.25这个版本的源码,其在处理查询这段的核心代码如下
sql_parse.cc文件中,有这么一段代码如下

case SQLCOM_SELECT:
 {
    //省略
    res= select_precheck(thd, lex, all_tables, first_table);
    if (!res)
      res= execute_sqlcom_select(thd, all_tables);
    //省略
  }

你可能感兴趣的:(SQL执行过程以及底层原理)