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

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

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

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

1、MySQL的臨時表，都是MyISAM的。

2、MyISAM表中的記錄總數(shù)是額外存儲的，count(*)的時候不需要遍歷數(shù)據。
-
 

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

問題分析：

這個值對應于代碼中的examined_row_count，用于統(tǒng)計每次執(zhí)行過程中實際掃描的記錄數(shù)。

正常的流程：

查詢執(zhí)行過程中，每個子查詢的信息都在curr_join，其中curr_join->examined_rows在每次掃一行的時候++.子查詢完成后，curr_join->examined_rows累積到examined_row_count中。

哪里清0的？

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

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

改進分析:

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

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

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

簡單驗證：

加了thd.derived_tables判斷后，

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

服務器租用/服務器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質保障！--億恩科技[ENKJ.COM]