sql是关系型数据库的统一标准, 那么在mysql里面,是如何实现sql语句的
执行 与返回的呢?
征途之始:
当某猿 坐在电脑前, 敲下sql语句, 点击运行之后
客户端向MySQL 发起名为短连接的通道, 我们的sql 沿着这条路踏上了征途
征途之中:
当sql 踏上短连接通道之后,就被压缩成了数据包, 一致送到了 MySQL中的码头,在码头上 由线程充当快递员小哥带着sql这个数据包到处跑
缓存区
当线程带着 sql数据包来到了MySQL 中的第一个建筑 -- MySQL 缓存区. 发现当前缓存区大门紧闭,根本进不去.听说当年MySQL 刚出来的时候,这里一度门庭若市, 但是因为在程序王国出现了更加优秀的缓存方案,导致目前缓存区的门可罗雀, 连大门都紧紧封闭,
“估计没有人会打开它了.”
“已经下命令了这里将要被拆掉了”
“…”
解析室
当线程小哥绕过缓存区 .于是带着sql数据包走到了 sql解析器之中,将sql交由解析器处理, 之间解析器一阵忙活,将sql从数据包状态恢复成 sql语句原本的样子, 并且将其各个部位进行了检查.发现各个部位都健康,
才让sql 走出解析室, 临走前解析室工作人员给了它一张检查报告"解析树".
预处理室
sql语句根据解析室的提示,走向下一个环节,这里叫做预处理器. 在预处理是中,它身上所带的变量 类似于 此次查询的表名称, 取的别名等,是否有错误的地方 ect...........优化室
等预处理室检查完毕之后, 带着由被添加了几笔的报告"解析树" ,sql语句晃晃悠悠的来到了优化室,. 只感觉满身疲劳优化室**工作人员**,看了眼 sql, sql一激灵,不敢犹豫连忙把 报告递上, **工作人员**不紧不慢的拿着报告, 然后开始分析
最后优化室**工作人员**开口道:"你的目的和情况我已经了解了, 现在有 两种方式, 第一中时间会很长,并不复杂, 第二种时间相对要少一点, 但是复杂程度也会上升".
"我选第二套方案." : sql如是说道, 其实sql已经不想在这里待下去了,它已经身心具惫.
"你很聪明,其实你没得选,这里不止你一个 sql ,所以 为了效率......": 工作人员一边说,一边把sql 提起来丢到一辆bus上,bus上除了它之外还有几个其他的陌生sql
查询引擎执行器:
当sql从bus上下来, 率先甩开其他sql, 走入了执行器中, 一进门看见类似银行柜台式的布局.
当下跟据优化室工作人员的嘱咐,跑到一个柜台面前坐下, 把报告"解析树", 和优化室工作人员的给的方案清单 一起交给执行器中的工作人员
工作人员一言不发的拿着执行方案等走开了, sql无奈,但是只能等待.
存储引擎:
在百般无聊中sql,听见边上的其他sql们在聊天, 于是宁心静听
sql_A: 这执行器的人去了哪里?怎么要这么久?
sql_B: 这个,我也不知道.但是我之前在bus上碰上一位老前辈,也许它知道
sql_C: …
这时sql_E 一脸倨傲的走进来: "他们这时到存储引擎里面拿数据去了."作为一个长连接,他当然有资本对这群短连接们 倨傲不已.
sql_B 一脸讨好的望向sql_E :“您知道的多,给我们讲讲呗”.
sql_C:对呀…
sql_A: …
…
sql_E 见气氛已经拿捏够了,也不卖关子 开口道:"这时因为执行器工作人员拿着我们每个人的方案去执行,
但是由于每个表的存储引擎不同,所以要根据不同的表,找到对应的存储引擎, 然后与操作系统交互, 从硬盘中拿出数据,给我们.
当然,硬盘有多慢你们也是知道的, 所以有些常用的数据会被留在缓存里面, 这不 从缓存中拿数据的工作人员已经回来了… "
就在这时 只见工作人员提着一个数据箱, 吃力的走过来, 然后把箱子丢给sql
“这是你的数据,拿了赶紧走, 出门右转, 有直接返回客户端的快车”.
sql开心极了,总算可以回去了.
归途
当sql拿着数据箱, 上了归途快车, 途经缓存室, 但是因为缓存室年久失修,所以就不作停留,直接返回数据码头, 连带数据箱一起再次被压缩成数据包, 然后返回了 客户端
被压缩前,想着任务完成了,回去可以休息了
(它不知道的是, 作为一个短链接, 这将是它一生的终点)
