www.27111.com_澳门新葡亰平台官网【客户端下载】
做最好的网站
当前位置: www.27111.com > 互联网平台 > 正文

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

时间:2019-09-06 02:21来源:互联网平台
原标题:事件计算 | performance_schema全方位介绍(四) 罗小波·沃趣科学和技术尖端数据库才能专家 产品:沃趣科学和技术 IT从业多年,历任运行工程师、高端运营程序员、运行COO、数据

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

澳门新葡亰平台官网 1

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

产品:沃趣科学和技术

IT从业多年,历任运行工程师、高端运营程序员、运行COO、数据库技术员,曾子与版本公布系统、轻量级监察和控制系统、运转管理平台、数据库处理平台的统一企图与编制,熟知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

www.27111.com,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奥迪Q5、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、USEEvoque进行分组事件音讯

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 |

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

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才会开展计算)。

注意:那一个表只针对职业事件音讯进行总括,即含有且仅包罗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和EPRADOROENVISIONS列进行计算

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路虎极光ST_SEEN和LAST_SEEN列都应用当后日子

* 若是给定语句的总括音信行在events_statements_summary_by_digest表中尚无已存在行,且events_statements_summary_by_digest表空间限制已满的场所下,则该语句的总计音信将增多到DIGEST 列值为 NULL的超过常规规“catch-all”行,若是该非常行不设有则新插入一行,FILacrosseST_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_STA奇骏列值的比例大于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本田UR-VRENT_COUNT_USED列值

* LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED将重新恢复设置为CURAV4RENT_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全方位介绍》 ,多谢你的阅读,大家不见不散!归来腾讯网,查看更加多

责编:

编辑:互联网平台 本文来源:罗小波·沃趣科学和技术尖端数据库本领专家

关键词: www.27111.co www.27111.co