數(shù)據(jù)庫中對于每條sql語句的資源使用情況統(tǒng)計(jì)往往是最頭疼的部分，也是最有效定位問題的方式。除此之外，資源使用情況能協(xié)助DBA確認(rèn) 是否業(yè)務(wù)并發(fā)量上升，硬件資源滿足現(xiàn)有需求，參數(shù)是否有必要調(diào)整 等情況。
目前MySQL提供的機(jī)制里還沒有類似oracle的AWR報(bào)告一樣做的便利又仔細(xì)的，但MySQL也提供了單語句PROFILE命令行，實(shí)際排查故障中提供了很大的幫助。

目前隨著MySQL8.0的普遍，官方介紹里PROFILE語句已準(zhǔn)備棄用，用performance_schema.setup_actors替代。

PROFILE語句顯示當(dāng)前會(huì)話過程中執(zhí)行的語句的資源使用情況。提供以下信息

指標(biāo)說明

ALL	顯示所有性能信息
BLOCK IO	顯示塊IO操作的次數(shù)
CONTEXT SWITCHES	顯示上下文切換次數(shù)，不管是主動(dòng)還是被動(dòng)
CPU	顯示用戶CPU時(shí)間、系統(tǒng)CPU時(shí)間
IPC	顯示發(fā)送和接收的消息數(shù)量
MEMORY	[當(dāng)前沒有實(shí)現(xiàn)]
PAGE FAULTS	顯示頁錯(cuò)誤數(shù)量
SOURCE	顯示源碼中的函數(shù)名稱與位置
SWAPS	顯示SWAP的次數(shù)

其實(shí)使用當(dāng)中，線程級(jí)別，人為操作控制確實(shí)很麻煩。有事收集信息性能壓榨也厲害。

那了解下setup_actors是用什么方式提供資源利用率統(tǒng)計(jì)。

setup_actors

從官方的介紹performance_schema下的setup_actors表可用于限制按主機(jī)、用戶或帳戶收集歷史事件，以減少運(yùn)行時(shí)開銷和歷史表中收集的數(shù)據(jù)量。就是說通過用戶級(jí)別設(shè)置，自動(dòng)對每條SQL統(tǒng)計(jì)資源使用情況。這樣比原先的PROFILE功能更齊全。

默認(rèn)情況下，setup_actors被配置為允許對所有前臺(tái)線程進(jìn)行監(jiān)視和歷史事件收集:但還是不能收集到相關(guān)信息的。但需要開啟收集器instruments才可以的。

1）用戶設(shè)置

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默認(rèn)情況下，目前已經(jīng)開啟wait，stage的sql語句,memory 等780個(gè)指標(biāo)監(jiān)控，就是日常使用的processlist,innodb statu 等信息監(jiān)控。

通過更新setup_instruments表，確保是啟用的。有些指標(biāo)有可能已經(jīng)默認(rèn)啟用。范圍太廣，沒有詳細(xì)的對應(yīng)關(guān)系，就全部開啟。

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_%'; ##查詢執(zhí)行過得sql 時(shí)間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 進(jìn)行查詢，目前只有耗時(shí)。 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個(gè)最近的跨所有線程全局結(jié)束的階段事件。舞臺(tái)活動(dòng)直到結(jié)束后才會(huì)添加到表中。當(dāng)表已滿時(shí)，當(dāng)添加新行時(shí)，最老的行將被丟棄，無論哪一個(gè)線程生成了這一行。events_stages_history_long表允許使用TRUNCATE TABLE方式刪除行

字段說明

THREAD_ID, EVENT_ID	開始時(shí) 線程ID 和 事件ID
END_EVENT_ID	該列在事件開始時(shí)設(shè)置為NULL，并在事件結(jié)束時(shí)更新為線程當(dāng)前事件號(hào)
EVENT_NAME	產(chǎn)生事件的儀器的名稱。這是setup_instruments表中的NAME值
SOURCE	源文件的名稱，其中包含生成事件的經(jīng)過檢測的代碼，以及發(fā)生檢測的文件中的行號(hào)
TIMER_START,TIMER_END, TIMER_WAI	TIMER_START和TIMER_END值表示事件計(jì)時(shí)開始和結(jié)束的時(shí)間。TIMER_WAIT是事件經(jīng)過的時(shí)間(持續(xù)時(shí)間)。皮秒(萬億分之一秒)
WORK_COMPLETED,?WORK_ESTIMATED	WORK_COMPLETED表示該階段已經(jīng)完成了多少工作單元，WORK_ESTIMATED表示該階段預(yù)計(jì)有多少工作單元
NESTING_EVENT_ID	嵌套該事件的事件的EVENT_ID值。事件的嵌套事件通常是語句事件。
NESTING_EVENT_TYPE	嵌套事件類型。取值為TRANSACTION、STATEMENT、STAGE或WAIT。

除此之外外events_stages_history_long 表受參數(shù)影響，只能記錄有限的SQL語句，默認(rèn)1000條

mysql> show variables like '%events_stages_history_long%'; +----------------------------------------------------+-------+ | Variable_name | Value | +----------------------------------------------------+-------+ | performance_schema_events_stages_history_long_size | 10000 | +----------------------------------------------------+-------+

總結(jié)

目前提供的功能非常有限，估計(jì)這個(gè)功能 應(yīng)該再磨煉2年才可以。

• 除了耗時(shí)其他無信息。
• instruments開啟關(guān)閉，無法重置并恢復(fù)初始值。
• 影響范圍和instruments性能消耗，無法評估，還有比較高。
  雖然profile對比不全，但8.0環(huán)境中還可以實(shí)踐使用。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。