MySQL | SQL 语句是怎样执行的呢?

微信公众号:一个优秀的废人
如有问题或建议,请后台留言,我会尽力解决你的问题。

前言

高产似母猪,废话少说,今天刚好读到一篇关于 MySQL 语句底层如何执行的文章,以下是我的理解,分享给你们。

简单的 SQL 语句

mysql> select * from User where ID=10086;

上面是一条非常简单的 SQL 查询语句,咋一看是不是觉得很简单,但却不懂它内部的执行流程?

根据自己的理解,我画了个不那么专业的执行流程图,先给出这条 SQL 语句的执行流程,再逐步解析每个流程,执行流程图如下:

SQL语句执行流程图

你可以清晰地看到,MySQL 其实分为两层,server 层和存储引擎层。

server 层包括 连接器、查询缓存、分析器、优化器、执行器等,这一层涵盖了 MySQL 的大部分核心功能,包括你平时用到的很多函数。从图中可以看出,不同的引擎使用同一个 Server 层。

存储引擎层则是复制数据的存储和读取。由于在 MySQL 中,存储引擎是以插件形式存在的。所以它支持 InnDB、MySAM、Memory 等引擎,其中用得最多的就是 InnDB。

连接器

这条语句执行的第一步就是连接数据库,这时会调用连接器干这个事情。他负责跟客户端建立连接、获取权限、维持和管理连接。

连接命令一般是这么写的,相信不用我过多解释。

mysql -h 192.168.0.201 -P 3306 -u root -p123

输入这条命令之后最底层就是客户端与数据库之间进行经典的 TCP 握手通信,连接完成后,连接器就开始校验当前用户的身份。

  • 如果账号密码不对,就会抛出 Access denied for user 的异常。

  • 如果账号密码正确,连接器就会读取当前用户此时所拥有的的权限,值得注意的是,在连接过程中,即使你用管理员账号修改当前用户的权限,丝毫不会影响它在本次连接的权限,你的修改需要等到下次连接才会生效。

  • 如果你长时间没有操作数据库,这个连接自动断开,这个时间默认是 8 小时。这个时候你要操作数据库就必须重连。

如何取舍长连接和短连接?

长连接指的是数据库持续拥有一个连接,短连接指每次执行完很少的几次操作就断开连接。

但是有个问题,长连接临时使用的内存管理在连接对象中,如果使用长连接,内存占用太大导致 MySQL 重启,而连接本来就是一个非常复杂的操作(想想 TCP 通信),我们又不能使用短连接。那如何取舍呢?

可以考虑以下方案:

  1. 定期断开长连接,使用一段时间,或者程序里面判断占用内存较大时,断开连接。

  2. MySQL 5.7 以上版本,可以在执行一个大的操作后,运行 mysql_reset_connection 来初始化链接资源,这个过程并不需要重连,但还是会恢复到初始连接的状态。

查询缓存

若开启了查询缓存,之前执行过的语句会以 key-value 对的形式存在。典型应用就是 redis。

连接建立完成后,接下来,select 语句就是到查询缓存中判断是否有当前语句的缓存,若有直接返回结果集。

使用了查询缓存效率会很高。但一般不建议用,为什么?

为什么不建议用查询缓存?

查询缓存失效的频率非常高,只要有对表的更新,这个表的所有查询缓存就失效了,你辛苦存起来的缓存,还没使用就这么一下子就没了。对于经常更新的数据库来说,查询缓存根本没必要存在。除非你的表数据是不常变动的,建议你使用查询缓存。

分析器

如果没命中缓存就要开始执行语句了,但在执行之前 MySQL 需要知道你想干嘛。因此会对语句进行分析,这时就是分析器的活了。

首先 MySQL 会做词法分析,以上述语句为例,MySQL 就会识别出 select 关键字,分析这是查询语句,再把 User 识别成 表名 User,把字符串 "ID" 识别出 "列ID"。

优化器

经过分析器知道了做什么,在开始执行前还需要经过优化器。

它的作用就是在表里面有多个索引的时候。决定使用那个索引;或者在一个语句有多表关联的时候,决定各个表的连接顺序。优化器会选择效率最高的优化方案。

执行器

翻过万水千山终于来到了执行器,在开始执行之前,执行器会判断当前用户对表 User 是否有查询的权限。如果没有就报权限异常,(那如果当前用户没有权限,但命中了查询缓存,那 MySQL 会在返回结果时做权限认证)

如果有权限,执行流程如下(以上述语句为例):

  1. 调用 InnoDB 引擎接口取这个表的第一行,判断 ID 值是不是 10086,如果不是则跳过,如果是则将这行存在结果集中。

  2. 调用引擎接口取“下一行”,重复相同的判断逻辑,直到取到这个表的最后一行。

  3. 执行器将上述遍历过程中所有满足条件的行组成的记录集作为结果集返回给客户。

至此执行结果完成。

后语

以上就是我对 MySQL 查询语句执行流程的理解,希望对你们有帮助。最后,对 Python 、Java 感兴趣请长按二维码关注一波,我会努力带给你们价值,如果觉得本文对你哪怕有一丁点帮助,请帮忙点好看,让更多人知道。如有问题或建议,请后台留言,我会尽力解决你的问题。

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

推荐阅读更多精彩内容