您的位置:美高梅mgm平台 > 美高梅mgm平台|线路 > performance_schema全方位介绍

performance_schema全方位介绍

发布时间:2019-04-19 21:18编辑:美高梅mgm平台|线路浏览(152)

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

    图片 1

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

    产品:沃趣科学和技术

    IT从业多年,历任运行技术员、高等运行程序员、运行首席实施官、数据库程序猿,曾参预版本发表系统、轻量级监察和控制连串、运营管理平台、数据库管理平台的规划与编辑,熟悉MySQL体系布局,Innodb存款和储蓄引擎,喜好专研开源技巧,追求完美。

    | 导语

    在上1篇《事件记录 | performance_schema全方位介绍"》中,大家详细介绍了performance_schema的事件记录表,恭喜大家在攻读performance_schema的路上度过了八个最劳累的时期。今后,相信大家已经对比清楚什么是事件了,但有时候我们不需求领悟每时每刻产生的每一条事件记录音讯, 举个例子:大家目的在于精晓数据库运行以来一段时间的事件总结数据,这一年就须要查阅事件总计表了。前几日将引导我们一起踏上聚讼纷繁第5篇的征程(全系共七个篇章),在那1期里,大家将为我们无微不至授课performance_schema中事件总括表。总计事件表分为七个门类,分别为等候事件、阶段事件、语句事件、事务事件、内部存款和储蓄器事件。下边,请跟随我们联合开头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、USERAV4、HOST举办分组事件音讯

    events_waits_summary_by_host_by_event_name表:按照列EVENT_NAME、HOST举办分组事件音讯

    events_waits_summary_by_instance表:按照列EVENT_NAME、OBJECT_INSTANCE_BEGIN举办分组事件音讯。借使3个instruments(event_name)创造有四个实例,则每一个实例都享有唯1的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冠道进行分组事件新闻

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

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

    COUNT_STACRUISER:事件被实践的数额。此值蕴含具备事件的执行次数,必要启用等待事件的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只有3个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:遵照每一种库品级对象和话语事件的原始语句文本统计值(md5hash字符串)举办总括,该总括值是遵照事件的原始语句文本进行简易(原始语句转变为标准语句),每行数据中的相关数值字段是有着同等总结值的总结结果。

    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和ERRORAV4S列举办总计

    events_statements_summary_by_digest表有本人额外的总括列:

    * FIRST_SEEN,LAST_SEEN:显示某给定语句第三遍插入 events_statements_summary_by_digest表和终极2遍立异该表的年月戳

    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启用,则在言辞实践到位时,将会把讲话文本进行md伍 hash总结之后 再发送到events_statements_summary_by_digest表中。分组列基于该语句的DIGEST列值(md5hash值)

    * 假诺给定语句的总计音信行在events_statements_summary_by_digest表中早就存在,则将该语句的总括音讯举办立异,并更新LAST_SEEN列值为日前几天子

    * 借使给定语句的计算新闻行在events_statements_summary_by_digest表中绝非已存在行,并且events_statements_summary_by_digest表空间范围未满的场合下,会在events_statements_summary_by_digest表中新插入一行计算新闻,FIPRADOST_SEEN和LAST_SEEN列都应用当前些天子

    * 如若给定语句的总结新闻行在events_statements_summary_by_digest表中尚无已存在行,且events_statements_summary_by_digest表空间限制已满的情景下,则该语句的总计音讯将增添到DIGEST 列值为 NULL的古怪“catch-all”行,如果该尤其行不存在则新插入1行,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_STATiguan列值攻克整个表中全体计算音讯的COUNT_STARAV四列值的比重大于0%,则表示存在由于该表限制已满导致部分语句总结消息无法归类保存,若是您须要保留全数语句的总括音讯,能够在server运转在此之前调度系统变量performance_schema_digests_size的值,暗许大小为200

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

    当某给定对象在server中第2遍被采取时(即采纳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 表中的示例数据,别的表的以身作则数据省略掉1部分雷同字段)。

    # 借使须要总括内部存款和储蓄器事件消息,须求打开内部存储器事件搜罗器

    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)

    从地点表中的演示记录音讯中,我们能够见见,一样与等待事件类似,依照用户、主机、用户 主机、线程等纬度举行分组与总括的列,分组列与等待事件类似,那里不再赘述,但对此内部存款和储蓄器总括事件,计算列与任何三种事件总计列分化(因为内部存款和储蓄器事件不总结时间支出,所以与其它二种事件类型比较无1致总括列),如下:

    各样内部存款和储蓄器统计表都有如下计算列:

    * 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将重新恢复设置为CUPRADORENT_COUNT_USED列值

    * LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED将重新载入参数为CU奔驰G级RENT_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,也许会促成由于丢失在此之前的分红操作数据而产生在刑释之后内部存储器总计信息出现负值,所以不建议在运行时1再按钮memory instruments,如若有内部存款和储蓄器事件计算必要,建议在server运转在此以前就在my.cnf中陈设好内需总计的事件采访

    当server中的某线程推行了内部存款和储蓄器分配操作时,遵照如下规则举行检验与聚集:

    * 就算该线程在threads表中尚无开启搜聚功效也许说在setup_instruments中对应的instruments未有张开,则该线程分配的内部存款和储蓄器块不会被监察和控制

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

    对于内部存款和储蓄器块的释放,依据如下规则举行检验与聚集:

    * 若是1个线程开启了征集效率,但是内部存款和储蓄器相关的instruments没有启用,则该内部存款和储蓄器释放操作不会被监督到,总括数据也不会发出转移

    * 假若2个线程未有开启收集作用,可是内部存储器相关的instruments启用了,则该内部存款和储蓄器释放的操作会被监察和控制到,总结数据会发生变动,那也是眼下提到的为什么反复在运营时修改memory instruments大概导致总计数据为负数的来由

    对于每种线程的计算音信,适用以下规则。

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

    * COUNT_ALLOC:增加1

    * CURRENT_COUNT_USED:增加1

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

    * 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"配置项,也等于说1旦"global_instrumentation"配置项关闭,全数的总结表的统计条目款项都不实行总结(总计列值为0);

    内部存款和储蓄器事件在setup_consumers表中未有单身的布署项,且memory/performance_schema/* instruments私下认可启用,无法在运营时或运行时关闭。performance_schema相关的内部存款和储蓄器计算新闻只保存在memory_summary_global_by_event_name表中,不会保存在根据帐户,主机,用户或线程分类聚合的内存总结表中。

    下1篇将为大家分享 《数据库对象事件总结与品质计算 | performance_schema全方位介绍》 ,多谢你的阅读,大家不见不散!重回博客园,查看越来越多

    责编:

    本文由美高梅mgm平台发布于美高梅mgm平台|线路,转载请注明出处:performance_schema全方位介绍

    关键词:

上一篇:药品真伪一比就知

下一篇:没有了