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

2019-11-29 05:53栏目:凤凰彩票下载-互联网
TAG:

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

图片 1

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

出品:沃趣科技(science and technology卡塔尔(قطر‎

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、USE大切诺基、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卡塔尔(英语:State of Qatar)创设有八个实例,则各样实例都享有唯黄金时代的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、USE悍马H2实行分组事件消息

events_waits_summary_global_by_event_name表:按照EVENT_NAME列实行分组事件音讯

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

COUNT_STAHuayra:事件被实行的数码。此值包含持有事件的推行次数,须求启用等待事件的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_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才会进展总括卡塔尔(英语:State of Qatar)。

注意:这一个表只针对职业事件音信举办计算,即含有且仅包含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和E奇骏ROHavalS列进行总计

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景逸SUVST_SEEN和LAST_SEEN列都接收当前光阴

* 要是给定语句的总结音信行在events_statements_summary_by_digest表中一直不已存在行,且events_statements_summary_by_digest表空间节制已满的情状下,则该语句的总括新闻将增多到DIGEST 列值为 NULL的例外“catch-all”行,假如该特别行不设有则新插入后生可畏行,FIPRADOST_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_STA奇骏列值攻克整个表中全部总括信息的COUNT_STAXC60列值的百分比大于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本田CR-VRENT_COUNT_USED列值

* LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED将重新设置为CUMuranoRENT_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全方位介绍》 ,多谢你的开卷,大家不见不散!回去年今年日头条,查看更加多

网编:

版权声明:本文由凤凰彩票发布于凤凰彩票下载-互联网,转载请注明出处:罗小波·沃趣科技高级数据库技术专家