MySQL的show profile簡介以及該功能在MySQL 5.7中performance_schema中的替代
本文出處:http://www.cnblogs.com/wy123/p/6979499.html
show profile 命令用於跟蹤執行過的sql語句的資源消耗信息,可以幫助查看sql語句的執行情況,可以在做性能分析或者問題診斷的時候作為參考。
在MySQL5.7中, show profile 命令已經開始不推薦使用,MySQL使用performance_schema 中系統表的信息來替代show profile命令
本文簡單介紹一下MySQL的profile使用,以及在MySQL5.7之後的改進,同時與SQL Server中的DMV以及profile和擴展事件做一個簡單的對比,
MySQL5.7尚且支持的show profile
show profile跟蹤記錄SQL執行情況的需要打開配置才能使用
測試執行數次“select count(1) from test_table1;”這個SQL語句,查看執行過的sql的QUERY_ID
然後查看具體的某一個query_id的執行過程
然後可以查看某一個query(執行過的SQL語句)的某一方面的資源消耗信息。
比如show profile cpufor query 82或者是show profile all for query 82;
或者是show profile all for query 82。更多show profile的參數請參考各種參考資料以及官方文檔。
show profile中記錄的信息實際上是存儲在INFORMATION_SCHEMA.PROFILING 這個系統表中的,
各種show profile只不過是相當於一個馬甲,換一種方式來展現INFORMATION_SCHEMA.PROFILING 中的信息。
實話講,個人是不太喜歡系統類似的封裝命令的,倒不如自己直接去定義查詢條件去查詢系統表本身來的更加實在。
MySQL的show profile差不多就是這個功能。
MySQL5.7之後的performance_schema 替代 show profile
首先參考官方文檔https://dev.mysql.com/doc/refman/5.7/en/performance-schema-query-profiling.html
個人理解起來就是將原先存儲在INFORMATION_SCHEMA.PROFILING系統表中的信息換了一個存儲的方式個位置。
這個過程也是支持可配置化的,首先看 performance_schema.setup_actors這個系統表,默認情況下是開啟了profile跟蹤記錄的。
可以在全局級關閉profile記錄跟蹤的功能,而只限定某一個賬號的執行記錄被跟蹤
這裏就重新建賬號了,重現打開默認情況下記錄所有賬號的跟蹤。
然後根據官網的提示,需要打開一個配置選項才能正常記錄profile信息。
執行如下sql。
UPDATE performance_schema.setup_instruments SET ENABLED = ‘YES‘, TIMED = ‘YES‘ WHERE NAME LIKE ‘%statement/%‘; UPDATE performance_schema.setup_instruments SET ENABLED = ‘YES‘, TIMED = ‘YES‘ WHERE NAME LIKE ‘%stage/%‘; UPDATE performance_schema.setup_consumers SET ENABLED = ‘YES‘ WHERE NAME LIKE ‘%events_statements_%‘; UPDATE performance_schema.setup_consumers SET ENABLED = ‘YES‘ WHERE NAME LIKE ‘%events_stages_%‘;
繼續使用上述的sql查詢語句(select count(1) from test_table1)做測試,
然後系統表performance_schema.events_statements_history_long 中可以根據文本信息模糊匹配出之前執行過的SQL語句的信息了
根據上述匹配到的sql語句的Event_id就可以查詢到這個SQL語句在執行過程中的資源消耗信息了。
上面的兩個sql,官當抄來的。
SELECT EVENT_ID, TRUNCATE(TIMER_WAIT/1000000000000,6) as Duration, SQL_TEXT FROM performance_schema.events_statements_history_long WHERE SQL_TEXT like ‘%select count(1) from test_table1%‘; SELECT event_name AS Stage, TRUNCATE(TIMER_WAIT/1000000000000,6) AS Duration FROM performance_schema.events_stages_history_long WHERE NESTING_EVENT_ID=544102;
但是performance_schema 系統表中記錄到的信息,並不能像show profile cpu for query *** 一樣,查詢出來某一類資源的消耗情況。
本身還沒有搜索到相關的等價於show profile cpu for query *** 的系統表,有知道的還望告知,謝謝。
到時某些資料上有這麽一說,在performance_schema 系統表記錄到的信息中:“Does not cover all metrics compared to the native profiling i.e. CONTEXT SWITCHES, BLOCK IO, SWAPS”
也就說相比之前版本的show profile,新的記錄profile的方式還是有待完善的,不知道到目前為止有沒有完善這個功能。
參考:https://www.percona.com/blog/2015/04/16/profiling-mysql-queries-from-performance-schema/
MySQL中的show profile中的信息大概就是這樣子,
參考了一下《深入淺出MySQL》發現提到的show profile在執行的執行給出了警告,表明後續版本中可能會移除這個功能,因此又搜索show profile的替代者。
MySQL的profile信息與SQL Server中的profile簡單的對比
最後簡單地與sqlserver系統表DMV中的類似功能做一下比較,還是有一些比較相似的地方的。
SQL Server可以通過DMV來查詢執行過的SQL的一些信息,比如執行的時間,消耗的CPU時間,執行的邏輯讀寫,物理讀寫等等
不過這個結果還是有一些不一樣的,下面再說。
上述MySQL統計出來的是一個結果強調的是步驟與時間的維度,也即每一步花費了多少時間,
這裏的sqlserver統計出來的是一個整體消耗信息
如果sqlserver想到達到類似也是可以的,最簡單的就是SQL Server中的profile跟蹤結果,也叫profile,看來套路都是一樣的,
另外就是sqlserver中改良過來的擴展事件,參考之前的博文:http://www.cnblogs.com/wy123/p/6835939.html
完全可以拿到Session級別的等待資源和等待時間,這樣子基本上就等同於MySQL中的performance_schema記錄到的信息了。
不過SQL Server 擴展事件捕獲到的這個信息要比MySQL的原始的Profile中INFORMATION_SCHEMA.PROFILING 的更加具體和詳盡了。
在資源消耗和時間維度上有一個更加清晰和直觀的結果。
比如如下的這個截圖,還是那句話,套路都是一樣的,換了個馬甲而已。
如果把擴展事件捕獲到的上述結果,統計起來看,就更像MySQL中的profile信息了。
總結:
profile跟蹤結果可以反饋出來sql執行過程中的資源消耗信息,以提供在做性能優化或者是問題診斷過程中的參考依據,作為DBA在管理和優化數據中的工具
不管是在MySQL中,還是在SQL Server中,功能都是類似的。
當然在問題診斷的時候,僅僅有這些信息,還是不完全夠的,需要其他方面的一些信息做綜合考量。
MySQL的show profile簡介以及該功能在MySQL 5.7中performance_schema中的替代