執行流程
如下圖所示，我們可以看到當向 MySQL 發送一個請求時，MySQL 到底做了什么：
- 客戶端發送一條査詢給服務器，
- 服務器先檢查査詢快取，如果命中了快取，則立刻回傳存盤在快取中的結果，否則進人下一階段，
- 服務器端進行 SQL 決議、預處理，再由優化器生成對應的執行計劃，
- MySQL 根據優化器生成的執行計劃，呼叫存盤引擎的 API 來執行查詢，
- 將結果回傳給客戶端，
查詢快取
在決議一個查詢陳述句之前，如果查詢快取時打開的，那么 MySQL 會優先檢查這個查詢是否命中查詢快取中的資料，這個檢查時通過一個對大小寫敏感的哈希查找實作的，查詢和快取中的查詢即使只有一個位元組不同，那也不會匹配快取結果， 如果當前的查詢恰好命中了快取，那么在回傳結果之前 MySQL 會檢查一次用戶權限，這仍然是無須決議查詢 SQL 陳述句的，因為在查詢快取中已經存放了當前查詢需要訪問的表資訊，如果權限沒有問題，MySQL 會跳過所有其他階段，直接從快取中拿到結果并回傳給客戶端，跳過了決議、優化和執行階段， 查詢快取系統會跟蹤查詢表中涉及的每個表，如果這些表發生變化，那么和這個表相關的所有快取資料都將失效，這種機制效率看起來比較低，因為資料變化時很有可能對應的查詢結果并沒有變更，但是這種簡單實作代價很小，而這點對于一個非常繁忙的系統來說非常重要，有關查詢快取的配置
query_cache_type 是否打開查詢快取，可以設定成 OFF、ON 或者 DEMAND，DEMAND 表示只有在查詢陳述句中明確寫明 SQL_CACHE 的陳述句才放入查詢快取， query_cache_size 查詢快取使用的總記憶體空間，單位是位元組，這個值必須是 1024 的整數倍，否則 MySQL實際分配的資料會和你指定的略有不同， query_cache_min_res_unit 在查詢快取中分配記憶體塊時的最小單位， query_cache_limit MySQL 能夠快取的最大查詢結果，如果查詢結果大于這個值，則不會被快取， query_cache_wlock_invalidate 如果某個資料表被其他的連接鎖住，是否仍然從拆線呢快取中回傳結果，這個引數默認是 OFF，這可能在一定程度上會改變服務器的行為，因為這使得資料庫可能回傳其他執行緒鎖住的資料，將引數設定為 ON，則不會從快取中讀取這類資料，但是這可能會增加鎖等待，對于絕大多數應用來說無需注意這個細節，所以默認設定通常是沒有問題的，語法決議器和預處理
首先，MySQL 通過關鍵字將 SQL 陳述句進行決議，并生成一顆對應的“決議樹”，MySQL 決議器將使用 MySQL 語法規則驗證和決議查詢，例如，它將驗證是否使用錯誤的關鍵字，或者使用關鍵字的順序是否正確等，再或者它還會驗證引號是否能前后正確匹配， 前處理器則根據一些 MySQL 規則進一步檢查決議樹是否合法，例如，這里將檢查資料表和資料列是否存在，還會決議名字和別名，看看它們是否有歧義， 下一步前處理器會驗證權限，這通常很快，除非服務器上有非常多的權限配置，查詢優化器
現在語法樹被認為是合法的了，并且由優化器將其轉化成執行計劃，一條查詢可以有很多種執行方式，最后都回傳相同的結果，優化器的作用就是找到這其中最好的執行計劃， MySQL 使用基于成本的優化器，它將嘗試預測一個查詢使用某種執行計劃時的成本，并選擇其中成本最小的一個， MySQL 查詢優化器在生成查詢的執行計劃時，需要向存盤引擎獲取相應的統計資訊，存盤引擎則提供給優化器對應的統計資訊，包括：每個表或索引有多少個頁面、每個表的每個索引的基數是多少、資料行和索引長度、索引的分布資訊等，優化器根據這些資訊來選擇一個最優的執行計劃，查詢執行引擎
相對于查詢優化階段，查詢執行階段不是那么復雜：MySQL 只是簡單地根據執行計劃給出地指令逐步執行，在根據計劃逐步執行的程序中，有大量的操作需要通過呼叫存盤引擎實作的介面來完成，回傳結果給客戶端
查詢執行的最后一個階段是將結果回傳給客戶端，即使查詢不需要回傳結果集給客戶端，MySQL 仍然會回傳這個查詢的一些資訊，如該查詢影響到的行數， 如果查詢可以被快取，那么 MySQL 在這個階段也會將結果存放到查詢快取中，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/299293.html
標籤：MySQL