數據庫中對于每條sql語句的資源使用情況統計往往是最頭疼的部分，也是最有效定位問題的方式。除此之外，資源使用情況能協助DBA確認 是否業務并發量上升，硬件資源滿足現有需求，參數是否有必要調整 等情況。
目前MySQL提供的機制里還沒有類似oracle的AWR報告一樣做的便利又仔細的，但MySQL也提供了單語句PROFILE命令行，實際排查故障中提供了很大的幫助。
目前隨著MySQL8.0的普遍，官方介紹里PROFILE語句已準備棄用，用performance_schema.setup_actors替代。
PROFILE語句顯示當前會話過程中執行的語句的資源使用情況。提供以下信息
| 指標 | 說明 |
|---|---|
| ALL | 顯示所有性能信息 |
| BLOCK IO | 顯示塊IO操作的次數 |
| CONTEXT SWITCHES | 顯示上下文切換次數，不管是主動還是被動 |
| CPU | 顯示用戶CPU時間、系統CPU時間 |
| IPC | 顯示發送和接收的消息數量 |
| MEMORY | [當前沒有實現] |
| PAGE FAULTS | 顯示頁錯誤數量 |
| SOURCE | 顯示源碼中的函數名稱與位置 |
| SWAPS | 顯示SWAP的次數 |
其實使用當中，線程級別，人為操作控制確實很麻煩。有事收集信息性能壓榨也厲害。
那了解下setup_actors是用什么方式提供資源利用率統計。
setup_actors
從官方的介紹performance_schema下的setup_actors表可用于限制按主機、用戶或帳戶收集歷史事件，以減少運行時開銷和歷史表中收集的數據量。就是說通過用戶級別設置，自動對每條SQL統計資源使用情況。這樣比原先的PROFILE功能更齊全。
默認情況下，setup_actors被配置為允許對所有前臺線程進行監視和歷史事件收集:但還是不能收集到相關信息的。但需要開啟收集器instruments才可以的。
1）用戶設置
mysql> SELECT * FROM performance_schema.setup_actors;
+------+------+------+---------+---------+
| HOST | USER | ROLE | ENABLED | HISTORY |
+------+------+------+---------+---------+
| % | % | % | YES | YES |
+------+------+------+---------+---------+
1 row in set (0.00 sec)
mysql> UPDATE performance_schema.setup_actors
SET ENABLED = 'NO', HISTORY = 'NO'
WHERE HOST = '%' AND USER = '%';
mysql> INSERT INTO performance_schema.setup_actors
(HOST,USER,ROLE,ENABLED,HISTORY)
VALUES('localhost','root','%','YES','YES');
mysql> SELECT * FROM performance_schema.setup_actors;
+-----------+------+------+---------+---------+
| HOST | USER | ROLE | ENABLED | HISTORY |
+-----------+------+------+---------+---------+
| % | % | % | NO | NO |
| localhost | root | % | YES | YES |
+-----------+------+------+---------+---------+
2 rows in set (0.00 sec)
2）setup_instruments開啟
instruments默認情況下，目前已經開啟wait，stage的sql語句,memory 等780個指標監控，就是日常使用的processlist,innodb statu 等信息監控。
通過更新setup_instruments表，確保是啟用的。有些指標有可能已經默認啟用。范圍太廣，沒有詳細的對應關系，就全部開啟。
mysql> UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME LIKE '%statement/%';
mysql> UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME LIKE '%stage/%';
mysql> UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME LIKE '%events_statements_%';
mysql> UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME LIKE '%events_stages_%';
##查詢執行過得sql 時間ID
mysql> SELECT EVENT_ID, TRUNCATE(TIMER_WAIT/1000000000000,6) as Duration, SQL_TEXT
FROM performance_schema.events_statements_history_long WHERE SQL_TEXT like '%t1%';
+----------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| EVENT_ID | Duration | SQL_TEXT |
+----------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 48 | 0.0065 | select *from db1.t1 |
| 84 | 0.0004 | select * from db1.t1 |
| 41 | 0.0082 | SELECT /*!40001 SQL_NO_CACHE */ * FROM `test1` |
+----------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
#再通過事件ID 進行查詢，目前只有耗時。
mysql> SELECT event_name AS Stage, TRUNCATE(TIMER_WAIT/1000000000000,6) AS Duration
FROM performance_schema.events_stages_history_long WHERE NESTING_EVENT_ID=41;
備注：events_stages_history_long表包含N個最近的跨所有線程全局結束的階段事件。舞臺活動直到結束后才會添加到表中。當表已滿時，當添加新行時，最老的行將被丟棄，無論哪一個線程生成了這一行。events_stages_history_long表允許使用TRUNCATE TABLE方式刪除行
| 字段 | 說明 |
|---|---|
| THREAD_ID, EVENT_ID | 開始時 線程ID 和 事件ID |
| END_EVENT_ID | 該列在事件開始時設置為NULL，并在事件結束時更新為線程當前事件號 |
| EVENT_NAME | 產生事件的儀器的名稱。這是setup_instruments表中的NAME值 |
| SOURCE | 源文件的名稱，其中包含生成事件的經過檢測的代碼，以及發生檢測的文件中的行號 |
| TIMER_START,TIMER_END, TIMER_WAI | TIMER_START和TIMER_END值表示事件計時開始和結束的時間。TIMER_WAIT是事件經過的時間(持續時間)。皮秒(萬億分之一秒) |
| WORK_COMPLETED,?WORK_ESTIMATED | WORK_COMPLETED表示該階段已經完成了多少工作單元，WORK_ESTIMATED表示該階段預計有多少工作單元 |
| NESTING_EVENT_ID | 嵌套該事件的事件的EVENT_ID值。事件的嵌套事件通常是語句事件。 |
| NESTING_EVENT_TYPE | 嵌套事件類型。取值為TRANSACTION、STATEMENT、STAGE或WAIT。 |
除此之外外events_stages_history_long 表受參數影響，只能記錄有限的SQL語句，默認1000條
mysql> show variables like '%events_stages_history_long%';
+----------------------------------------------------+-------+
| Variable_name | Value |
+----------------------------------------------------+-------+
| performance_schema_events_stages_history_long_size | 10000 |
+----------------------------------------------------+-------+
總結
目前提供的功能非常有限，估計這個功能 應該再磨煉2年才可以。
- 除了耗時其他無信息。
- instruments開啟關閉，無法重置并恢復初始值。
- 影響范圍和instruments性能消耗，無法評估，還有比較高。
雖然profile對比不全，但8.0環境中還可以實踐使用。
