servermysql
Server 層包括鏈接器、查詢緩存、分析器、優化器、執行器等,涵蓋 MySQL 的大多數核 心服務功能,以及全部的內置函數(如日期、時間、數學和加密函數等),全部跨存儲引 擎的功能都在這一層實現,好比存儲過程、觸發器、視圖等。
存儲引擎sql
存儲引擎層負責數據的存儲和提取。其架構模式是插件式的,支持 InnoDB、 MyISAM、Memory 等多個存儲引擎。如今最經常使用的存儲引擎是 InnoDB,它從 MySQL 5.5.5 版本開始成爲了默認存儲引擎。
鏈接器負責跟客戶端創建鏈接、獲取權限、維持和管理鏈接數據庫
注意:緩存
一個用戶成功創建鏈接後,即便你用管理員帳號對這個用戶的權限作了修 改,也不會影響已經存在鏈接的權限。修改完成後,只有再新建的鏈接纔會使用新的權限設置。
長連接:架構
數據庫裏面,長鏈接是指鏈接成功後,若是客戶端持續有請求,則一直使用同一個鏈接。 短鏈接則是指每次執行完不多的幾回查詢就斷開鏈接,下次查詢再從新創建一個。 創建鏈接的過程一般是比較複雜的,因此我建議你在使用中要儘可能減小創建鏈接的動做,也就是儘可能使用長鏈接。
執行步驟1:查詢緩存函數
MySQL 拿到一個查詢請求後,會先到查詢緩存看看,以前是否是執行過這條語句。以前 執行過的語句及其結果可能會以 key-value 對的形式,被直接緩存在內存中。key 是查詢 的語句,value 是查詢的結果。若是你的查詢可以直接在這個緩存中找到 key,那麼這個 value 就會被直接返回給客戶端。
緩存中沒有優化
就會繼續後面的執行階段。執行完成後,執行結果會被存入查 詢緩存中。你能夠看到,若是查詢命中緩存,MySQL 不須要執行後面的複雜操做,就可 以直接返回結果,這個效率會很高。
是否使用緩存加密
查詢緩存的失效很是頻繁,只要有對一個表的更新,這個表上全部的查詢緩存都會被清空。所以極可能你費勁地把結果存起來,還沒使用呢,就被一個更新全清空了。 對於更新壓力大的數據庫來講,查詢緩存的命中率會很是低。除非你的業務就是有一張靜態表,很長時間纔會更新一次。好比,一個系統配置表,那這張表上的查詢才適合使用查詢緩存。
按需使用插件
MySQL 也提供了這種「按需使用」的方式。你能夠將參數 query_cache_type 設置 成 DEMAND,這樣對於默認的 SQL 語句都不使用查詢緩存。而對於你肯定要使用查詢緩 存的語句,能夠用 SQL_CACHE 顯式指定,像下面這個語句同樣: mysql> select SQL_CACHE * from T where ID=10; MySQL 8.0 版本直接將查詢緩存的整塊功能刪掉了,也就是說 8.0 開始徹 底沒有這個功能了
詞法分析3d
你輸入的是由多個字符串和空格組成的一條 SQL 語句, MySQL 須要識別出裏面的字符串分別是什麼,表明什麼。 MySQL 從你輸入的"select"這個關鍵字識別出來,這是一個查詢語句。它也要把字符 串「T」識別成「表名 T」,把字符串「ID」識別成「列 ID」。
語法分析
根據詞法分析的結果,語法分析器會根據語 法規則,判斷你輸入的這個 SQL 語句是否知足 MySQL 語法。 通常語法錯誤會提示第一個出現錯誤的位置,因此你要關注的是緊接「use near」的內 容。
優化器是在表裏面有多個索引的時候,決定使用哪一個索引;或者在一個語句有多表關聯 (join)的時候,決定各個表的鏈接順序
select * from t1 join t2 using(ID) where t1.c=10 and t2.d=20; 既能夠先從表 t1 裏面取出 c=10 的記錄的 ID 值,再根據 ID 值關聯到表 t2,再判斷 t2 裏面 d 的值是否等於 20 也能夠先從表 t2 裏面取出 d=20 的記錄的 ID 值,再根據 ID 值關聯到 t1,再判斷 t1 裏面 c 的值是否等於 10 優化器的做用就是決定選擇使用哪個方案
執行前的判斷
要先判斷一下你對這個表 T 有沒有執行查詢的權限,若是沒有,就會返 回沒有權限的錯誤(若是命中查詢緩存,會在查詢緩存返回結果的時候,作權限驗證。查詢也會在優化器以前調用 precheck 驗證權限)
以索引示例
ID 字段沒有索引
1. 調用 InnoDB 引擎接口取這個表的第一行,判斷 ID 值是否是 10,若是不是則跳過,如 果是則將這行存在結果集中; 2. 調用引擎接口取「下一行」,重複相同的判斷邏輯,直到取到這個表的最後一行。 3. 執行器將上述遍歷過程當中全部知足條件的行組成的記錄集做爲結果集返回給客戶端。
ID 字段有索引
1.第一次調用的是「取知足條件的第一行」這個接口 2.以後循環取「知足條件的下一行」這個接口,接口都是引擎中已經定義好的