sql是關係型數據庫的統一標準, 那麼在mysql裏面,是如何實現sql語句的
執行 與返回的呢?
征途之始:
當客戶端發起一條sql請求的時候. 我們sql語句的征途就正式開始了
征途之中:
對於mysql 服務器來說,接收到sql語句的時候, sql它還是一個數據包., 然後首先進入了Mysql中的自定義緩存區中, 發現當前緩存處於關閉狀態.
解析室
於是帶着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開心極了,總算可以回去了.
歸途
當sql拿着數據箱, 上了歸途快車, 途經緩存室, 但是因爲緩存室年久失修,所以就不停留,直接返回數據碼頭, 連帶數據箱一起再次被壓縮成數據包, 然後返回了 客戶端
被壓縮前,想着任務完成了,回去可以休息了
(它不知道的是, 作爲一個短鏈接, 這將是它一生的終點)