最近在一個項目中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了。