MySQL體系架構
可以看出MySQL是由連接配接池、管理工具和服務、SQL接口、解析器、優化器、緩存、存儲引擎、檔案系統組成。
連接配接池
由于每次建立建立需要消耗很多時間，連接配接池的作用就是将這些連接配接緩存下來，下次可以直接用已經建立好的連接配接，提升伺服器性能。
管理工具和服務
系統管理和控制工具，例如備份恢複、Mysql複制、叢集等
SQL接口
接受使用者的SQL指令，并且傳回使用者需要查詢的結果。比如select ... from就是調用SQL接口
解析器
SQL指令傳遞到解析器的時候會被解析器驗證和解析。解析器主要功能：1、将SQL語句分解成資料結構，後續步驟的傳遞和處理就是基于這個結構的。2、将SQL語句分解成資料結構，後續步驟的傳遞和處理就是基于這個結構的。
優化器
查詢優化器，SQL語句在查詢之前會使用查詢優化器對查詢進行優化。
緩存器
查詢緩存，如果查詢緩存有命中的查詢結果，查詢語句就可以直接去查詢緩存中取資料。這個緩存機制是由一系列小緩存組成的。比如表緩存，記錄緩存，key緩存，權限緩存等。
存儲引擎(後面單獨說)
檔案系統(後面單獨說講)
連接配接層
當MySQL啟動（MySQL伺服器就是一個程序），等待用戶端連接配接，每一個用戶端連接配接請求，伺服器程序會建立一個線程專門處理與這個用戶端的互動。當用戶端與該伺服器斷開之後，不會立即撤銷線程，隻會把他緩存起來等待下一個用戶端請求連接配接的時候，将其配置設定給該用戶端。每個線程獨立，擁有各自的記憶體處理空間。
以下指令可以檢視最大的連接配接數：
show VARIABLES like '%max_connections%' 連接配接到伺服器，伺服器需要對其進行驗證，也就是使用者名、IP、密碼驗證，一旦連接配接成功，還要驗證是否具有執行某個特定查詢的權限（例如，是否允許用戶端對某個資料庫某個表的某個操作）
Server層(SQL處理層)
這一層主要功能有：SQL語句的解析、優化，緩存的查詢，MySQL内置函數的實作，跨存儲引擎功能（所謂跨存儲引擎就是說每個引擎都需提供的功能（引擎需對外提供接口）），例如：存儲過程、觸發器、視圖等。
當然作為一個SQL的執行流程如下：
1.如果是查詢語句（select語句），首先會查詢緩存是否已有相應結果，有則傳回結果，無則進行下一步（如果不是查詢語句，同樣調到下一步）
2.解析查詢，建立一個内部資料結構（解析樹），這個解析樹主要用來SQL語句的語義與文法解析；
3.優化：優化SQL語句，例如重寫查詢，決定表的讀取順序，以及選擇需要的索引等。這一階段使用者是可以查詢的，查詢伺服器優化器是如何進行優化的，便于使用者重構查詢和修改相關配置，達到最優化。這一階段還涉及到存儲引擎，優化器會詢問存儲引擎，比如某個操作的開銷資訊、是否對特定索引有查詢優化等。
緩存（了解即可）
show variables like '%query_cache_type%' -- 預設不開啟
show variables like '%query_cache_size%' --預設值1M
SET GLOBAL query_cache_type = 1; --會報錯 query_cache_type隻能配置在my.cnf檔案中！
緩存在生産環境建議不開啟，除非經常有sql完全一模一樣的查詢
緩存 嚴格要求2次SQL請求要完全一樣，包括SQL語句，連接配接的資料庫、協定版本、字元集等因素都會影響
從8.0開始，MySQL不再使用查詢緩存，那麼放棄它的原因是什麼呢？
MySQL查詢緩存是查詢結果緩存。它将以SEL開頭的查詢與哈希表進行比較，如果比對，則傳回上一次查詢的結果。進行比對時，查詢必須逐位元組比對，例如 SELECT * FROM e1; 不等于select * from e1;
此外，一些不确定的查詢結果無法被緩存，任何對表的修改都會導緻這些表的所有緩存無效。是以，适用于查詢緩存的最理想的方案是隻讀，特别是需要檢查數百萬行後僅傳回數行的複雜查詢。如果你的查詢符合這樣一個特點，開啟查詢緩存會提升你的查詢性能。
随着技術的進步，經過時間的考驗，MySQL的工程團隊發現啟用緩存的好處并不多。
首先，查詢緩存的效果取決于緩存的命中率，隻有命中緩存的查詢效果才能有改善，是以無法預測其性能。
其次，查詢緩存的另一個大問題是它受到單個互斥鎖的保護。在具有多個核心的伺服器上，大量查詢會導緻大量的互斥鎖争用。
通過基準測試發現，大多數工作負載最好禁用查詢緩存(5.6的預設設定)：按照官方所說的：造成的問題比它解決問題要多的多，弊大于利就直接砍掉了。