【邏輯架構(gòu)】

第一層：所包含的服務(wù)并不是MySQL所獨有的技術(shù)。它們都是服務(wù)于C/S程序或者是這些程序所需要的 ：連接處理，身份驗證，安全性等等。

第二層：通常叫做 SQL Layer。在 MySQL數(shù)據(jù)庫系統(tǒng)處理底層數(shù)據(jù)之前的所有工作都是在這一層完成的，包括權(quán)限判斷， sql解析，行計劃優(yōu)化， query cache 的處理以及所有內(nèi)置的函數(shù)(如日期,時間,數(shù)學(xué)運算,加密)等等。各個存儲引擎提供的功能都集中在這一層，如存儲過程，觸發(fā)器，視圖等

第三層：通常叫做StorEngine Layer ，也就是底層數(shù)據(jù)存取操作實現(xiàn)部分，由多種存儲引擎共同組成。它們負(fù)責(zé)存儲和獲取所有存儲在MySQL中的數(shù)據(jù)。就像Linux眾多的文件系統(tǒng) 一樣。每個存儲引擎都有自己的優(yōu)點和缺陷。服務(wù)器是通過存儲引擎API來與它們交互的。這個接口隱藏了各個存儲引擎不同的地方。對于查詢層盡可能的透明。這個API包含了很多底層的操作。如開始一個事務(wù)，或者取出有特定主鍵的行。存儲引擎不能解析SQL，互相之間也不能通信。僅僅是簡單的響應(yīng)服務(wù)器的請求。

【查詢過程】

1.客戶端請求：

MySQL客戶端/服務(wù)端通信協(xié)議是“半雙工”的：在任一時刻，要么是服務(wù)器向客戶端發(fā)送數(shù)據(jù)，要么是客戶端向服務(wù)器發(fā)送數(shù)據(jù)，這兩個動作不能同時發(fā)生。因而在實際開發(fā)中，盡量保持查詢簡單且只返回必需的數(shù)據(jù)，減小通信間數(shù)據(jù)包的大小和數(shù)量

2.查詢緩存：

在解析一個查詢語句前，如果緩存是打開的，那么MySQL會檢查這個查詢語句是否命中查詢緩存中的數(shù)據(jù)。如果當(dāng)前查詢恰好命中查詢緩存，在檢查一次用戶權(quán)限后直接返回緩存中的結(jié)果。這種情況下，查詢不會被解析，也不會生成執(zhí)行計劃，更不會執(zhí)行。

MySQL將緩存存放在一個引用表(不要理解成table，可以認(rèn)為是類似于HashMap的數(shù)據(jù)結(jié)構(gòu))，通過一個哈希值索引，這個哈希值通過查詢本身、當(dāng)前要查詢的數(shù)據(jù)庫、客戶端協(xié)議版本號等一些可能影響結(jié)果的信息計算得來。所以兩個查詢在任何字符上的不同(例如：空格、注釋)，都會導(dǎo)致緩存不會命中。

如果查詢中包含任何用戶自定義函數(shù)、存儲函數(shù)、用戶變量、臨時表、mysql庫中的系統(tǒng)表，其查詢結(jié)果都不會被緩存。比如函數(shù)NOW()

MySQL的查詢緩存系統(tǒng)會跟蹤查詢中涉及的每個表，如果這些表(數(shù)據(jù)或結(jié)構(gòu))發(fā)生變化，那么和這張表相關(guān)的所有緩存數(shù)據(jù)都將失效。正因為如此，在任何的寫操作時，MySQL必須將對應(yīng)表的所有緩存都設(shè)置為失效。如果查詢緩存非常大或者碎片很多，這個操作就可能帶來很大的系統(tǒng)消耗，甚至導(dǎo)致系統(tǒng)僵死一會兒。而且查詢緩存對系統(tǒng)的額外消耗也不僅僅在寫操作，讀操作也不例外

3.語法解析和預(yù)處理：

MySQL通過關(guān)鍵字將SQL語句進行解析，并生成一顆對應(yīng)的解析樹。這個過程解析器主要通過語法規(guī)則來驗證和解析。比如SQL中是否使用了錯誤的關(guān)鍵字或者關(guān)鍵字的順序是否正確等等。預(yù)處理則會根據(jù)MySQL規(guī)則進一步檢查解析樹是否合法。比如檢查要查詢的數(shù)據(jù)表和數(shù)據(jù)列是否存在等等

4.查詢優(yōu)化

經(jīng)過前面的步驟生成的語法樹被認(rèn)為是合法的了，并且由優(yōu)化器將其轉(zhuǎn)化成查詢計劃。多數(shù)情況下，一條查詢可以有很多種執(zhí)行方式，最后都返回相應(yīng)的結(jié)果。優(yōu)化器的作用就是找到這其中最好的執(zhí)行計劃。MySQL使用基于成本的優(yōu)化器，它嘗試預(yù)測一個查詢使用某種執(zhí)行計劃時的成本，并選擇其中成本最小的一個。

5.查詢執(zhí)行引擎

在完成解析和優(yōu)化階段以后，MySQL會生成對應(yīng)的執(zhí)行計劃，查詢執(zhí)行引擎根據(jù)執(zhí)行計劃給出的指令逐步執(zhí)行得出結(jié)果。整個執(zhí)行過程的大部分操作均是通過調(diào)用存儲引擎實現(xiàn)的接口來完成，這些接口被稱為handler API。查詢過程中的每一張表由一個handler實例表示。實際上，MySQL在查詢優(yōu)化階段就為每一張表創(chuàng)建了一個handler實例，優(yōu)化器可以根據(jù)這些實例的接口來獲取表的相關(guān)信息，包括表的所有列名、索引統(tǒng)計信息等。存儲引擎接口提供了非常豐富的功能，但其底層僅有幾十個接口，這些接口像搭積木一樣完成了一次查詢的大部分操作。

6.返回結(jié)果

查詢執(zhí)行的最后一個階段就是將結(jié)果返回給客戶端。即使查詢不到數(shù)據(jù)，MySQL仍然會返回這個查詢的相關(guān)信息，比如該查詢影響到的行數(shù)以及執(zhí)行時間等等。

【存儲引擎】

查看現(xiàn)在提供的存儲引擎： show engines;

查看現(xiàn)在默認(rèn)使用的存儲引擎：show variables like '%storage_engine%';

查看某表使用的存儲引擎：show create table 表名;

InnoDB和MyISAM的區(qū)別：

InnoDB 支持事務(wù)，MyISAM 不支持事務(wù)。這是 MySQL 將默認(rèn)存儲引擎從 MyISAM 變成 InnoDB 的重要原因之一；

InnoDB 支持外鍵，而 MyISAM 不支持。對一個包含外鍵的 InnoDB 表轉(zhuǎn)為 MYISAM 會失敗；

InnoDB 是聚簇索引，MyISAM 是非聚簇索引。聚簇索引的文件存放在主鍵索引的葉子節(jié)點上，因此 InnoDB 必須要有主鍵，通過主鍵索引效率很高。但是輔助索引需要兩次查詢，先查詢到主鍵，然后再通過主鍵查詢到數(shù)據(jù)。因此，主鍵不應(yīng)該過大，因為主鍵太大，其他索引也都會很大。而 MyISAM 是非聚集索引，數(shù)據(jù)和索引是分離的，索引保存的是數(shù)據(jù)文件的指針。主鍵索引和輔助索引是獨立的。

InnoDB 不保存表的具體行數(shù)，執(zhí)行select count(*) from table 時需要全表掃描。而 MyISAM 用一個變量保存了整個表的行數(shù)，執(zhí)行上述語句時只需要讀出該變量即可，速度很快；

InnoDB 最小的鎖粒度是行鎖，MyISAM 最小的鎖粒度是表鎖。一個更新語句會鎖住整張表，導(dǎo)致其他查詢和更新都會被阻塞，因此并發(fā)訪問受限。這也是 MySQL 將默認(rèn)存儲引擎從 MyISAM 變成 InnoDB 的重要原因之一；

總結(jié)

以上是生活随笔為你收集整理的mysql 架构名_MySQL 逻辑体系架构的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。