罗小波·沃趣科技高级数据库技术专家

原标题:事件总括 | performance_schema全方位介绍(四)

js金沙 1

罗小波·沃趣科学和技术尖端数据库手艺专家

产品:沃趣科学技术

IT从业多年,历任运行程序员、高等运营技术员、运行首席营业官、数据库程序员,曾参预版本发表系统、轻量级监察和控制种类、运转管理平台、数据库管理平台的设计与编辑,熟练MySQL种类布局,Innodb存款和储蓄引擎,喜好专研开源手艺,追求左右逢源。

| 导语

在上一篇《事件记录 |
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 |

+——————————————————-+

6rows inset ( 0. 00sec)

大家先来探视这一个表中记录的总结新闻是怎么着体统的。

# 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 1G

*************************** 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 1G

*************************** 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 1G

*************************** 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 1G

*************************** 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 1G

*************************** 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 1G

*************************** 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、USEXC60、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、USELacrosse举办分组事件音讯

events_waits_summary_global_by_event_name表:按照EVENT_NAME列实行分组事件新闻

全体表的总结列(数值型)都为如下多少个:

COUNT_STA安德拉:事件被实行的数码。此值满含全体事件的试行次数,须求启用等待事件的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 |

+——————————————————–+

5rows inset ( 0. 00sec)

大家先来会见这一个表中著录的总结音信是什么样样子的。

# 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 1G

*************************** 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_js金沙 ,stages _summary_by _host_by _event_name where HOST is not
null limit 1G

*************************** 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 1G

*************************** 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 1G

*************************** 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 1G

*************************** 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 |

+————————————————————–+

5rows inset ( 0. 00sec)

我们先来探视这个表中记录的总括音讯是哪些体统的(由于单行记录较长,这里只列出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 1G

*************************** 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 1G

*************************** 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!=0G

*************************** 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!=0G

*************************** 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!=0G

*************************** 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 |

+————————————————————+

7rows inset ( 0. 00sec)

admin@localhost : performance_schema 06:28:48> show tables like
‘%prepare%’;

+——————————————+

| Tables_in_performance_schema (%prepare%) |

+——————————————+

| prepared_statements_instances |

+——————————————+

1row inset ( 0. 00sec)

我们先来寻访那么些表中记录的计算新闻是什么样子的(由于单行记录较长,这里只列出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 1G

*************************** 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 1G

*************************** 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 1G

*************************** 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_programG;

*************************** 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 1G

*************************** 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 1G

*************************** 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 1G

*************************** 1. row
***************************

EVENT_NAME: statement/sql/select

COUNT_STAR: 59

……

1 row in set (0.00 sec)

从上面表中的演示记录音讯中,大家得以看来,一样与等待事件类似,根据客商、主机、客商+主机、线程等纬度进行分组与总计的列,分组和部分日子计算列与等待事件类似,这里不再赘述,但对于语句总结事件,有指向语句对象的附加的计算列,如下:

SUM_xxx:针对events_statements_*事件记录表中相应的xxx列举行总计。譬如:语句计算表中的SUM_LOCK_TIME和SUM_ERRORS列对events_statements_current事件记录表中LOCK_TIME和ERRO锐界S列进行计算

events_statements_summary_by_digest表有和煦额外的总计列:

*
FIRST_SEEN,LAST_SEEN:展现某给定语句第叁回插入
events_statements_summary_by_digest表和最终叁回立异该表的时光戳

events_statements_summary_by_program表有友好额外的计算列:

*
COUNT_STATEMENTS,SUM_STATEMENTS_WAIT,MIN_STATEMENTS_WAIT,AVG_STATEMENTS_WAIT,MAX_STATEMENTS_WAIT:关于存款和储蓄程序试行时期调用的嵌套语句的总计音信

prepared_statements_instances表有谈得来额外的总计列:

*
COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE:实行prepare语句对象的总计音信

PS1:

关于events_statements_summary_by_digest表

如果setup_consumers配置表中statements_digest
consumers启用,则在言辞施行到位时,将会把讲话文本举行md5 hash总括之后
再发送到events_statements_summary_by_digest表中。分组列基于该语句的DIGEST列值(md5
hash值)

*
倘若给定语句的计算音讯行在events_statements_summary_by_digest表中已经存在,则将该语句的总结音信实行立异,并更新LAST_SEEN列值为当下时刻

*
假设给定语句的计算新闻行在events_statements_summary_by_digest表中尚无已存在行,并且events_statements_summary_by_digest表空间限制未满的意况下,会在events_statements_summary_by_digest表中新插入一行总括新闻,FI宝马X3ST_SEEN和LAST_SEEN列都利用领后天子

*
假使给定语句的总结音讯行在events_statements_summary_by_digest表中从未已存在行,且events_statements_summary_by_digest表空间限制已满的意况下,则该语句的总计音讯将丰盛到DIGEST
列值为
NULL的特种“catch-all”行,假诺该特别行不设有则新插入一行,FI路虎极光ST_SEEN和LAST_SEEN列为当前岁月。倘诺该非常行已存在则更新该行的音信,LAST_SEEN为当前几日子

由于performance_schema表内部存款和储蓄器限制,所以爱戴了DIGEST
= NULL的特殊行。
当events_statements_summary_by_digest表限制体积已满的场馆下,且新的讲话总计音讯在需求插入到该表时又尚未在该表中找到相配的DIGEST列值时,就能够把这几个语句总括音信都总计到
DIGEST =
NULL的行中。此行可援救您猜想events_statements_summary_by_digest表的界定是或不是需求调治

* 如果DIGEST =
NULL行的COUNT_STAEvoque列值攻下整个表中全数总结新闻的COUNT_STASportage列值的百分比大于0%,则表示存在由于该表限制已满导致部分语句计算新闻不可能归类保存,借使您要求保留全体语句的计算消息,能够在server运行在此之前调治系统变量performance_schema_digests_size的值,暗许大小为200

PS2:至于存款和储蓄程序监察和控制行为:对于在setup_objects表中启用了instruments的储存程序类型,events_statements_summary_by_program将维护存款和储蓄程序的总括信息,如下所示:

当某给定对象在server中第三遍被使用时(即利用call语句调用了仓库储存进程或自定义存储函数时),将在events_statements_summary_by_program表中增添一行总括音信;

当某给定对象被剔除时,该指标在events_statements_summary_by_program表中的总结音讯将在被删除;

当某给定对象被实行时,其对应的总结信息将记录在events_statements_summary_by_program表中并开展总计。

PS3:对这几个表使用truncate语句,影响与等待事件类似。

| 内存事件计算表

performance_schema把内部存款和储蓄器事件计算表也如约与等待事件计算表类似的法规进行分类总结。

performance_schema会记录内部存款和储蓄器使用状态并集合内部存款和储蓄器使用总括消息,如:使用的内部存款和储蓄器类型(各个缓存,内部缓冲区等)和线程、帐号、客商、主机的相干操作间接进行的内部存款和储蓄器操作。performance_schema从使用的内部存款和储蓄器大小、相关操作数量、高低水位(内部存款和储蓄器叁遍操作的最大和纤维的连带计算值)。

内部存款和储蓄器大小计算音讯有利于了然当前server的内部存款和储蓄器消耗,以便及时开展内部存款和储蓄器调节。内部存款和储蓄器相关操作计数有利于理解当前server的内部存款和储蓄器分配器的总体压力,及时精晓server品质数据。比方:分配单个字节一百万次与单次分配一百万个字节的属性耗费是见仁见智的,通过追踪内部存款和储蓄器分配器分配的内部存储器大小和分红次数就能够理解互相的差异。

检查实验内存专门的学问负荷峰值、内部存款和储蓄器总体的行事负荷牢固性、大概的内部存款和储蓄器泄漏等是最首要的。

内部存款和储蓄器事件instruments中除去performance_schema本人内部存款和储蓄器分配相关的事件instruments配置默许开启之外,别的的内存事件instruments配置都暗许关闭的,且在setup_consumers表中尚无像等待事件、阶段事件、语句事件与业务事件那样的独门布署项。

PS:内存总计表不含有计时消息,因为内部存款和储蓄器事件不帮衬时间音讯采撷。

内部存款和储蓄器事件总结表有如下几张表:

admin@localhost : performance_schema 06:56:56> show tables like
‘%memory%summary%’;

+————————————————-+

| Tables_in_performance_schema (%memory%summary%) |

+————————————————-+

| memory_summary_by_account_by_event_name |

| memory_summary_by_host_by_event_name |

| memory_summary_by_thread_by_event_name |

| memory_summary_by_user_by_event_name |

| memory_summary_global_by_event_name |

+————————————————-+

5rows inset ( 0. 00sec)

我们先来走访那么些表中著录的总结信息是什么样子的(由于单行记录较长,这里只列出memory_summary_by_account_by_event_name
表中的示例数据,其他表的亲自去做数据省略掉一部分一样字段)。

# 要是急需总结内部存款和储蓄器事件新闻,须要敞开内部存储器事件搜罗器

root@localhost : performance _schema 11:50:46> update
setup_instruments set enabled=’yes’,timed=’yes’ where name like
‘memory/%’;

Query OK, 377 rows affected (0.00 sec)

Rows matched: 377 Changed: 377 Warnings: 0

# memory_summary_by_account_by_event_name表

root@localhost : performance _schema 11:53:24> select * from
memory_summary _by_account _by_event _name where COUNT_ALLOC!=0
limit 1G

*************************** 1. row
***************************

USER: NULL

HOST: NULL

EVENT_NAME: memory/innodb/fil0fil

COUNT_ALLOC: 103

COUNT_FREE: 103

SUM _NUMBER_OF _BYTES_ALLOC: 3296

SUM _NUMBER_OF _BYTES_FREE: 3296

LOW_COUNT_USED: 0

CURRENT_COUNT_USED: 0

HIGH_COUNT_USED: 1

LOW _NUMBER_OF _BYTES_USED: 0

CURRENT _NUMBER_OF _BYTES_USED: 0

HIGH _NUMBER_OF _BYTES_USED: 32

1 row in set (0.00 sec)

# memory_summary_by_host_by_event_name表

root@localhost : performance _schema 11:54:36> select * from
memory_summary _by_host _by_event _name where COUNT_ALLOC!=0
limit 1G

*************************** 1. row
***************************

HOST: NULL

EVENT_NAME: memory/innodb/fil0fil

COUNT_ALLOC: 158

……

1 row in set (0.00 sec)

# memory_summary_by_thread_by_event_name表

root@localhost : performance _schema 11:55:11> select * from
memory_summary _by_thread _by_event _name where COUNT_ALLOC!=0
limit 1G

*************************** 1. row
***************************

THREAD_ID: 37

EVENT_NAME: memory/innodb/fil0fil

COUNT_ALLOC: 193

……

1 row in set (0.00 sec)

# memory_summary_by_user_by_event_name表

root@localhost : performance _schema 11:55:36> select * from
memory_summary _by_user _by_event _name where COUNT_ALLOC!=0
limit 1G

*************************** 1. row
***************************

USER: NULL

EVENT_NAME: memory/innodb/fil0fil

COUNT_ALLOC: 216

……

1 row in set (0.00 sec)

# memory_summary_global_by_event_name表

root@localhost : performance _schema 11:56:02> select * from
memory_summary _global_by _event_name where COUNT_ALLOC!=0 limit
1G

*************************** 1. row
***************************

EVENT_NAME: memory/performance_schema/mutex_instances

COUNT_ALLOC: 1

……

1 row in set (0.00 sec)

从上面表中的示范记录音讯中,大家得以看来,一样与等待事件类似,按照顾客、主机、客商+主机、线程等纬度举办分组与总结的列,分组列与等待事件类似,这里不再赘言,但对此内部存储器计算事件,总计列与任何三种事件总计列差异(因为内部存款和储蓄器事件不计算时间支出,所以与其余三种事件类型比较无一致计算列),如下:

种种内部存款和储蓄器总计表都有如下计算列:

*
COUNT_ALLOC,COUNT_FREE:对内部存款和储蓄器分配和刑满释放解除劳教内部存储器函数的调用总次数

*
SUM_NUMBER_OF_BYTES_ALLOC,SUM_NUMBER_OF_BYTES_FREE:已分配和已出狱的内部存款和储蓄器块的总字节大小

*
CURRENT_COUNT_USED:这是三个便捷列,等于COUNT_ALLOC – COUNT_FREE

*
CURRENT_NUMBER_OF_BYTES_USED:当前已分配的内部存款和储蓄器块但未释放的计算大小。那是二个便捷列,等于SUM_NUMBER_OF_BYTES_ALLOC

  • SUM_NUMBER_OF_BYTES_FREE

*
LOW_COUNT_USED,HIGH_COUNT_USED:对应CURRENT_COUNT_USED列的低和高水位标志

*
LOW_NUMBER_OF_BYTES_USED,HIGH_NUMBER_OF_BYTES_USED:对应CURRENT_NUMBER_OF_BYTES_USED列的低和高水位标识

内部存款和储蓄器总计表允许使用TRUNCATE
TABLE语句。使用truncate语句时有如下行为:

*
常常,truncate操作会重新恢复设置总结音讯的基准数据(即清空此前的数据),但不会修改当前server的内部存款和储蓄器分配等景色。也正是说,truncate内部存款和储蓄器总计表不会放出已分配内部存款和储蓄器

*
将COUNT_ALLOC和COUNT_FREE列重新恢复设置,视同一律复先河计数(等于内部存储器总括音讯以复位后的数值作为标准数据)

*
SUM_NUMBER_OF_BYTES_ALLOC和SUM_NUMBER_OF_BYTES_FREE列重新初始化与COUNT_ALLOC和COUNT_FREE列重新载入参数类似

*
LOW_COUNT_USED和HIGH_COUNT_USED将复位为CU纳瓦拉RENT_COUNT_USED列值

*
LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED将重新载入参数为CUTiguanRENT_NUMBER_OF_BYTES_USED列值

*
别的,依照帐户,主机,客商或线程分类计算的内部存款和储蓄器总计表或memory_summary_global_by_event_name表,假设在对其借助的accounts、hosts、users表实行truncate时,会隐式对那些内部存款和储蓄器总计表实践truncate语句

关于内部存款和储蓄器事件的行为监督装置与注意事项

内部存储器行为监督装置:

*
内存instruments在setup_instruments表中具备memory/code_area/instrument_name格式的名目。但默许情状下大好多instruments都被剥夺了,暗中认可只开启了memory/performance_schema/*开头的instruments

*
以前缀memory/performance_schema命名的instruments能够搜罗performance_schema本人消耗的内部缓存区大小等消息。memory/performance_schema/*
instruments暗中同意启用,不恐怕在运转时或运转时关闭。performance_schema本身有关的内部存储器总计新闻只保存在memory_summary_global_by_event_name表中,不会保存在依据帐户,主机,顾客或线程分类聚合的内部存款和储蓄器总括表中

* 对于memory
instruments,setup_instruments表中的TIMED列无效,因为内部存款和储蓄器操作不协助时间总括

* 注意:若是在server运转之后再修改memory
instruments,或然会产生由于遗失此前的分配操作数据而导致在放出之后内部存款和储蓄器计算新闻出现负值,所以不提出在运行时每每按钮memory
instruments,若是有内部存款和储蓄器事件总结要求,建议在server运行此前就在my.cnf中配备好内需总括的平地风波访问

当server中的某线程试行了内部存款和储蓄器分配操作时,依据如下准则进行检验与聚集:

*
若是该线程在threads表中绝非拉开荒集效用恐怕说在setup_instruments中对应的instruments未有开启,则该线程分配的内存块不会被监督

*
要是threads表中该线程的访谈功用和setup_instruments表中相应的memory
instruments都启用了,则该线程分配的内部存款和储蓄器块会被监察和控制

对此内存块的假释,遵照如下法规进行检查测试与集中:

*
假若三个线程开启了征集功效,不过内部存款和储蓄器相关的instruments未有启用,则该内部存款和储蓄器释放操作不会被监察和控制到,计算数据也不会发出改动

*
假设贰个线程未有开启收集功效,不过内部存储器相关的instruments启用了,则该内部存款和储蓄器释放的操作会被监督到,总结数据会爆发转移,这也是前方提到的为啥一再在运作时修改memory
instruments或然形成总结数据为负数的因由

对于每一种线程的总括音信,适用以下法则。

当贰个可被监察和控制的内部存款和储蓄器块N被分配时,performance_schema会对内部存款和储蓄器总计表中的如下列进行更新:

* COUNT_ALLOC:增加1

* CURRENT_COUNT_USED:增加1

*
HIGH_COUNT_USED:如果CURRENT_COUNT_USED扩展1是三个新的最高值,则该字段值相应增加

* SUM_NUMBER_OF_BYTES_ALLOC:增加N

*
CURRENT_NUMBER_OF_BYTES_USED:增加N

*
HIGH_NUMBER_OF_BYTES_USED:如果CURRENT_NUMBER_OF_BYTES_USED扩大N之后是一个新的最高值,则该字段值相应扩展

当三个可被监察和控制的内部存款和储蓄器块N被放走时,performance_schema会对总括表中的如下列进行翻新:

* COUNT_FREE:增加1

* CURRENT_COUNT_USED:减少1

*
LOW_COUNT_USED:如果CURRENT_COUNT_USED减少1之后是一个新的最低值,则该字段相应核减

* SUM_NUMBER_OF_BYTES_FREE:增加N

* CURRENT_NUMBER_OF_BYTES_USED:减少N

*
LOW_NUMBER_OF_BYTES_USED:如果CURRENT_NUMBER_OF_BYTES_USED收缩N之后是四个新的最低值,则该字段相应核减

对于较高端别的聚焦(全局,按帐户,按客户,按主机)总结表中,低水位和高水位适用于如下法则:

*
LOW_COUNT_USED和LOW_NUMBER_OF_BYTES_USED是异常低的低水位估摸值。performance_schema输出的低水位值能够有限帮助总计表中的内部存款和储蓄器分配次数和内部存款和储蓄器小于或等于当前server中真正的内部存款和储蓄器分配值

*
HIGH_COUNT_USED和HIGH_NUMBER_OF_BYTES_USED是较高的高水位估摸值。performance_schema输出的低水位值可以保障计算表中的内部存款和储蓄器分配次数和内部存款和储蓄器大于或等于当前server中实际的内部存款和储蓄器分配值

对此内部存款和储蓄器计算表中的低水位测度值,在memory_summary_global_by_event_name表中就算内部存款和储蓄器全部权在线程之间传输,则该揣测值或者为负数

| 温馨提示

脾性事件总计表中的多少条目款项是不能够去除的,只好把相应计算字段清零;

属性事件总结表中的某部instruments是或不是进行总结,正视于在setup_instruments表中的配置项是否展开;

天性事件总结表在setup_consumers表中只受控于”global_instrumentation”配置项,也正是说一旦”global_instrumentation”配置项关闭,全数的总结表的总计条款都不推行总括(总括列值为0);

内存事件在setup_consumers表中一向不单身的布局项,且memory/performance_schema/*
instruments私下认可启用,不可能在运行时或运维时关闭。performance_schema相关的内部存款和储蓄器计算音讯只保存在memory_summary_global_by_event_name表中,不会保存在根据帐户,主机,客商或线程分类聚合的内部存款和储蓄器总括表中。

下一篇将为大家分享《数据库对象事件总计与性能总括 | performance_schema全方位介绍》
,谢谢你的阅读,大家不见不散!回来天涯论坛,查看越来越多

主编:

Copyright @ 2015-2020 js金沙 版权所有
网站地图xml地图