剖析服務器負載（）
服務器端的剖析很有價值因為在服務器端可以有效地審計效率低下的查詢定位和優化壞查詢能夠顯著地提升應用的性能也能解決某些特定的難題還可以降低服務器的整體壓力這樣所有的查詢都將因為減少了對共享資源的爭用而受益（間接的好處）降低服務器的負載也可以推遲或者避免升級更昂貴硬件的需求還可以發現和定位糟糕的用戶體驗比如某些極端情況
MySQL 的每一個新版本中都增加了更多的可測量點如果當前的趨勢可靠的話那麼在性能方面比較重要的測量需求很快能夠在全球范圍內得到支持但如果只是需要剖析並找出代價高的查詢就不需要如此復雜有一個工具很早之前就能幫到我們了這就是慢查詢日志
捕獲MySQL 的查詢到日志文件中
在MySQL 中慢查詢日志最初只是捕獲比較慢的查詢而性能剖析卻需要針對所有的查詢而且在MySQL 及之前的版本中慢查詢日志的響應時間的單位是秒粒度太粗了幸運的是這些限制都已經成為歷史了在MySQL 及更新的版本中慢日志的功能已經被加強可以通過設置long_query_time 為 來捕獲所有的查詢而且查詢的響應時間單位已經可以做到微秒級如果使用的是Percona Server那麼 版本就具備了這些特性而且Percona Server 提供了對日志內容和查詢捕獲的更多控制能力
在MySQL 的當前版本中慢查詢日志是開銷最低精度最高的測量查詢時間的工具如果還在擔心開啟慢查詢日志會帶來額外的I/O 開銷那大可以放心我們在I/O 密集型場景做過基准測試慢查詢日志帶來的開銷可以忽略不計（實際上在CPU 密集型場景的影響還稍微大一些）更需要擔心的是日志可能消耗大量的磁盤空間如果長期開啟慢查詢日志注意要部署日志輪轉（log rotation）工具或者不要長期啟用慢查詢日志只在需要收集負載樣本的期間開啟即可
MySQL 還有另外一種查詢日志被稱之為通用日志但很少用於分析和剖析服務器性能通用日志在查詢請求到服務器時進行記錄所以不包含響應時間和執行計劃等重要信息MySQL 之後支持將日志記錄到數據庫的表中但多數情況下這樣做沒什麼必要這不但對性能有較大影響而且MySQL 在將慢查詢記錄到文件中時已經支持微秒級別的信息然而將慢查詢記錄到表中會導致時間粒度退化為只能到秒級而秒級別的慢查詢日志沒有太大的意義
Percona Server 的慢查詢日志比MySQL 官方版本記錄了更多細節且有價值的信息如查詢執行計劃鎖I/O 活動等這些特性都是隨著處理各種不同的優化場景的需求而慢慢加進來的另外在可管理性上也進行了增強比如全局修改針對每個連接的long_query_time 的阈值這樣當應用使用連接池或者持久連接的時候可以不用重置會話級別的變量而啟動或者停止連接的查詢日志總的來說慢查詢日志是一種輕量而且功能全面的性能剖析工具是優化服務器查詢的利器
有時因為某些原因如權限不足等無法在服務器上記錄查詢這樣的限制我們也常常碰到所以我們開發了兩種替代的技術都集成到了Percona Toolkit 中的ptquerydigest 中第一種是通過processlist 選項不斷查看SHOW FULL PROCESSLIST 的輸出記錄查詢第一次出現的時間和消失的時間某些情況下這樣的精度也足夠發現問題但卻無法捕獲所有的查詢一些執行較快的查詢可能在兩次執行的間隙就執行完成了從而無法捕獲到
第二種技術是通過抓取TCP 網絡包然後根據MySQL 的客戶端/ 服務端通信協議進行解析可以先通過tcpdump 將網絡包數據保存到磁盤然後使用ptquerydigest 的type=tcpdump 選項來解析並分析查詢此方法的精度比較高並且可以捕獲所有查詢還可以解析更高級的協議特性比如可以解析二進制協議從而創建並執行服務端預解析的語句（prepared statement）及壓縮協議另外還有一種方法就是通過MySQLProxy 代理層的腳本來記錄所有查詢但在實踐中我們很少這樣做
[] []
From:http://tw.wingwit.com/Article/program/MySQL/201311/29714.html
