MySQL8.0 setup_actors执行时间统计

数据库中对于每条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环境中还可以实践使用。

MySQL8.0 setup_actors执行时间统计

setup_actors

总结

猜你喜欢