您的位置:四不像必中一肖动物图 > 深度阅读 > 四不像必中一肖动物图:事件统计

四不像必中一肖动物图:事件统计

发布时间:2019-10-15 08:26编辑:深度阅读浏览(91)

    原标题:事件总计 | 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、USERAV4、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、USEENVISION实行分组事件新闻

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

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

    COUNT_STAENCORE:事件被施行的数目。此值包蕴所有事件的实施次数,必要启用等待事件的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和E凯雷德RO瑞鹰S列进行计算

    events_statements_summary_by_digest表有友好额外的总括列:

    * FIRST_SEEN,LAST_SEEN:展现某给定语句第三遍插入 events_statements_summary_by_digest表和结尾叁回立异该表的岁月戳

    events_statements_summary_by_program表有投机额外的计算列:

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

    prepared_statements_instances表有友好额外的总结列:

    * COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE:推行prepare语句对象的总结音讯

    PS1:

    关于events_statements_summary_by_digest表

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

    * 借使给定语句的总计音信行在events_statements_summary_by_digest表中已经存在,则将该语句的计算音讯进行翻新,并更新LAST_SEEN列值为近期时间

    * 借使给定语句的总括新闻行在events_statements_summary_by_digest表中绝非已存在行,况兼events_statements_summary_by_digest表空间限制未满的意况下,会在events_statements_summary_by_digest表中新插队一行总括新闻,FITiggoST_SEEN和LAST_SEEN列都应用当前时刻

    * 如若给定语句的总计音讯行在events_statements_summary_by_digest表中一贯不已存在行,且events_statements_summary_by_digest表空间限制已满的情况下,则该语句的总结新闻将增加到DIGEST 列值为 NULL的超过常规规“catch-all”行,要是该特别行不设有则新插入一行,FIRST_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福特ExplorerRENT_COUNT_USED列值

    * LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED将重新恢复设置为CUOdysseyRENT_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全方位介绍》 ,感谢你的开卷,大家不见不散!回去博客园,查看越多

    主编:

    本文由四不像必中一肖动物图发布于深度阅读,转载请注明出处:四不像必中一肖动物图:事件统计

    关键词: