事件统计

2019-04-20 00:00栏目:澳门皇家赌场网址导航
TAG:

# 假如要求计算内部存款和储蓄器事件信息,供给开启内部存款和储蓄器事件采撷器

SUM_NO_INDEX_USED: 42

| 导语

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

对此内部存款和储蓄器总结表中的低水位推测值,在memory_summary_global_by_event_name表中假使内部存储器全数权在线程之间传输,则该估计值大概为负数

1 row in set (0.01 sec)

-------------------------------------------------

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

内部存款和储蓄器大小总括新闻有助于理解当下server的内部存款和储蓄器消耗,以便及时举行内部存储器调节。内部存款和储蓄器相关操作计数有助于通晓当下server的内部存款和储蓄器分配器的共同体压力,及时间调节制server品质数据。例如:分配单个字节一百万次与单次分配一百万个字节的习性费用是见仁见智的,通过追踪内部存款和储蓄器分配器分配的内部存款和储蓄器大小和分配次数就足以知道两岸的差别。

MAX _TIMER_WAIT: 0

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

| Tables_in_performance_schema (%memory%summary%) |

* 事务事件的搜集不考虑隔绝品级,访问方式或自行提交情势

MIN _TIMER_WAIT: 0

EVENT_NAME: stage/sql/After create

| events_transactions_summary_by_user_by_event_name |

SUM_xxx:针对events_statements_*事件记录表中相应的xxx列实行计算。比方:语句总结表中的SUM_LOCK_TIME和SUM_ERRORS列对events_statements_current事件记录表中LOCK_TIME和EPAJEROROHavalS列进行总计

COUNT_FREE: 103

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

质量事件总结表中的数目条约是不可能去除的,只好把相应总括字段清零;

1 row in set (0.00 sec)

admin@localhost : performance_schema 06:27:58> show tables like '%events_statements_summary%';

SUM_WARNINGS: 0

COUNT_ALLOC: 193

1 row in set (0.00 sec)

EVENT_NAME: statement/sql/select

-------------------------------------------------------

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

| 事务事件总结表

1 row in set (0.00 sec)

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

7rows inset ( 0. 00sec)

| Tables_in_performance_schema (%events_transactions_summary%) |

EVENT_NAME: statement/sql/select

MIN _TIMER_WAIT: 0

......

| events_waits_summary_by_thread_by_event_name |

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

AVG _TIMER_WAIT: 0

events_waits_summary_by_thread_by_event_name表:按照列THREAD_ID、EVENT_NAME实行分组事件音讯

......

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

| events_statements_summary_by_thread_by_event_name |

属性事件总计表在setup_consumers表中只受控于"global_instrumentation"配置项,也正是说一旦"global_instrumentation"配置项关闭,全体的总括表的总括条目款项都不实施总括(总计列值为0);

# events_transactions_summary_by_thread_by_event_name表

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

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

HOST: localhost

| events_statements_summary_by_account_by_event_name |

SUM _NUMBER_OF _BYTES_FREE: 3296

| events_statements_summary_by_program |

THREAD_ID: 1

* 平常,truncate操作会重新设置总计消息的规范数据(即清空以前的数额),但不会修改当前server的内部存款和储蓄器分配等景色。约等于说,truncate内部存款和储蓄器总计表不会放出已分配内部存款和储蓄器

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

1 row in set (0.01 sec)

root@localhost : performance _schema 01:27:32> select * from events_transactions _summary_global _by_event _name where SUM_TIMER_WAIT!=0G

# events_statements_summary_by_digest表

admin@localhost : performance_schema 06:23:02> show tables like '%events_stages_summary%';

performance_schema会记录内部存款和储蓄器使用境况并集合内部存款和储蓄器使用总括新闻,如:使用的内部存款和储蓄器类型(各类缓存,内部缓冲区等)和线程、帐号、用户、主机的相关操作直接实行的内部存款和储蓄器操作。performance_schema从使用的内存大小、相关操作数量、高低水位(内部存款和储蓄器2回操作的最大和纤维的相干总结值)。

------------------------------------------------------------

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

root@localhost : performance _schema 01:27:27> select * from events_transactions _summary_by _user_by _event_name where SUM _TIMER_WAIT!=0G

5rows inset ( 0. 00sec)

......

MAX _TIMER_WAIT: 0

events_statements_summary_global_by_event_name:遵照每一个事件名称实行总括的Statement事件

SUM _TIMER_WAIT: 0

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

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

# events_stages_summary_by_account_by_event_name表

SUM_ERRORS: 2

AVG _TIMER_WAIT: 0

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

检查实验内存工作负荷峰值、内部存款和储蓄器总体的做事负荷稳固性、或许的内部存款和储蓄器泄漏等是重要的。

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

* SUM_NUMBER_OF_BYTES_FREE:增加N

events_waits_summary_by_instance表:按照列EVENT_NAME、OBJECT_INSTANCE_BEGIN进行分组事件新闻。借使五个instruments(event_name)成立有三个实例,则每一种实例都负有唯一的OBJECT_INSTANCE_BEGIN值,由此各类实例会开始展览单独分组

USER: NULL

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

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

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

SUM _TIMER_READ_WRITE: 8592136000

EVENT_NAME: wait/synch/mutex/mysys/THR_LOCK_heap

COUNT_STAR: 0

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

USER: NULL

MIN _TIMER_WAIT: 0

MIN _TIMER_WAIT: 0

* HIGH_COUNT_USED:如果CURRENT_COUNT_USED扩大一是三个新的最高值,则该字段值相应加多

EVENT_NAME: memory/innodb/fil0fil

EVENT_NAME: stage/sql/After create

EVENT_NAME: statement/sql/select

SUM _TIMER_WAIT: 0

| events_transactions_summary_by_thread_by_event_name |

* 事务所占用的财富需要多少也也许会因业务隔断等级有所差异(举例:锁财富)。然则:各个server可能是利用同样的隔开品级,所以不独立提供隔断等级相关的计算列

events_statements_summary_by_account_by_event_name:遵照各种帐户和语句事件名称实行总结

| memory_summary_by_host_by_event_name |

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

* 要是给定语句的总计音讯行在events_statements_summary_by_digest表中绝非已存在行,且events_statements_summary_by_digest表空间范围已满的事态下,则该语句的总计音信将充裕到DIGEST 列值为 NULL的奇特“catch-all”行,假如该特别行不存在则新插入一行,FIGL450ST_SEEN和LAST_SEEN列为当前岁月。若是该越发行已存在则更新该行的新闻,LAST_SEEN为当下光阴

* 要是三个线程未有拉开荒集成效,不过内部存款和储蓄器相关的instruments启用了,则该内部存款和储蓄器释放的操作会被监察和控制到,总计数据会发生改换,那也是前方提到的为什么反复在运作时修改memory instruments大概变成总括数据为负数的来由

EVENT _NAME: wait/synch/mutex/sql/TC_LOG _MMAP::LOCK_tc

PS:内部存储器总计表不包蕴计时音信,因为内部存款和储蓄器事件不扶助时间消息收集。

| events_stages_summary_by_account_by_event_name |

1row inset ( 0. 00sec)

events_statements_summary_by_user_by_event_name:依照各类用户名和事件名称进行计算的Statement事件

prepared_statements_instances:遵照每种prepare语句实例聚合的总结音信

# events_waits_summary_by_instance表

admin@localhost : performance_schema 06:17:11> show tables like '%events_waits_summary%';

# events_waits_summary_by_user_by_event_name表

| memory_summary_by_account_by_event_name |

当某给定对象在server中第叁回被接纳时(即选拔call语句调用了积存进程或自定义存款和储蓄函数时),将在events_statements_summary_by_program表中增多一行总计消息;

# events_stages_summary_by_thread_by_event_name表

-------------------------------------------------

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

MIN _TIMER_WAIT: 0

USER: NULL

COUNT_ALLOC: 103

| events_waits_summary_by_account_by_event_name |

SUM_SELECT_RANGE: 0

MAX _TIMER_READ_WRITE: 2427645000

出品:沃趣科技(science and technology)

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

HOST: localhost

| events_waits_summary_by_user_by_event_name |

注意:这一个表只针对等候事件消息实行总结,即含有setup_instruments表中的wait/%上马的收集器 idle空闲收罗器,每一个等待事件在每一种表中的总结记录行数供给看怎样分组(比如:依据用户分组总计的表中,有微微个活泼用户,表中就会某些许条同样搜聚器的记录),别的,总括计数器是或不是见效还亟需看setup_instruments表中相应的等待事件搜集器是还是不是启用。

COUNT_ALLOC: 158

# events_stages_summary_by_user_by_event_name表

AVG _TIMER_WAIT: 0

下壹篇将为我们分享 《数据库对象事件总括与品质计算 | performance_schema全方位介绍》 ,感谢您的翻阅,大家不见不散!回去和讯,查看越多

EVENT _NAME: wait/synch/mutex/sql/TC_LOG _MMAP::LOCK_tc

| events_waits_summary_global_by_event_name |

MAX_TIMER_WAIT: 80968744000

Query OK, 377 rows affected (0.00 sec)

| events_statements_summary_global_by_event_name |

| memory_summary_global_by_event_name |

PS1:

root@localhost : performance _schema 11:08:36> select * from events_waits _summary_by _user_by _event_name limit 1G

| Tables_in_performance_schema (%prepare%) |

| events_statements_summary_by_digest |

admin@localhost : performance_schema 06:37:45> show tables like '%events_transactions_summary%';

# events_transactions_summary_global_by_event_name表

......

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

FIRST_SEEN: 2018-05-19 22:33:50

SUM_TIMER_WAIT: 234614735000

从上边表中的言传身教记录音信中,大家得以观望,同样与等待事件类似,依照用户、主机、用户 主机、线程等纬度实行分组与总括的列,这个列的意思与等待事件类似,那里不再赘述,但对此事情总括事件,针对读写事务和只读事务还独自做了计算(xx_READ_WRITE和xx_READ_ONLY列,只读事务需求安装只读事务变量transaction_read_only=on才会议及展览开总计)。

THREAD_ID: 47

| memory_summary_by_user_by_event_name |

# memory_summary_by_thread_by_event_name表

-------------------------------------------------------

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

AVG _TIMER_WAIT: 0

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

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

AVG _TIMER_WAIT: 1235672000

| 温馨提示

DIGEST: 4fb483fe710f27d1d06f83573c5ce11c

SUM_ROWS_EXAMINED: 39718

| events_transactions_summary_by_host_by_event_name |

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

HOST: NULL

EVENT_NAME: transaction

------------------------------------------

......

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

performance_schema把语句事件总括表也根据与等待事件总括表类似的规则进行分拣计算,语句事件instruments暗许全部拉开,所以,语句事件总结表中私下认可会记录全数的言辞事件总计音讯,言辞事件总计表包蕴如下几张表:

| 语句事件总计表

HOST: localhost

内部存款和储蓄器事件instruments中除去performance_schema本身内部存储器分配相关的事件instruments配置暗许开启之外,其余的内部存储器事件instruments配置都默许关闭的,且在setup_consumers表中并未有像等待事件、阶段事件、语句事件与业务事件那样的单独安排项。

OBJECT_SCHEMA: sys

HOST: NULL

......

root@localhost : performance _schema 11:08:23> select * from events_waits _summary_by _thread_by _event_name limit 1G

......

SUM _TIMER_WAIT: 0

MAX _TIMER_WAIT: 0

------------------------------------------

USER: root

EVENT _NAME: wait/synch/mutex/sql/TC_LOG _MMAP::LOCK_tc

......

SUM _TIMER_WAIT: 0

* 读写作业平日比只读事务占用愈多能源,因而事务计算表包罗了用于读写和只读事务的独立总括列

COUNT_STAR: 53

MIN _TIMER_WAIT: 57571000

events_statements_summary_by_thread_by_event_name:根据每种线程和事件名称举办总计的Statement事件

MAX _TIMER_WAIT: 0

EVENT_NAME: stage/sql/After create

MIN _TIMER_READ_WRITE: 87193000

COUNT_STAR: 59

COUNT_STA奥迪Q5:事件被实行的多寡。此值包蕴具备事件的实施次数,需求启用等待事件的instruments

* FIRST_SEEN,LAST_SEEN:展现某给定语句第3次插入 events_statements_summary_by_digest表和最终2次立异该表的年月戳

1 row in set (0.00 sec)

performance_schema把专门的工作事件计算表也如约与等待事件总计表类似的规则进行分类总括,事务事件instruments只有二个transaction,默许禁止使用,事务事件总计表有如下几张表:

* 注意:固然在server运营之后再修改memory instruments,或然会促成由于丢失在此以前的分配操作数据而导致在自由之后内部存款和储蓄器总结消息出现负值,所以不建议在运营时反复按键memory instruments,即便有内部存款和储蓄器事件总结供给,提议在server运维在此以前就在my.cnf中配置好内需总结的风云采访

* CURRENT_COUNT_USED:减少1

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

......

| Tables_in_performance_schema (%events_waits_summary%) |

COUNT_STAR: 11

COUNT_STAR: 0

SUM _SELECT_FULL_JOIN: 21

* CURRENT_NUMBER_OF_BYTES_USED:增加N

AVG _TIMER_WAIT: 0

COUNT_STAR: 0

EVENT_NAME: memory/performance_schema/mutex_instances

SUM _NO_GOOD _INDEX_USED: 0

咱俩先来探望那一个表中记录的计算音讯是何等体统的(由于单行记录较长,那里只列出events_transactions_summary_by_account_by_event_name表中的示例数据,别的表的言传身教数据省略掉1部分同样字段)。

EVENT _NAME: wait/synch/mutex/sql/TC_LOG _MMAP::LOCK_tc

# events_statements_summary_by_host_by_event_name表

| events_stages_summary_by_host_by_event_name |

# memory_summary_global_by_event_name表

EVENT_NAME: memory/innodb/fil0fil

root@localhost : performance _schema 11:07:09> select * from events_waits _summary_by _account_by _event_name limit 1G

EVENT_NAME: memory/innodb/fil0fil

| 等待事件总计表

root@localhost : performance _schema 01:19:07> select * from events_transactions _summary_by _account_by _event_name where COUNT_STAR!=0 limit 1G

HOST: localhost

events_waits_summary_by_host_by_event_name表:按照列EVENT_NAME、HOST进行分组事件音讯

IT从业多年,历任运转程序员、高等运营程序猿、运行首席执行官、数据库程序员,曾参与版本发表种类、轻量级监察和控制类别、运行管理平台、数据库管理平台的准备与编写制定,熟稔MySQL连串布局,Innodb存储引擎,喜好专研开源工夫,追求完善。

COUNT_ALLOC: 1

AVG_TIMER_WAIT:给定计时事件的平分等待时间

在上1篇《事件记录 | performance_schema全方位介绍"》中,大家详细介绍了performance_schema的风浪记录表,恭喜我们在学习performance_schema的旅途度过了五个最艰巨的时日。未来,相信大家早就相比清楚什么是事件了,但奇迹我们不供给明白每时每刻产生的每一条事件记录新闻, 比如:大家希望领悟数据库运转以来壹段时间的风云计算数据,那个时候就要求查阅事件总结表了。前天将辅导大家一块踏上层层第五篇的道路(全系共捌个篇章),在那1期里,我们将为大家无微不至授课performance_schema中事件总结表。总括事件表分为四个种类,分别为等候事件、阶段事件、语句事件、事务事件、内部存款和储蓄器事件。上面,请随行我们一齐起来performance_schema系统的求学之旅吧。

events_statements_summary_by_digest:遵照每一个库品级对象和语句事件的原始语句文本总结值(md伍hash字符串)进行总计,该计算值是依照事件的原始语句文本举行简短(原始语句调换为尺度语句),每行数据中的相关数值字段是兼具一样总计值的总计结果。

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

MAX _TIMER_WAIT: 0

* SUM_NUMBER_OF_BYTES_ALLOC:增加N

root@localhost : performance _schema 11:02:15> select * from events_statements _summary_by _host_by _event_name where COUNT_STAR!=0 limit 1G

COUNT_STAR: 1

--------------------------------------------------------

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

COUNT_STAR: 7

EVENT_NAME: statement/sql/select

COUNT_STAR: 7

俺们先来探视那个表中著录的计算音信是哪些样子的。

--------------------------------------------------------------

MIN _TIMER_WAIT: 0

DIGEST_TEXT: SELECT @@`version_comment` LIMIT ?

USER: root

SUM_TIMER_WAIT:计算给定计时事件的总等待时间。此值仅针对有计时遵循的事件instruments或张开了计时效用事件的instruments,倘使某事件的instruments不补助计时也许尚未拉开计时作用,则该字段为NULL。别的xxx_TIMER_WAIT字段值类似

SUM _TIMER_WAIT: 0

业务聚合计算规则

| events_stages_summary_by_thread_by_event_name |

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

HOST: localhost

root@localhost : performance _schema 10:37:27> select * from events_statements _summary_by _account_by _event_name where COUNT_STAR!=0 limit 1G

# memory_summary_by_user_by_event_name表

SUM _SELECT_FULL _RANGE_JOIN: 0

内存行为监察装置:

1 row in set (0.00 sec)

1 row in set (0.00 sec)

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

root@localhost : performance _schema 12:34:43> select * from events_statements _summary_by_programG;

COUNT_STAR: 0

* 将COUNT_ALLOC和COUNT_FREE列复位,相提并论新早先计数(等于内存计算音信以重新载入参数后的数值作为标准数据)

MIN _TIMER_WAIT: 0

COUNT_STAR: 55

AVG _TIMER_WAIT: 0

COUNT_STAR: 58

OBJECT_TYPE: PROCEDURE

root@localhost : performance _schema 11:21:04> select * from events_stages _summary_by _account_by _event_name where USER is not null limit 1G

AVG _TIMER_WAIT: 0

COUNT_ALLOC: 216

1 row in set (0.00 sec)

THREAD_ID: 46

图片 1

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 in set (0.00 sec)

# events_stages_summary_global_by_event_name表

SUM _CREATED_TMP_TABLES: 10

............

------------------------------------------------------------

MAX _TIMER_WAIT: 0

events_statements_summary_by_host_by_event_name:依照每一个主机名和事件名称举办总计的Statement事件

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

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

| events_statements_summary_by_host_by_event_name |

* 其它,根据帐户,主机,用户或线程分类总计的内部存款和储蓄器总括表或memory_summary_global_by_event_name表,若是在对其借助的accounts、hosts、users表施行truncate时,会隐式对那个内部存储器总计表实施truncate语句

COUNT_STAR: 7

# events_statements_summary_global_by_event_name表

1 row in set (0.00 sec)

# events_transactions_summary_by_host_by_event_name表

LAST_SEEN: 2018-05-20 10:24:42

COUNT_STAR: 0

SUM _TIMER_WAIT: 0

events_statements_summary_by_digest表有自个儿额外的计算列:

root@localhost : performance _schema 11:43:03> select * from events_stages _summary_global _by_event_name limit 1G

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

5rows inset ( 0. 00sec)

CURRENT_COUNT_USED: 0

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

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

对于根据帐户、主机、用户集中的总括表,truncate语句会删除已早先连接的帐户,主机或用户对应的行,并将别的有连接的行的总括列值重新设置为零(实地度量跟未依据帐号、主机、用户集中的计算表同样,只会被重新载入参数不会被剔除)。

| events_waits_summary_by_host_by_event_name |

USER: root

| events_waits_summary_by_instance |

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

* 如若threads表中该线程的搜集功效和setup_instruments表中相应的memory instruments都启用了,则该线程分配的内部存储器块会被监督

主要编辑:

MAX _TIMER_WAIT: 2427645000

SUM _TIMER_WAIT: 0

SUM_SORT_SCAN: 6

events_waits_summary_by_user_by_event_name表:按照列EVENT_NAME、USE福睿斯举办分组事件音信

HOST: NULL

COUNT_STAR: 7

对此较高等别的会见(全局,按帐户,按用户,按主机)总结表中,低水位和高水位适用于如下规则 :

| events_stages_summary_global_by_event_name |

performance_schema把内部存款和储蓄器事件计算表也遵循与等待事件总计表类似的规则进行归类总括。

* COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE:实践prepare语句对象的总计新闻

除此以外,遵照帐户、主机、用户、线程聚合的各样等待事件计算表恐怕events_waits_summary_global_by_event_name表,假诺依据的连接表(accounts、hosts、users表)施行truncate时,那么重视的那些表中的总计数据也会同时被隐式truncate 。

由于performance_schema表内部存款和储蓄器限制,所以尊敬了DIGEST = NULL的异样行。 当events_statements_summary_by_digest表限制体积已满的景色下,且新的语句总计消息在急需插入到该表时又不曾在该表中找到相称的DIGEST列值时,就会把这么些语句计算音讯都总括到 DIGEST = NULL的行中。此行可扶助你推测events_statements_summary_by_digest表的限量是还是不是供给调动

MAX _TIMER_READ_ONLY: 57571000

* SUM_NUMBER_OF_BYTES_ALLOC和SUM_NUMBER_OF_BYTES_FREE列重新设置与COUNT_ALLOC和COUNT_FREE列重新初始化类似

EVENT_NAME: transaction

1 row in set (0.00 sec)

......

EVENT_NAME: transaction

AVG_TIMER_WAIT: 4426693000

可透过如下语句查看语句事件总括表:

SUM _TIMER_WAIT: 0

CURRENT _NUMBER_OF _BYTES_USED: 0

注意:这么些表只针对专业事件音讯实行总括,即含有且仅包蕴setup_instruments表中的transaction收集器,每一个专业事件在各种表中的总结记录行数供给看什么分组(比方:根据用户分组总括的表中,有微微个活泼用户,表中就会有些许条相同收罗器的笔录),其余,总括计数器是不是见效还亟需看transaction搜罗器是不是启用。

1 row in set (0.00 sec)

AVG _TIMER_WAIT: 0

Rows matched: 377 Changed: 377 Warnings: 0

SUM _TIMER_READ_ONLY: 57571000

SUM _TIMER_WAIT: 0

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

1 row in set (0.00 sec)

root@localhost : performance _schema 11:07:14> select * from events_waits _summary_by _host_by _event_name limit 1G

我们先来探望那一个表中著录的总计音信是何许体统的(由于单行记录较长,那里只列出memory_summary_by_account_by_event_name 表中的示例数据,别的表的言传身教数据省略掉1部分雷同字段)。

SUM _TIMER_WAIT: 0

root@localhost : performance _schema 11:29:27> select * from events_stages _summary_by _host_by _event_name where HOST is not null limit 1G

1 row in set (0.00 sec)

1 row in set (0.00 sec)

COUNT_STAR: 0

1 row in set (0.00 sec)

MIN _TIMER_WAIT: 0

* CURRENT_NUMBER_OF_BYTES_USED:减少N

MIN _TIMER_WAIT: 0

| prepared_statements_instances |

--------------------------------------------------------------

1 row in set (0.00 sec)

* HIGH_NUMBER_OF_BYTES_USED:如果CURRENT_NUMBER_OF_BYTES_USED增添N之后是三个新的最高值,则该字段值相应加多

# memory_summary_by_host_by_event_name表

从上边表中的言传身教记录音讯中,我们得以看到,一样与等待事件类似,依照用户、主机、用户 主机、线程等纬度举行分组与总计的列,分组和一些日子总括列与等待事件类似,那里不再赘述,但对于语句总计事件,有针对性语句对象的附加的总计列,如下:

MAX _TIMER_WAIT: 0

root@localhost : performance _schema 11:08:05> select * from events_waits _summary_by_instance limit 1G

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

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

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

1 row in set (0.00 sec)

SUM _CREATED_TMP _DISK_TABLES: 3

......

# events_statements_summary_by_program表(需求调用了仓库储存进度或函数之后才会有数据)

------------------------------------------

5rows inset ( 0. 00sec)

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

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

# events_statements_summary_by_account_by_event_name表

# events_waits_summary_global_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

* LOW_COUNT_USED和HIGH_COUNT_USED将重新初始化为CUPRADORENT_COUNT_USED列值

对此内部存款和储蓄器块的放出,依照如下规则进行检测与聚焦:

COUNT_STAR: 0

LOW _NUMBER_OF _BYTES_USED: 0

MIN _TIMER_READ_ONLY: 57571000

THREAD_ID: 37

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

root@localhost : performance _schema 11:01:51> select * from events_statements _summary_by_digest limit 1G

SUM_ROWS_AFFECTED: 0

* CURRENT_COUNT_USED:增加1

USER: root

performance_schema把等待事件计算表遵照不一致的分组列(不一样纬度)对等候事件相关的数码开展联谊(聚合计算数据列包含:事件时有发生次数,总等待时间,最小、最大、平均等待时间),注意:等待事件的募集功效有一对私下认可是禁用的,供给的时候能够经过setup_instruments和setup_objects表动态开启,等待事件总结表包括如下几张表:

root@localhost : performance _schema 11:08:53> select * from events_waits _summary_global _by_event_name limit 1G

MAX _TIMER_WAIT: 0

* CURRENT_COUNT_USED:那是四个便捷列,等于COUNT_ALLOC - COUNT_FREE

HIGH_COUNT_USED: 1

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

# events_statements_summary_by_user_by_event_name表

events_statements_summary_by_program:根据每一个存款和储蓄程序(存款和储蓄进度和函数,触发器和事件)的事件名称进行总括的Statement事件

当五个可被监督的内部存款和储蓄器块N被释放时,performance_schema会对总计表中的如下列进行创新:

1 row in set (0.00 sec)

1 row in set (0.00 sec)

内部存款和储蓄器事件在setup_consumers表中绝非单独的配置项,且memory/performance_schema/* instruments暗中认可启用,不能够在运行时或运营时关闭。performance_schema相关的内部存款和储蓄器总结音信只保存在memory_summary_global_by_event_name表中,不会保存在根据帐户,主机,用户或线程分类聚合的内部存款和储蓄器计算表中。

1 row in set (0.00 sec)

| events_statements_summary_by_user_by_event_name |

关于events_statements_summary_by_digest表

从下面表中的示范记录信息中,我们得以见见,同样与等待事件类似,根据用户、主机、用户 主机、线程等纬度进行分组与计算的列,分组列与等待事件类似,那里不再赘述,但对此内部存储器总计事件,总结列与任何二种事件计算列分化(因为内部存款和储蓄器事件不总括时间支出,所以与其余两种事件类型比较无一致总计列),如下:

USER: root

AVG _TIMER_WAIT: 0

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

--------------------------------------------------------------

* 内存instruments在setup_instruments表中颇具memory/code_area/instrument_name格式的名号。但私下认可景况下大大多instruments都被剥夺了,暗中同意只开启了memory/performance_schema/*开头的instruments

root@localhost : performance _schema 01:25:13> select * from events_transactions _summary_by _host_by _event_name where COUNT_STAR!=0 limit 1G

| 内部存款和储蓄器事件统计表

......

HOST: localhost

prepared_statements_instances表有和煦额外的计算列:

从上边表中的言传身教记录音讯中,大家得以看来:

MIN_TIMER_WAIT:给定计时事件的非常小等待时间

对于未根据帐户、主机、用户集中的计算表,truncate语句会将总括列值重新设置为零,而不是去除行。

THREAD_ID: 1

root@localhost : performance _schema 11:04:31> select * from events_statements _summary_global _by_event_name limit 1G

# events_statements_summary_by_thread_by_event_name表

EVENT_NAME: transaction

大家先来看望那么些表中著录的总结信息是怎么着子的。

* HIGH_COUNT_USED和HIGH_NUMBER_OF_BYTES_USED是较高的高水位推断值。performance_schema输出的低水位值能够保险总括表中的内部存储器分配次数和内部存款和储蓄器大于或等于当前server中实际的内部存款和储蓄器分配值

* 假设三个线程开启了征集作用,但是内部存款和储蓄器相关的instruments未有启用,则该内部存款和储蓄器释放操作不会被监察和控制到,总括数据也不会发出改造

events_waits_summary_by_account_by_event_name表:按照列EVENT_NAME、USE福特Explorer、HOST进行分组事件音讯

# events_waits_summary_by_host_by_event_name表

当一个可被监督的内部存款和储蓄器块N被分配时,performance_schema会对内部存款和储蓄器总计表中的如下列举行翻新:

* LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED将复位为CU帕杰罗RENT_NUMBER_OF_BYTES_USED列值

1 row in set (0.00 sec)

1 row in set (0.00 sec)

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

SUM_LOCK_TIME: 26026000000

-------------------------------------------------

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

当server中的某线程实施了内部存款和储蓄器分配操作时,遵照如下规则举办检查评定与聚集:

# events_stages_summary_by_host_by_event_name表

* 假如给定语句的计算新闻行在events_statements_summary_by_digest表中一直不已存在行,并且events_statements_summary_by_digest表空间范围未满的情况下,会在events_statements_summary_by_digest表中新插队1行总括消息,FIEvoqueST_SEEN和LAST_SEEN列都应用当前天子

# events_waits_summary_by_thread_by_event_name表

COUNT_STAR: 0

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

EVENT_NAME: transaction

种种表都有分别的2个或八个分组列,以鲜明什么聚合事件消息(全部表都有EVENT_NAME列,列值与setup_instruments表中NAME列值对应),如下:

SUM _SORT_MERGE_PASSES: 0

| events_stages_summary_by_user_by_event_name |

* 假如给定语句的总结音讯行在events_statements_summary_by_digest表中壹度存在,则将该语句的总结音信实行立异,并更新LAST_SEEN列值为近期时间

MIN_TIMER_WAIT: 72775000

* 借使该线程在threads表中一直不展开辟集效率只怕说在setup_instruments中对应的instruments没有拉开,则该线程分配的内部存款和储蓄器块不会被监督

SUM _SELECT_RANGE_CHECK: 0

PS2:关于存款和储蓄程序监控行为:对于在setup_objects表中启用了instruments的仓库储存程序类型,events_statements_summary_by_program将有限支撑存款和储蓄程序的总括音讯,如下所示:

OBJECT_NAME: ps_setup_enable_consumer

MIN _TIMER_WAIT: 0

# events_transactions_summary_by_account_by_event_name表

------------------------------------------------------------

# events_waits_summary_by_account_by_event_name表

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

* LOW_COUNT_USED:如果CURRENT_COUNT_USED减弱一从此是1个新的最低值,则该字段相应收缩

SCHEMA_NAME: NULL

--------------------------------------------------------

6rows inset ( 0. 00sec)

PS:等待事件总计表允许选拔TRUNCATE TABLE语句。

COUNT_STAR: 0

1 row in set (0.00 sec)

AVG _TIMER_READ_WRITE: 1432022000

COUNT_STAR: 0

root@localhost : performance _schema 11:42:37> select * from events_stages _summary_by _user_by _event_name where user is not null limit 1G

* COUNT_ALLOC:增加1

SUM _TIMER_WAIT: 0

# memory_summary_by_account_by_event_name表

--------------------------------------------------------

SUM _TIMER_WAIT: 8649707000

* COUNT_FREE:增加1

COUNT_STAR: 3

MAX _TIMER_WAIT: 0

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

EVENT_NAME: stage/sql/After create

EVENT_NAME: stage/sql/After create

COUNT _READ_WRITE: 6

从地点表中的示范记录音讯中,大家得以观望,同样与等待事件类似,根据用户、主机、用户 主机、线程等纬度举行分组与总计的列,那么些列的意义与等待事件类似,那里不再赘述。

AVG _TIMER_READ_ONLY: 57571000

| Tables_in_performance_schema (%events_stages_summary%) |

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

performance_schema把阶段事件统计表也遵从与等待事件计算表类似的规则进行归类聚合,阶段事件也有一对是默许禁用的,1部分是张开的,阶段事件总括表包蕴如下几张表:

COUNT _READ_ONLY: 1

1 row in set (0.00 sec)

USER: root

* 如果DIGEST = NULL行的COUNT_STACR-V列值占有整个表中全数总计新闻的COUNT_STACRUISER列值的百分比大于0%,则意味着存在由于该表限制已满导致一些语句计算音信不能归类保存,假若你需求保留全数语句的总结音讯,能够在server运转之前调解系统变量performance_schema_digests_size的值,暗中同意大小为200

COUNT_STAR: 7

SUM_SELECT_SCAN: 45

COUNT_STAR: 0

我们先来看望那几个表中著录的总结新闻是怎么体统的(由于单行记录较长,那里只列出events_statements_summary_by_account_by_event_name 表中的示例数据,其他表的以身作则数据省略掉壹部分雷同字段)。

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

SUM_SORT_RANGE: 0

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

SUM_ROWS_SENT: 1635

| memory_summary_by_thread_by_event_name |

-------------------------------------------------------

EVENT_NAME: statement/sql/select

| Tables_in_performance_schema (%events_statements_summary%) |

......

# events_transactions_summary_by_user_by_event_name表

1 row in set (0.01 sec)

EVENT_NAME: memory/innodb/fil0fil

性子事件总括表中的某些instruments是还是不是实践总括,依赖于在setup_instruments表中的配置项是或不是张开;

| 阶段事件总计表

OBJECT _INSTANCE_BEGIN: 32492032

HOST: NULL

AVG _TIMER_WAIT: 0

  • SUM_NUMBER_OF_BYTES_FREE

MIN _TIMER_WAIT: 0

SUM _NUMBER_OF _BYTES_ALLOC: 3296

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

LOW_COUNT_USED: 0

root@localhost : performance _schema 11:03:19> select * from events_statements _summary_by _thread_by _event_name where COUNT_STAR!=0 limit 1G

* 以前缀memory/performance_schema命名的instruments能够搜集performance_schema自己消耗的中间缓存区大小等音信。memory/performance_schema/* instruments暗许启用,无法在运行时或运维时关闭。performance_schema自己有关的内部存款和储蓄器计算新闻只保存在memory_summary_global_by_event_name表中,不会保存在依据帐户,主机,用户或线程分类聚合的内部存款和储蓄器总计表中

HIGH _NUMBER_OF _BYTES_USED: 32

events_waits_summary_global_by_event_name表:按照EVENT_NAME列实行分组事件消息

USER: NULL

MAX _TIMER_WAIT: 0

注意:这几个表只针对阶段事件消息进行总计,即包涵setup_instruments表中的stage/%开始的采撷器,各类阶段事件在各样表中的总计记录行数供给看怎么分组(比如:依据用户分组计算的表中,有稍许个活泼用户,表中就会有微微条同样收集器的笔录),其它,总结计数器是还是不是见效还需求看setup_instruments表中相应的阶段事件采撷器是不是启用。

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

* COUNT_STATEMENTS,SUM_STATEMENTS_WAIT,MIN_STATEMENTS_WAIT,AVG_STATEMENTS_WAIT,MAX_STATEMENTS_WAIT:关于存款和储蓄程序实施时期调用的嵌套语句的总结音讯

AVG _TIMER_WAIT: 0

EVENT _NAME: wait/synch/mutex/sql/TC_LOG _MMAP::LOCK_tc

SUM_SORT_ROWS: 170

MAX _TIMER_WAIT: 0

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

对于每一个线程的总结音讯,适用以下规则。

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

1 row in set (0.00 sec)

版权声明:本文由澳门皇家赌场网址导航发布于澳门皇家赌场网址导航,转载请注明出处:事件统计