關於MySQL中的查詢開銷檢視方法詳解

mysql邏輯架構

如果能在頭腦中構建一幅mysql各元件之間如何協同工作的架構圖，有助於深入理解mysql伺服器。下圖展示了mysql的邏輯架構圖。

mysql邏輯架構，來自：高效能mysql

mysql邏輯架構整體分為三層，最上層為客戶端層，並非mysql所獨有，諸如：連線處理、授權認證、安全等功能均在這一層處理。

mysql大多數核心服務均在中間這一層，包括查詢解析、分析、優化、快取、內建函式(比如：時間、數學、加密等函式)。所有的跨儲存引擎的功能也在這一層實現：儲存過程、觸發器、檢視等。

最下層為儲存引擎，其負責mysql中的資料儲存和提取。和linux下的檔案系統類似，每種儲存引擎都有其優勢和劣勢。中間的服務層通過api與儲存引擎通訊，這些api介面遮蔽了不同儲存引擎間的差異。

mysql使用基於成本的優化器，它嘗試**乙個查詢使用某種執行計畫時的成本，並選擇其中成本最小的乙個。在mysql可以通過查詢當前會話的last_query_cost的值來得到其計算當前查詢的成本。

示例**

mysql> select * from t_message limit 10;

...省略結果集

mysql> show status like 'last_query_cost';

+-----------------+-------------+

| variable_name | value |

+-----------------+-------------+

| last_query_cost | 6391.799000 |

+-----------------+-------------+

示例中的結果表示優化器認為大概需要做6391個資料頁的隨機查詢才能完成上面的查詢。這個結果是根據一些列的統計資訊計算得來的，這些統計資訊包括：每張表或者索引的頁面個數、索引的基數、索引和資料行的長度、索引的分布情況等等。

有非常多的原因會導致mysql選擇錯誤的執行計畫，比如統計資訊不準確、不會考慮不受其控制的操作成本（使用者自定義函式、儲存過程）、mysql認為的最優跟我們想的不一樣（我們希望執行時間盡可能短，但myswww.cppcns.comql值選擇它認為成本小的，但成本小並不意味著執行時間短）等等。

這裡last_query_cost的值是io_cost和cpu_cost的開銷總和，它通常也是我們評價乙個查詢的執行效率的乙個常用指標。

(1)它是作為比較各個查詢之間的開銷的乙個依據。

(2)它只能檢測比較簡單的查詢開銷，lckiugikky對於包含子查詢和union的查詢是測試不出來的。

(3)當我們執行查詢的時候，mysql會自動生成乙個執行計畫，也就是query plan，而且通常有很多種不同的實現方式，它會選擇最低的那一程式設計客棧個，而這個cost值就是開銷最低的那乙個。

(4)它對於比較我們的開銷是非常有用的，特別是我們有好幾種查詢方式可選的時候。

程式設計客棧總結

本文標題: 關於mysql中的查詢開銷檢視方法詳解

本文位址: /shujuku/mysql/232158.html