數據庫中對于每條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_actorsSET 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_instrumentsSET ENABLED = 'YES', TIMED = 'YES'WHERE NAME LIKE '%statement/%';mysql> UPDATE performance_schema.setup_instrumentsSET ENABLED = 'YES', TIMED = 'YES'WHERE NAME LIKE '%stage/%'; mysql> UPDATE performance_schema.setup_consumersSET ENABLED = 'YES'WHERE NAME LIKE '%events_statements_%';mysql> UPDATE performance_schema.setup_consumersSET ENABLED = 'YES'WHERE NAME LIKE '%events_stages_%'; ##查詢執行過得sql 時間ID mysql> SELECT EVENT_ID, TRUNCATE(TIMER_WAIT/1000000000000,6) as Duration, SQL_TEXTFROM 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 DurationFROM 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環境中還可以實踐使用。

總結

以上是生活随笔為你收集整理的MySQL8.0 setup_actors执行时间统计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。