另外也可以看到慢查詢日志中詳細記錄的條目包含了SHOW PROFILE 和SHOW STATUS 所有的輸出並且還有更多的信息所以通過ptquerydigest 發現壞查詢後在慢查詢日志中可以獲得足夠有用的信息查看ptquerydigest 的報告時其標題部分一般會有如下輸出
可以通過這裡的字節偏移值（）直接跳轉到日志的對應部分例如用下面這樣的命令即可
這樣就可以直接跳轉到細節部分了另外ptquerydigest 能夠處理Percona Server 在慢查詢日志中增加的所有鍵值對並且會自動在報告中打印更多的細節信息
使用Performance Schema
在本書寫作之際在MySQL 中新增的Performance Schema 表還不支持查詢級別的剖析信息Performance Schema 還是非常新的特性並且還在快速開發中未來的版本中將會包含更多的功能盡管如此MySQL 的初始版本已經包含了很多有趣的信息例如下面的查詢顯示了系統中等待的主要原因
mysql> SELECT event_name count_star sum_timer_wait
> FROM events_waits_summary_global_by_event_name
> ORDER BY sum_timer_wait DESC LIMIT ;
++++
| event_name | count_star | sum_timer_wait |
++++
| innodb_log_file | | |
| Query_cache::COND_cache_status_changed | | |
| Query_cache::structure_guard_mutex | | |
| innodb_data_file | | |
| dict_table_stats | | |
++++
目前還有一些限制使得Performance Schema 還無法被當作一個通用的剖析工具首先它還無法提供查詢執行階段的細節信息和計時信息而前面提供的很多現有的工具都已經能做到這些了其次還沒有經過長時間大規模使用的驗證並且自身的開銷也還比較大多數比較保守的用戶還對此持有疑問（不過有理由相信這些問題很快都會被修復的）
最後對大多數用戶來說直接通過Performance Schema 的裸數據獲得有用的結果相對來說過於復雜和底層到目前為止實現的這個特性主要是為了測量當為提升服務器性能而修改MySQL 源代碼時使用包括等待和互斥鎖MySQL 中的特性對於高級用戶也很有價值而不僅僅為開發者使用但還是需要開發一些前端工具以方便用戶使用和分析結果目前就只能通過寫一些復雜的語句去查詢大量的元數據表的各種列這在使用過程中需要花很多時間去熟悉和理解
在MySQL 或者以後的版本中Performance Schema 將會包含更多的功能再加上一些方便使用的工具這樣就更爽了而且Oracle 將其實現成表的形式可以通過SQL 訪問這樣用戶可以方便地訪問有用的數據但其目前還無法立即取代慢查詢日志等其他工具用於服務器和查詢的性能優化
返回目錄高性能MySQL
編輯推薦
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
Oracle索引技術
[] []
From:http://tw.wingwit.com/Article/program/MySQL/201311/29707.html
