MySQL源碼學習：關於慢查詢日誌中的Rows_examined=0

最近在一個項目中DBA同學問了一個問題：為什麼很多慢查詢日誌中顯示 Rows_examined : 0?

需要說明的是， 這類慢查詢語句都是類似 select count(*) from (…)t;

在說明這個問題之前，我們先指出兩個相關背景:

1、MySQL的暫存資料表，都是MyISAM的。

2、MyISAM表中的記錄總數是額外儲存的，count(*)的時候不需要遍曆資料。

3、把count(*)轉換為取一個const值這件事情，是在最佳化(optimize)階段作的。

問題分析：

這個值對應於代碼中的examined_row_count，用於統計每次執行過程中實際掃描的記錄數。

正常的流程：

查詢執行過程中，每個子查詢的資訊都在curr_join，其中curr_join->examined_rows在每次掃一行的時候++.子查詢完成後，curr_join->examined_rows累積到examined_row_count中。

哪裡清0的？

我們上面這個語句，from內的子查詢，curr_join->examined_rows是正常的，但在外部計算count的時候，上面提到的最佳化結果認為這個階段是不需要掃描表的，把thd->examined_row_count給置0了。罪魁代碼在JOIN::exec()中。

從代碼中的注釋來看，似乎是一個沒有考慮細緻的地方，待求證。

改進分析:

縱然有很多理由，在慢查詢日誌中顯示的0還是不友好的，可以理解為是一個bug。

實際上從上面的分析可知，如果是複合查詢中的一個環節，尤其不是第一個環節，此處清0會使顯示結果出錯。從當前的thd資訊中可以判斷出是否使用了子查詢，簡單一點的修改，根據thd.derived_tables資訊來確定是否清0。

實際上每次執行開始之前的這個值是被reset過的，有理由懷疑這個地方實際上可以直接刪除這句話。這個比較激進，要求證一下。

簡單驗證：

加了thd.derived_tables判斷後，

方便調試起見，把所有的查詢都打到slow_log了。