03 SQL是如何执行的

目录链接:https://www.jianshu.com/p/2c104aaadb03

Oracle 中的 SQL 是如何执行的

更多可以参看 oracle 官方文档 关于 About SQL Processing https://docs.oracle.com/database/121/TGSQL/tgsql_sqlproc.htm#TGSQL175

看下 SQL 在 Oracle 中的执行过程:

image.png

注:图片来自于 极客时间 SQL必知必会 专栏

这个和官方文档中流程图基本一样


image.png

从上面的图中可以看出, SQL 语句在 Oracle 中经历了以下的几个步骤
例子来自官方文档
1、语法检查:检查 SQL 拼写是否正确, 如果不正确, Oracle 会报语法错误。

SQL> SELECT * FORM employees;
SELECT * FORM employees
         *
ERROR at line 1:
ORA-00923: FROM keyword not found where expected
  1. 语义检查:检查 SQL 中的访问对象是否存在语句是否有意义。 比如我们在写 SELECT 语句的时候, 列名写错了, 系统就会提示错误。 语法检查和语义检查的作用是保证 SQL 语句没有错误。
SQL> SELECT * FROM nonexistent_table;
SELECT * FROM nonexistent_table
              *
ERROR at line 1:
ORA-00942: table or view does not exist
  1. 权限检查:看用户是否具备访问该数据的权限。

  2. 共享池检查:共享池(Shared Pool) 是一块内存池, 最主要的作用是缓存 SQL 语句和该语句的执行计划。Oracle 通过检查共享池是否存在 SQL 语句的执行计划, 来判断进行软解析, 还是硬解析。
    那软解析和硬解析应该怎么理解呢?
    在共享池中, Oracle 首先对 SQL 语句进行 Hash 运算, 然后根据 Hash 值在库缓存(Library Cache) 中查找, 如果存在 SQL 语句的执行计划, 就直接拿来执行, 直接进行“执行器”的环节, 这就是软解析。如果没有找到 SQL 语句和执行计划, Oracle 就需要创建解析树进行解析, 生成执行计划,进行“优化器”这个步骤, 这就是硬解析。

image.png

图片来自 官方文档

  1. 优化器:优化器中就是要进行硬解析, 也就是决定怎么做, 比如创建解析树, 生成执行计划。
    在优化阶段,Oracle数据库必须至少对每个唯一的DML语句执行一次硬解析,并在此解析期间执行优化。 数据库永远不会优化DDL,除非它包含DML组件,例如需要优化的子查询。
    关于DDL DML可参见 https://www.jianshu.com/p/8ead960d2079
  1. 执行器:当有了解析树和执行计划之后, 就知道了 SQL 该怎么被执行, 这样就可以在执行器中执行语句了。

共享池 是 Oracle 中的术语, 包括了库缓存, 数据字典缓冲区等。 库缓存区,它主要缓存 SQL 语句和执行计划。而数据字典缓冲区存储的是 Oracle 中的对象定义, 比如表、视图、 索引等对象。 当对 SQL 语句进行解析的时候, 如果需要相关的数据, 会从数据字典缓冲区中提取。

为了提升 SQL 的执行效率, 我们应该尽量避免硬解析, 因为在 SQL 的执行过程中, 创建解析树, 生成执行计划是很消耗资源的。如何避免硬解析, 尽量使行软解析呢?在 Oracle 中, 绑定变量是它的一大特色。 绑定变量的实质就是用于替代sql语句中的常量的替代变量。绑定变量能够使得每次提交的sql语句都完全一样。

绑定变量相关可以参看:
https://blog.csdn.net/wanghai__/article/details/4778343

MySQL 中的 SQL 是如何执行的

首先 MySQL 是典型的 C/S 架构, 即 Client/Server 架构, 服务器端程序使用的 mysqld。 整体的
MySQL 流程如下图所示:


image.png

注:图片来自于 极客时间 SQL必知必会 专栏
或者


image.png

注:图片来自 《当我们输入一条 SQL 查询语句时,发生了什么?》,文章链接见参考资料

能看到 MySQL 由三层组成:

  1. 连接层:客户端和服务器端建立连接, 客户端发送 SQL 至服务器端;
  2. SQL 层:对 SQL 语句进行查询处理;
  3. 存储引擎层:与数据库文件打交道, 负责数据的存储和读取。

SQL 层的结构

image.png

注:图片来自于 极客时间 SQL必知必会 专栏

  1. 查询缓存:
    Server 如果在查询缓存中发现了这条 SQL 语句, 就会直接将结果返回给客户端;如果没有, 就进行到解析器阶段。 需要说明的是, 因为查询缓存往往效率不高, 所以在MySQL8.0 之后就抛弃了这个功能。查询缓存的失效非常频繁,只要有对一个表的更新,这个表上所有的查询缓存都会被清空。因此很可能你费劲地把结果存起来,还没使用呢,就被一个更新全清空了。对于更新压力大的数据库来说,查询缓存的命中率会非常低。
  2. 解析器:
    在解析器中对 SQL 语句进行语法分析、 语义分析。
  3. 优化器:
    在优化器中会确定 SQL 语句的执行路径, 比如是根据全表检索, 还是根据索引来检索等。优化器是在表里面有多个索引的时候,决定使用哪个索引;或者在一个语句有多表关联(join)的时候,决定各个表的连接顺序。
  4. 执行器:在执行之前需要判断该用户是否具备权限, 如果具备权限就执行 SQL 查询并返回
    结果。 在 MySQL8.0 以下的版本, 如果设置了查询缓存, 这时会将查询结果进行缓存。

与 Oracle 不同的是, MySQL 的存储引擎采用了插件的形式, 每个存储引擎都面向一种特定的数据库应用环境。

存储引擎

存储引擎 特点
InnoDB 存储引擎 它是 MySQL 5.5.8 版本之后默认的存储引擎, 最大的特点是支持事务、级锁定、 外键约束等。
MyISAM 存储引擎 在 MySQL 5.5.8 版本之前是默认的存储引擎, 不支持事务, 也不支持外键, 最大的特点是速度快, 占用资源少。
Memory 存储引擎 使用系统内存作为存储介质, 以便得到更快的响应速度。
NDB 存储引擎 也叫做 NDB Cluster 存储引擎,主要用于 MySQL Cluster 分布式集群环境, 类似于 Oracle 的 RAC 集群。
Archive 存储引擎 它有很好的压缩机制, 用于文件归档, 在请求写入时会进行压缩, 所以也经常用来做仓库。

不同的存储引擎都有各自的特点,以适应不同的需求,如下表所示:

功 能 MYISAM Memory InnoDB Archive
存储限制 256TB RAM 64TB None
支持事物 No No Yes No
支持全文索引 Yes No No No
支持数索引 Yes Yes Yes No
支持哈希索引 No Yes No No
支持数据缓存 No N/A Yes No
支持外键 No No Yes No

实际上完整的 Oracle 和 MySQL结构图要复杂得多:

image.png

注:图片来自于 极客时间 SQL必知必会 专栏

可参看:
Oracle--数据库体系结构(物理结构、逻辑结构、内存结构及后台进程)

image.png

注:图片来自于 极客时间 SQL必知必会 专栏

可参看:
MySQL体系结构

image.png

注:图片来自于 极客时间 SQL必知必会 专栏

参考资料:

极客时间 SQL必知必会学习

SQL必知必会专栏(极客时间)链接:
http://gk.link/a/103Sm

Oracle 官方文档 Database SQL Tuning Guide中:
https://docs.oracle.com/database/121/TGSQL/tgsql_sqlproc.htm#TGSQL176

ORACLE 绑定变量用法总结:
https://blog.csdn.net/wanghai__/article/details/4778343

当我们输入一条 SQL 查询语句时,发生了什么?:
https://www.infoq.cn/article/PKzT75BPcryCYJ_VuWrR

Mysql 存储引擎的区别和比较:
https://blog.csdn.net/zgrgfr/article/details/74455547

四种mysql存储引擎:
https://blog.csdn.net/zhangyuan19880606/article/details/51217952

Oracle--数据库体系结构(物理结构、逻辑结构、内存结构及后台进程):
https://blog.csdn.net/oChangWen/article/details/51171992

MySQL体系结构:
https://www.cnblogs.com/yjf512/archive/2012/02/06/2339496.html


GitHub链接:
https://github.com/lichangke/LeetCode

知乎个人首页:
https://www.zhihu.com/people/lichangke/

简书个人首页:
https://www.jianshu.com/u/3e95c7555dc7

个人Blog:
https://lichangke.github.io/

欢迎大家来一起交流学习

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,590评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 86,808评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,151评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,779评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,773评论 5 367
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,656评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,022评论 3 398
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,678评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 41,038评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,659评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,756评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,411评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,005评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,973评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,053评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,495评论 2 343

推荐阅读更多精彩内容