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