所述內容均來自網際網路，文章僅作為學習筆記，備忘使用。
有時候我在想我們總是在談優化，fa 優化結構、優化框架、優化程式…，可是我真的了解將要進行的操作[優化]嗎？以最近我的工作-優化sql為例，我真的明白一條sql從提交伺服器到返回資料所經理的過程嗎？貌似這些理論知識以前都看過，但年代久遠在我的記憶中已經變的相當模糊。現在重新來認識一下：
查詢解析：
當伺服器接收到請求，獲取到需要當前需要執行的字串[sql語句]，首先會對其進行解析，看看是否符合基本的語法結構，如果沒有問題，將繼續進行後續步驟，反之則給出響應的錯誤提示。當然如果是ddl語句就不用再看了，sql不會對ddl進行優化。
深度查詢解析：
看網上的大牛稱這步為algebrizer，為了方便本人記憶我稱之為深度解析,它完成一些基本但更深入的評估工作，例如對方是否存在等等。如果沒有發現問題，algebrizer 輸出乙個二進位制資料稱為查詢處理樹，並傳輸給查詢優化器。查詢處理樹包含了乙個hash值（描述查詢的乙個已經編碼的值）。優化器根據這個hash值去確認當前的查詢計畫是否存在,如果當發現已經存在，優化過程將在這裡結束並使用這個計畫。查詢計畫是什麼呢？其實我們經常見到，就是平時不太注意，我們有兩種方式來檢視查詢計畫：圖表、列表
set statistics profile on查詢優化：優化器本質是一塊模型，用於模擬資料庫關係引擎如何工作的軟體。統計資訊是核心，它是由sqlserver針對索引和列產生並維護的，明確用於優化的元件。需要注意的是表變數沒有統計資訊而臨時表擁有和物理表一樣的統計資訊。通過查詢處理樹和關於資料的統計資訊，優化器應用模型將給出它認為最佳的查詢的方式，也就是說，它產生乙個執行計畫。優化器會產生並評估很多計畫並快取計畫[存放在名為plan cache的記憶體中]，通常來說，sql會選擇開銷最低的計畫，也就是它認為的最優計畫，多數情況下sql的選擇都是正確的。有時候，優化優化器執行的並不是最好的執行計畫，而是找到最少可能的迭代次數的最低開銷的計畫，也就是說找到在處理過程中最短時間的計畫,當然有時候也會執行乙個並不很好的計畫。select d.name from humanresources.department as d where d.departmentid=42
這樣就可以看到**形式的查詢計畫了。
查詢執行：
當上面的步驟都已經完成，計畫已經制定，那就要開始幹活了，這個時候將由分析引擎切換到儲存引擎。由它來完成整個查詢計畫的實施過程。一般來說這個步驟是整個請求響應的最後一步。但也不是一定的，特定的情況下查詢計畫會發生更改，從而回到查詢計畫的評估和制定步驟，例如統計資訊發生了變化、查詢中使用了臨時表等。
sql的執行順序
mysql檢視sql執行過程 SQL查詢執行過程
mysql查詢執行過程客戶端向伺服器傳送請求 伺服器查詢快取，快取中命中則結束，將結果返回客戶端 返回前會檢查使用者許可權 否則繼續下邊步驟 伺服器端進行sql解析 預處理，再由優化器生成對應的執行計畫 根據執行計畫呼叫儲存引擎的api執行查詢 將結果返回客戶端 一 查詢快取 如果一條sql語句以s...
sql執行過程
程式中寫的一條sql傳送到伺服器端 查詢此條sql是否存在執行計畫 如果存在則直接呼叫已經編譯好的執行計畫 否則進入下一步。如果sql計畫快取中沒有對應的執行計畫，則進行語法校驗 檢視是否存在語法錯誤 如果語法沒有錯誤則進行語義校驗，例如,表名,列名,儲存過程等等資料庫物件是否真正存在 如果語義沒有...
SQL執行過程
mysql server pluggable storage engines 1 客戶端 服務端通訊協議 查詢快取，如果有資料返回，否則繼續 複製 2 解析器根據解析樹解析 預處理器檢測正常繼續，否則報錯 比如要查詢的字段不存在 複製 3 查詢優化器 explain查詢執行計畫 好比以前我們除錯介面...