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中的替代