MySQL 查詢的成本的檢視

讀《高效能MySQL》第三版，筆記。

MySQL 使用基於成本的優化器，它將嘗試預測一個查詢使用某種執行計劃時的成本，選擇其中成本最小的一個。

最初，成本的最小單位是隨機讀取一個 4K 資料頁的成本，後來（成本計算公式）變得更加複雜，並且引入了一些 “ 因子 ” 來估算某些操作的代價，如當執行一次 WHERE 條件比較的成本。

可以通過查詢當前會話的 last_query_cost 的值來得知 MySQL 計算的當前查詢的成本。

mysql> show status like 'last_query_cost';
+-----------------+----------+
| Variable_name   | Value    |
+-----------------+----------+
| Last_query_cost | 2.399000 |
+-----------------+----------+
1 row in set (0.00 sec)

以上表示需要 2 個資料頁的隨機查詢才能完成上面的查詢。

這是根據一系列的統計資訊計算得來的：

• 每個表或者所有的頁面個數
• 索引的基數（索引中不同值的數量）
• 索引和資料行的長度
• 索引分配情況

優化器評估成本不考慮快取，它假設讀取任何資料都需要一次磁碟 I/O。

有很多原因會導致 MySQL 優化器選擇錯誤的執行計劃：

• 統計資訊不準確。
• 執行計劃中的成本估算不等同於實際執行的成本。
• MySQL 的最優可能和你想的最優不一樣。
• MySQL 從不考慮其他併發執行的查詢，這可能會影響到當前查詢的速度。
• MySQL 也並不是任何時候都是基於成本的優化。
• MySQL 不會考慮不受其控制的操作的成本。