作/譯者：葉金榮（Email:[email protected] ），來源：http://imysql.cn，轉載請注明作/譯者和出處，並且不能用於商業用途，違者必究。

原文出自：The new cool MySQL patch has landed! Check your queries performance!，本文做只部分翻譯。

MySQL微秒慢查詢(microtime slow query)補丁包具有以下特色：

• 識別連接

每個慢查詢結果中都記錄了是哪個連接線程引起的，如下：

# Thread_id: 571

• 微秒計數

可以記錄執行時間在1秒一下的慢查詢，選項 long_query_time 的單位現在是微秒，而不是秒，例如設置成300000表示0.3秒。

# Query_time: 0.021752  Lock_time: 0.000016  Rows_sent: 1  Rows_examined: 103

• 記錄復制產生的慢查詢

通常情況下，MySQL並不記錄復制產生的慢查詢，使用該補丁後，只需要打開選項 --log-slow-slave-statements 解決這一問題。


• 詳細的查詢執行計劃

每次查詢的執行計劃都不一樣。可能使用索引掃描，或者全表掃描，或者使用臨時表。通常這些信息也能從 EXPLAIN 結果中得到。該補丁會在日志中顯示了查詢中最重要的幾個方面，如下：

1.  # QC_Hit: No  Full_scan: No  Full_join: No  Tmp_table: Yes  Tmp_table_on_disk: No
2.  # Filesort: Yes  Filesort_on_disk: No  Merge_passes: 0

QC_Hit 表示本次查詢是否命中了查詢緩存(Query Cache)。如果顯示的是 0，則表示該查詢並沒有真正的執行。
如果 Full_scan 的結果為 Yes 表示該查詢比較糟糕，因為需要掃描全表。
Full_join 表示聯合查詢時沒有使用索引。
如果需要創建臨時表，則 Tmp_table 的結果為 Yes；如果需要創建基於磁盤的臨時表而不是基於內存的，則 Disk_tmp_table 的值為 Yes。
如果用到 filesort 算法，則 Filesort 的值為 Yes，Filesort_on_disk 則表示排序是基於臨時文件進行的。


• InnoDB 的使用

最後一部分是InnoDB使用結果的統計。MySQL現在允許運行 SHOW SESSION STATUS 來查看每個線程的統計信息，但是這並不包括InnoDB的使用，因為InnoDB部分而總是顯示全局統計的結果。該補丁允許你查看每次查詢的InnoDB資源使用情況。

#   InnoDB_IO_r_ops: 3  InnoDB_IO_r_bytes: 49152  InnoDB_IO_r_wait: 0.018690
#   InnoDB_rec_lock_wait: 0.000000  InnoDB_queue_wait: 0.000000
#   InnoDB_pages_distinct: 7

InnoDB_IO_r_ops 統計計劃需要讀取的頁數。實際數量可能不太一樣，雖然它可以異步完成，不幸的是並沒有好辦法來衡量它。它的單位是字節(bytes)。
從 InnoDB_IO_r_wait 中可以看到 InnoDB 從存儲引擎中讀取數據鎖等待的時間(單位是秒)。
InnoDB_rec_lock_wait 表示等待行鎖所需時間(單位是秒)。
InnoDB_queue_wait 表示等待進入 InnoDB 隊列或在隊列中等待執行所消耗的時間(單位是秒)。
InnoDB_pages_distinct 顯示了讀取的獨立頁個數。這只是基於用小哈希數組表示的整個緩沖池的近似值，因為有可能需要用很大的內存來映射所有頁。同一個查詢卻產生不准確的讀取頁數量增長可能是發生了哈希沖撞的緣故。
如果查詢中沒有用到InnoDB，則相關日志行變成下面這樣，其他的不變：

# No InnoDB statistics available for this query

注意：盡管該補丁已經做過壓力測試，並且還在實際環境中使用過，但仍然建議不要在非常重要的系統中使用，萬一出了問題，人家可不負責啊 :)