事件统计|performance_schema全方位介绍

| 导语

专注于为中小企业提供成都网站制作、成都做网站服务,电脑端+手机端+微信端的三站合一,更高效的管理,为中小企业龙潭免费做网站提供优质的服务。我们立足成都，凝聚了一批互联网行业人才，有力地推动了上千家企业的稳健成长，帮助中小企业通过网站建设实现规模扩充和转变。

在上一篇《事件记录 | performance_schema全方位介绍"》中，我们详细介绍了performance_schema的事件记录表，恭喜大家在学习performance_schema的路上度过了两个最困难的时期。现在，相信大家已经比较清楚什么是事件了，但有时候我们不需要知道每时每刻产生的每一条事件记录信息，例如：我们希望了解数据库运行以来一段时间的事件统计数据，这个时候就需要查看事件统计表了。今天将带领大家一起踏上系列第四篇的征程(全系共7个篇章)，在这一期里，我们将为大家全面讲解performance_schema中事件统计表。统计事件表分为5个类别，分别为等待事件、阶段事件、语句事件、事务事件、内存事件。下面，请跟随我们一起开始performance_schema系统的学习之旅吧。

| 等待事件统计表

performance_schema把等待事件统计表按照不同的分组列（不同纬度）对等待事件相关的数据进行聚合（聚合统计数据列包括：事件发生次数，总等待时间，最小、最大、平均等待时间），注意：等待事件的采集功能有一部分默认是禁用的，需要的时候可以通过setup_instruments和setup_objects表动态开启，等待事件统计表包含如下几张表：

点击(此处)折叠或打开

admin@localhost : performance_schema 06:17:11> show tables like '%events_waits_summary%';
+-------------------------------------------------------+
| Tables_in_performance_schema (%events_waits_summary%) |
+-------------------------------------------------------+
| events_waits_summary_by_account_by_event_name |
| events_waits_summary_by_host_by_event_name |
| events_waits_summary_by_instance |
| events_waits_summary_by_thread_by_event_name |
| events_waits_summary_by_user_by_event_name |
| events_waits_summary_global_by_event_name |
+-------------------------------------------------------+
6 rows in set (0.00 sec)

我们先来看看这些表中记录的统计信息是什么样子的。

点击(此处)折叠或打开

# events_waits_summary_by_account_by_event_name表
root@localhost : performance_schema 11:07:09> select * from events_waits_summary_by_account_by_event_name limit 1\G
*************************** 1. row ***************************
USER: NULL
HOST: NULL
EVENT_NAME: wait/synch/mutex/sql/TC_LOG_MMAP::LOCK_tc
COUNT_STAR: 0
SUM_TIMER_WAIT: 0
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 0
MAX_TIMER_WAIT: 0
1 row in set (0.00 sec)
# events_waits_summary_by_host_by_event_name表
root@localhost : performance_schema 11:07:14> select * from events_waits_summary_by_host_by_event_name limit 1\G
*************************** 1. row ***************************
HOST: NULL
EVENT_NAME: wait/synch/mutex/sql/TC_LOG_MMAP::LOCK_tc
COUNT_STAR: 0
SUM_TIMER_WAIT: 0
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 0
MAX_TIMER_WAIT: 0
1 row in set (0.00 sec)
# events_waits_summary_by_instance表
root@localhost : performance_schema 11:08:05> select * from events_waits_summary_by_instance limit 1\G
*************************** 1. row ***************************
EVENT_NAME: wait/synch/mutex/mysys/THR_LOCK_heap
OBJECT_INSTANCE_BEGIN: 32492032
COUNT_STAR: 0
SUM_TIMER_WAIT: 0
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 0
MAX_TIMER_WAIT: 0
1 row in set (0.00 sec)
# events_waits_summary_by_thread_by_event_name表
root@localhost : performance_schema 11:08:23> select * from events_waits_summary_by_thread_by_event_name limit 1\G
*************************** 1. row ***************************
THREAD_ID: 1
EVENT_NAME: wait/synch/mutex/sql/TC_LOG_MMAP::LOCK_tc
COUNT_STAR: 0
SUM_TIMER_WAIT: 0
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 0
MAX_TIMER_WAIT: 0
1 row in set (0.00 sec)
# events_waits_summary_by_user_by_event_name表
root@localhost : performance_schema 11:08:36> select * from events_waits_summary_by_user_by_event_name limit 1\G
*************************** 1. row ***************************
USER: NULL
EVENT_NAME: wait/synch/mutex/sql/TC_LOG_MMAP::LOCK_tc
COUNT_STAR: 0
SUM_TIMER_WAIT: 0
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 0
MAX_TIMER_WAIT: 0
1 row in set (0.00 sec)
# events_waits_summary_global_by_event_name表
root@localhost : performance_schema 11:08:53> select * from events_waits_summary_global_by_event_name limit 1\G
*************************** 1. row ***************************
EVENT_NAME: wait/synch/mutex/sql/TC_LOG_MMAP::LOCK_tc
COUNT_STAR: 0
SUM_TIMER_WAIT: 0
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 0
MAX_TIMER_WAIT: 0
1 row in set (0.00 sec)

从上面表中的示例记录信息中，我们可以看到：

每个表都有各自的一个或多个分组列，以确定如何聚合事件信息（所有表都有EVENT_NAME列，列值与setup_instruments表中NAME列值对应），如下：

events_waits_summary_by_account_by_event_name表：按照列EVENT_NAME、USER、HOST进行分组事件信息

events_waits_summary_by_host_by_event_name表：按照列EVENT_NAME、HOST进行分组事件信息

events_waits_summary_by_instance表：按照列EVENT_NAME、OBJECT_INSTANCE_BEGIN进行分组事件信息。如果一个instruments(event_name)创建有多个实例，则每个实例都具有唯一的OBJECT_INSTANCE_BEGIN值，因此每个实例会进行单独分组

events_waits_summary_by_thread_by_event_name表：按照列THREAD_ID、EVENT_NAME进行分组事件信息

events_waits_summary_by_user_by_event_name表：按照列EVENT_NAME、USER进行分组事件信息

events_waits_summary_global_by_event_name表：按照EVENT_NAME列进行分组事件信息

所有表的统计列（数值型）都为如下几个：

COUNT_STAR：事件被执行的数量。此值包括所有事件的执行次数，需要启用等待事件的instruments

SUM_TIMER_WAIT：统计给定计时事件的总等待时间。此值仅针对有计时功能的事件instruments或开启了计时功能事件的instruments，如果某事件的instruments不支持计时或者没有开启计时功能，则该字段为NULL。其他xxx_TIMER_WAIT字段值类似

MIN_TIMER_WAIT：给定计时事件的最小等待时间

AVG_TIMER_WAIT：给定计时事件的平均等待时间

MAX_TIMER_WAIT：给定计时事件的最大等待时间

PS：等待事件统计表允许使用TRUNCATE TABLE语句。

执行该语句时有如下行为：

对于未按照帐户、主机、用户聚合的统计表，truncate语句会将统计列值重置为零，而不是删除行。

对于按照帐户、主机、用户聚合的统计表，truncate语句会删除已开端连接的帐户，主机或用户对应的行，并将其他有连接的行的统计列值重置为零（实测跟未按照帐号、主机、用户聚合的统计表一样，只会被重置不会被删除）。

此外，按照帐户、主机、用户、线程聚合的每个等待事件统计表或者events_waits_summary_global_by_event_name表，如果依赖的连接表(accounts、hosts、users表)执行truncate时，那么依赖的这些表中的统计数据也会同时被隐式truncate 。

注意：这些表只针对等待事件信息进行统计，即包含setup_instruments表中的wait/%开头的采集器+ idle空闲采集器，每个等待事件在每个表中的统计记录行数需要看如何分组（例如：按照用户分组统计的表中，有多少个活跃用户，表中就会有多少条相同采集器的记录），另外，统计计数器是否生效还需要看setup_instruments表中相应的等待事件采集器是否启用。

| 阶段事件统计表

performance_schema把阶段事件统计表也按照与等待事件统计表类似的规则进行分类聚合，阶段事件也有一部分是默认禁用的，一部分是开启的，阶段事件统计表包含如下几张表：

点击(此处)折叠或打开

admin@localhost : performance_schema 06:23:02> show tables like '%events_stages_summary%';
+--------------------------------------------------------+
| Tables_in_performance_schema (%events_stages_summary%) |
+--------------------------------------------------------+
| events_stages_summary_by_account_by_event_name |
| events_stages_summary_by_host_by_event_name |
| events_stages_summary_by_thread_by_event_name |
| events_stages_summary_by_user_by_event_name |
| events_stages_summary_global_by_event_name |
+--------------------------------------------------------+
5 rows in set (0.00 sec)

我们先来看看这些表中记录的统计信息是什么样子的。

点击(此处)折叠或打开

# events_stages_summary_by_account_by_event_name表
root@localhost : performance_schema 11:21:04> select * from events_stages_summary_by_account_by_event_name where USER is not null limit 1\G
*************************** 1. row ***************************
USER: root
HOST: localhost
EVENT_NAME: stage/sql/After create
COUNT_STAR: 0
SUM_TIMER_WAIT: 0
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 0
MAX_TIMER_WAIT: 0
1 row in set (0.01 sec)
# events_stages_summary_by_host_by_event_name表
root@localhost : performance_schema 11:29:27> select * from events_stages_summary_by_host_by_event_name where HOST is not null limit 1\G
*************************** 1. row ***************************
HOST: localhost
EVENT_NAME: stage/sql/After create
COUNT_STAR: 0
SUM_TIMER_WAIT: 0
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 0
MAX_TIMER_WAIT: 0
1 row in set (0.00 sec)
# events_stages_summary_by_thread_by_event_name表
root@localhost : performance_schema 11:37:03> select * from events_stages_summary_by_thread_by_event_name where thread_id is not null limit 1\G
*************************** 1. row ***************************
THREAD_ID: 1
EVENT_NAME: stage/sql/After create
COUNT_STAR: 0
SUM_TIMER_WAIT: 0
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 0
MAX_TIMER_WAIT: 0
1 row in set (0.01 sec)
# events_stages_summary_by_user_by_event_name表
root@localhost : performance_schema 11:42:37> select * from events_stages_summary_by_user_by_event_name where user is not null limit 1\G
*************************** 1. row ***************************
USER: root
EVENT_NAME: stage/sql/After create
COUNT_STAR: 0
SUM_TIMER_WAIT: 0
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 0
MAX_TIMER_WAIT: 0
1 row in set (0.00 sec)
# events_stages_summary_global_by_event_name表
root@localhost : performance_schema 11:43:03> select * from events_stages_summary_global_by_event_name limit 1\G
*************************** 1. row ***************************
EVENT_NAME: stage/sql/After create
COUNT_STAR: 0
SUM_TIMER_WAIT: 0
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 0
MAX_TIMER_WAIT: 0
1 row in set (0.00 sec)

从上面表中的示例记录信息中，我们可以看到，同样与等待事件类似，按照用户、主机、用户+主机、线程等纬度进行分组与统计的列，这些列的含义与等待事件类似，这里不再赘述。

注意：这些表只针对阶段事件信息进行统计，即包含setup_instruments表中的stage/%开头的采集器，每个阶段事件在每个表中的统计记录行数需要看如何分组（例如：按照用户分组统计的表中，有多少个活跃用户，表中就会有多少条相同采集器的记录），另外，统计计数器是否生效还需要看setup_instruments表中相应的阶段事件采集器是否启用。

PS：对这些表使用truncate语句，影响与等待事件类似。

| 事务事件统计表

performance_schema把事务事件统计表也按照与等待事件统计表类似的规则进行分类统计，事务事件instruments只有一个transaction，默认禁用，事务事件统计表有如下几张表：

点击(此处)折叠或打开

admin@localhost : performance_schema 06:37:45> show tables like '%events_transactions_summary%';
+--------------------------------------------------------------+
| Tables_in_performance_schema (%events_transactions_summary%) |
+--------------------------------------------------------------+
| events_transactions_summary_by_account_by_event_name |
| events_transactions_summary_by_host_by_event_name |
| events_transactions_summary_by_thread_by_event_name |
| events_transactions_summary_by_user_by_event_name |
| events_transactions_summary_global_by_event_name |
+--------------------------------------------------------------+
5 rows in set (0.00 sec)

我们先来看看这些表中记录的统计信息是什么样子的（由于单行记录较长，这里只列出events_transactions_summary_by_account_by_event_name表中的示例数据，其余表的示例数据省略掉部分相同字段）。

点击(此处)折叠或打开

# events_transactions_summary_by_account_by_event_name表
root@localhost : performance_schema 01:19:07> select * from events_transactions_summary_by_account_by_event_name where COUNT_STAR!=0 limit 1\G
*************************** 1. row ***************************
USER: root
HOST: localhost
EVENT_NAME: transaction
COUNT_STAR: 7
SUM_TIMER_WAIT: 8649707000
MIN_TIMER_WAIT: 57571000
AVG_TIMER_WAIT: 1235672000
MAX_TIMER_WAIT: 2427645000
COUNT_READ_WRITE: 6
SUM_TIMER_READ_WRITE: 8592136000
MIN_TIMER_READ_WRITE: 87193000
AVG_TIMER_READ_WRITE: 1432022000
MAX_TIMER_READ_WRITE: 2427645000
COUNT_READ_ONLY: 1
SUM_TIMER_READ_ONLY: 57571000
MIN_TIMER_READ_ONLY: 57571000
AVG_TIMER_READ_ONLY: 57571000
MAX_TIMER_READ_ONLY: 57571000
1 row in set (0.00 sec)
# events_transactions_summary_by_host_by_event_name表
root@localhost : performance_schema 01:25:13> select * from events_transactions_summary_by_host_by_event_name where COUNT_STAR!=0 limit 1\G
*************************** 1. row ***************************
HOST: localhost
EVENT_NAME: transaction
COUNT_STAR: 7
......
1 row in set (0.00 sec)
# events_transactions_summary_by_thread_by_event_name表
root@localhost : performance_schema 01:25:27> select * from events_transactions_summary_by_thread_by_event_name where SUM_TIMER_WAIT!=0\G
*************************** 1. row ***************************
THREAD_ID: 46
EVENT_NAME: transaction
COUNT_STAR: 7
......
1 row in set (0.00 sec)
# events_transactions_summary_by_user_by_event_name表
root@localhost : performance_schema 01:27:27> select * from events_transactions_summary_by_user_by_event_name where SUM_TIMER_WAIT!=0\G
*************************** 1. row ***************************
USER: root
EVENT_NAME: transaction
COUNT_STAR: 7
......
1 row in set (0.00 sec)
# events_transactions_summary_global_by_event_name表
root@localhost : performance_schema 01:27:32> select * from events_transactions_summary_global_by_event_name where SUM_TIMER_WAIT!=0\G
*************************** 1. row ***************************
EVENT_NAME: transaction
COUNT_STAR: 7
......
1 row in set (0.00 sec)

从上面表中的示例记录信息中，我们可以看到，同样与等待事件类似，按照用户、主机、用户+主机、线程等纬度进行分组与统计的列，这些列的含义与等待事件类似，这里不再赘述，但对于事务统计事件，针对读写事务和只读事务还单独做了统计(xx_READ_WRITE和xx_READ_ONLY列，只读事务需要设置只读事务变量transaction_read_only=on才会进行统计)。

注意：这些表只针对事务事件信息进行统计，即包含且仅包含setup_instruments表中的transaction采集器，每个事务事件在每个表中的统计记录行数需要看如何分组（例如：按照用户分组统计的表中，有多少个活跃用户，表中就会有多少条相同采集器的记录），另外，统计计数器是否生效还需要看transaction采集器是否启用。

事务聚合统计规则

* 事务事件的收集不考虑隔离级别，访问模式或自动提交模式

* 读写事务通常比只读事务占用更多资源，因此事务统计表包含了用于读写和只读事务的单独统计列

* 事务所占用的资源需求多少也可能会因事务隔离级别有所差异(例如：锁资源)。但是：每个server可能是使用相同的隔离级别，所以不单独提供隔离级别相关的统计列

PS：对这些表使用truncate语句，影响与等待事件类似。

| 语句事件统计表

performance_schema把语句事件统计表也按照与等待事件统计表类似的规则进行分类统计，语句事件instruments默认全部开启，所以，语句事件统计表中默认会记录所有的语句事件统计信息，语句事件统计表包含如下几张表：

events_statements_summary_by_account_by_event_name：按照每个帐户和语句事件名称进行统计

events_statements_summary_by_digest：按照每个库级别对象和语句事件的原始语句文本统计值（md5 hash字符串）进行统计，该统计值是基于事件的原始语句文本进行精炼(原始语句转换为标准化语句)，每行数据中的相关数值字段是具有相同统计值的统计结果。

events_statements_summary_by_host_by_event_name：按照每个主机名和事件名称进行统计的Statement事件

events_statements_summary_by_program：按照每个存储程序（存储过程和函数，触发器和事件）的事件名称进行统计的Statement事件

events_statements_summary_by_thread_by_event_name：按照每个线程和事件名称进行统计的Statement事件

events_statements_summary_by_user_by_event_name：按照每个用户名和事件名称进行统计的Statement事件

events_statements_summary_global_by_event_name：按照每个事件名称进行统计的Statement事件

prepared_statements_instances：按照每个prepare语句实例聚合的统计信息

可通过如下语句查看语句事件统计表：

点击(此处)折叠或打开

admin@localhost : performance_schema 06:27:58> show tables like '%events_statements_summary%';
+------------------------------------------------------------+
| Tables_in_performance_schema (%events_statements_summary%) |
+------------------------------------------------------------+
| events_statements_summary_by_account_by_event_name |
| events_statements_summary_by_digest |
| events_statements_summary_by_host_by_event_name |
| events_statements_summary_by_program |
| events_statements_summary_by_thread_by_event_name |
| events_statements_summary_by_user_by_event_name |
| events_statements_summary_global_by_event_name |
+------------------------------------------------------------+
7 rows in set (0.00 sec)
admin@localhost : performance_schema 06:28:48> show tables like '%prepare%';
+------------------------------------------+
| Tables_in_performance_schema (%prepare%) |
+------------------------------------------+
| prepared_statements_instances |
+------------------------------------------+
1 row in set (0.00 sec)

我们先来看看这些表中记录的统计信息是什么样子的（由于单行记录较长，这里只列出events_statements_summary_by_account_by_event_name 表中的示例数据，其余表的示例数据省略掉部分相同字段）。

点击(此处)折叠或打开

# events_statements_summary_by_account_by_event_name表
root@localhost : performance_schema 10:37:27> select * from events_statements_summary_by_account_by_event_name where COUNT_STAR!=0 limit 1\G
*************************** 1. row ***************************
USER: root
HOST: localhost
EVENT_NAME: statement/sql/select
COUNT_STAR: 53
SUM_TIMER_WAIT: 234614735000
MIN_TIMER_WAIT: 72775000
AVG_TIMER_WAIT: 4426693000
MAX_TIMER_WAIT: 80968744000
SUM_LOCK_TIME: 26026000000
SUM_ERRORS: 2
SUM_WARNINGS: 0
SUM_ROWS_AFFECTED: 0
SUM_ROWS_SENT: 1635
SUM_ROWS_EXAMINED: 39718
SUM_CREATED_TMP_DISK_TABLES: 3
SUM_CREATED_TMP_TABLES: 10
SUM_SELECT_FULL_JOIN: 21
SUM_SELECT_FULL_RANGE_JOIN: 0
SUM_SELECT_RANGE: 0
SUM_SELECT_RANGE_CHECK: 0
SUM_SELECT_SCAN: 45
SUM_SORT_MERGE_PASSES: 0
SUM_SORT_RANGE: 0
SUM_SORT_ROWS: 170
SUM_SORT_SCAN: 6
SUM_NO_INDEX_USED: 42
SUM_NO_GOOD_INDEX_USED: 0
1 row in set (0.00 sec)
# events_statements_summary_by_digest表
root@localhost : performance_schema 11:01:51> select * from events_statements_summary_by_digest limit 1\G
*************************** 1. row ***************************
SCHEMA_NAME: NULL
DIGEST: 4fb483fe710f27d1d06f83573c5ce11c
DIGEST_TEXT: SELECT @@`version_comment` LIMIT ?
COUNT_STAR: 3
......
FIRST_SEEN: 2018-05-19 22:33:50
LAST_SEEN: 2018-05-20 10:24:42
1 row in set (0.00 sec)
# events_statements_summary_by_host_by_event_name表
root@localhost : performance_schema 11:02:15> select * from events_statements_summary_by_host_by_event_name where COUNT_STAR!=0 limit 1\G
*************************** 1. row ***************************
HOST: localhost
EVENT_NAME: statement/sql/select
COUNT_STAR: 55
......
1 row in set (0.00 sec)
# events_statements_summary_by_program表(需要调用了存储过程或函数之后才会有数据)
root@localhost : performance_schema 12:34:43> select * from events_statements_summary_by_program\G;
*************************** 1. row ***************************
OBJECT_TYPE: PROCEDURE
OBJECT_SCHEMA: sys
OBJECT_NAME: ps_setup_enable_consumer
COUNT_STAR: 1
............
1 row in set (0.00 sec)
# events_statements_summary_by_thread_by_event_name表
root@localhost : performance_schema 11:03:19> select * from events_statements_summary_by_thread_by_event_name where COUNT_STAR!=0 limit 1\G
*************************** 1. row ***************************
THREAD_ID: 47
EVENT_NAME: statement/sql/select
COUNT_STAR: 11
......
1 row in set (0.01 sec)
# events_statements_summary_by_user_by_event_name表
root@localhost : performance_schema 11:04:10> select * from events_statements_summary_by_user_by_event_name where COUNT_STAR!=0 limit 1\G
*************************** 1. row ***************************
USER: root
EVENT_NAME: statement/sql/select
COUNT_STAR: 58
......
1 row in set (0.00 sec)
# events_statements_summary_global_by_event_name表
root@localhost : performance_schema 11:04:31> select * from events_statements_summary_global_by_event_name limit 1\G
***********************
本文标题：事件统计|performance_schema全方位介绍
本文路径：http://cqcxhl.cn/article/jihpig.html