原标题:事件记录 | performance_schema全方位介绍(三)

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

图片 1

图片 2

导语

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

在上一篇 《配置详解 |
performance_schema全方位介绍》中,我们详细介绍了performance_schema的配置表,坚定不移读完的是真爱,也恭喜大家翻过了一座苍山。相信有无数人读完事后,已经等比不上的想要严阵以待了,明日将教导大家一同踏上层层第三篇的征程(全系共6个篇章),在这一期里,大家将为大家精细入微授课performance_schema中事件原来记录表。下边,请跟随我们一道起首performance_schema系统的求学之旅吧。

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

等候事件表

IT从业多年,历任运转技术员、高端运行程序员、运转首席营业官、数据库程序猿,曾参与版本发表系统、轻量级监察和控制体系、运行管理平台、数据库处理平台的安插与编辑,精晓MySQL连串布局,Innodb存款和储蓄引擎,喜好专研开源才具,追求完善。

平时,大家在境遇品质瓶颈时,假若别的的方式难以寻觅质量瓶颈的时候(比如:硬件负载不高、SQL优化和库表结构优化都难以奏效的时候),大家平常需求正视等待事件来开展深入分析,寻觅在MySQL
Server内部,到底数据库响应慢是慢在哪儿。

| 导语

等候事件记录表包含三张表,那么些表记录了脚下与如今在MySQL实例中生出了哪些等待事件,时间开支是稍微。

在上一篇《事件记录 |
performance_schema全方位介绍”》中,大家详细介绍了performance_schema的平地风波记录表,恭喜大家在念书performance_schema的旅途度过了多个最困难的一代。现在,相信大家已经相比清楚什么是事件了,但有的时候大家无需精晓每时每刻发生的每一条事件记录消息,
举个例子:大家盼望通晓数据库运行以来一段时间的平地风波总结数据,这一年就供给查阅事件总计表了。明天将引导咱们一起踏上劈头盖脸第四篇的征途(全系共7个篇章),在这一期里,大家将为大家无所不至授课performance_schema中事件计算表。总括事件表分为5个品类,分别为等候事件、阶段事件、语句事件、事务事件、内部存款和储蓄器事件。上边,请跟随大家一同起来performance_schema系统的学习之旅吧。

  • events_waits_current表:记录当前正在施行的等待事件的,每种线程只记录1行记录
  • events_waits_history表:记录已经实行完的最近的等待事件历史,暗中认可每一个线程只记录10行记录
  • events_waits_history_long表:记录已经实践完的这几天的等待事件历史,默许全数线程的总记录行数为一千0行

| 等待事件计算表

要小心:等待事件有关布署中,setup_instruments表中多方面包车型客车等候事件instruments都不曾展开(IO相关的守候事件instruments暗许大部分已拉开),setup_consumers表中waits相关的consumers配置私下认可未有拉开

performance_schema把等待事件总结表依据差别的分组列(差别纬度)对等候事件有关的数额开展联谊(聚合总括数据列包罗:事件时有产生次数,总等待时间,最小、最大、平均等待时间),注意:等待事件的募集效率有部分暗许是禁用的,供给的时候能够由此setup_instruments和setup_objects表动态开启,等待事件总计表包罗如下几张表:

events_waits_current 表

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

events_waits_current表包罗当前的等待事件音信,各样线程只显示一行近期监视的等候事件的当前场地

+——————————————————-+

在颇有包蕴等待事件行的表中,events_waits_current表是最基础的数目来自。其余包罗等待事件数据表在逻辑上是来自events_waits_current表中的当前事件新闻(汇总表除此而外)。举例,events_waits_history和events_waits_history_long表中的数据是events_waits_current表数据的二个小集合汇总(具体贮存多少行数据集合有些的变量支配)

| Tables_in_performance_schema (%events_waits_summary%) |

表记录内容示例(那是多个实践select
sleep(100);语句的线程等待事件音信)

+——————————————————-+

root@localhost : performance _schema 12:15:03> select * from
events_waits _current where EVENT_NAME=’wait/synch/cond/sql/Item
_func_sleep::cond’G;

| events_waits_summary_by_account_by_event_name |

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

| events_waits_summary_by_host_by_event_name |

THREAD_ID: 46

| events_waits_summary_by_instance |

EVENT_ID: 140

| events_waits_summary_by_thread_by_event_name |

END_EVENT_ID: NULL

| events_waits_summary_by_user_by_event_name |

EVENT_NAME: wait/synch/cond/sql/Item_func_sleep::cond

| events_waits_summary_global_by_event_name |

SOURCE: item_func.cc:5261

+——————————————————-+

TIMER_START: 14128809267002592

6rows inset ( 0. 00sec)

TIMER_END: 14132636159944419

大家先来拜见那么些表中著录的总计音信是何等体统的。

TIMER_WAIT: 3826892941827

# events_waits_summary_by_account_by_event_name表

SPINS: NULL

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

OBJECT_SCHEMA: NULL

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

OBJECT_NAME: NULL

USER: NULL

INDEX_NAME: NULL

HOST: NULL

OBJECT_TYPE: NULL

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

OBJECT _INSTANCE_BEGIN: 140568905519072

COUNT_STAR: 0

NESTING _EVENT_ID: 116

SUM _TIMER_WAIT: 0

NESTING _EVENT_TYPE: STATEMENT

MIN _TIMER_WAIT: 0

OPERATION: timed_wait

AVG _TIMER_WAIT: 0

NUMBER _OF_BYTES: NULL

MAX _TIMER_WAIT: 0

FLAGS: NULL

1 row in set (0.00 sec)

1 row in set (0.00 sec)

# events_waits_summary_by_host_by_event_name表

地方的输出结果中,TIMETiggo_WAIT字段即意味着该事件的时日支付,单位是微秒,在事实上的运用场景中,大家得以行使该字段音讯进行倒序排序,以便找寻时间支出最大的等待事件。

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

events_waits_current表完整的字段含义如下:

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

THREAD_ID,EVENT_ID:与事件涉及的线程ID和如今事变ID。THREAD_ID和EVENT_ID值构成了该事件音信行的独一标记(不会有又一次的THREAD_ID+EVENT_ID值)

HOST: NULL

END_EVENT_ID:当一个事件正在试行时该列值为NULL,当贰个事变施行落成时把该事件的ID更新到该列

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

EVENT_NAME:产滋事件的instruments名称。该名称来自setup_instruments表的NAME字段值

COUNT_STAR: 0

SOURCE:产生该事件的instruments所在的源文件名称以及检查实验到该事件产生点的代码行号。您能够查看源代码来显明涉及的代码。举例,若是互斥锁、锁被堵塞,您能够检查爆发这种情形的上下文景况

SUM _TIMER_WAIT: 0

TIMER_START,TIMER_END,TIMER_WAIT:事件的时日音讯。单位阿秒(万亿分之一秒)。
TIMEEnclave_START和TIMER_END值表示事件开始和终结时间。
TIME路虎极光_WAIT是事件经过岁月(即事件施行了多久)

MIN _TIMER_WAIT: 0

  • 假诺事件未实践到位,则TIMELacrosse_END为如今沙漏时间值(当前时刻),TIMEPRADO_WAIT为近年来结束所经过的时光(TIME福特Explorer_END –
    TIMER_START)
  • 若果搜集该事件的instruments配置项TIMED =
    NO,则不会搜聚事件的小时音信,TIME凯雷德_START,TIMER_END和TIMER_WAIT在这种情状下均记录为NULL

AVG _TIMER_WAIT: 0

SPINS:对于互斥量和自旋次数。假如该列值为NULL,则意味代码中从不采纳自旋只怕说自旋未有被监察和控制起来

MAX _TIMER_WAIT: 0

OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE,OBJECT_INSTANCE_BEGIN:这几个列标志了二个正值被实施的靶子,所以这个列记录的音信意义必要看对象是何等类型,下边遵照分歧对象类型分别对这一个列的意思进行表明:

1 row in set (0.00 sec)

*
对于联合对象(cond,mutex,rwlock):

# events_waits_summary_by_instance表

*
1)、OBJECT_SCHEMA,OBJECT_NAME和OBJECT_TYPE列值都为NULL

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

*
2)、OBJECT_INSTANCE_BEGIN列是内部存储器中同步对象的地点。OBJECT_INSTANCE_BEGIN除了不相同的值标识分歧的靶子之外,其值本人未有意义。但OBJECT_INSTANCE_BEGIN值可用以调节和测验。譬如,它能够与GROUP BY
OBJECT_INSTANCE_BEGIN子句一同使用来查看1,000个互斥体(举个例子:爱慕1,000个页或数据块)上的载荷是或不是是均匀遍及依然时有暴发了一部分瓶颈。要是在日记文件或其余调试、质量工具中观察与该语句查看的结果中有雷同的指标地址,那么,在你剖析品质难题时,能够把那么些语句查见到的消息与别的工具查见到的音信涉及起来。

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

* 对于文本I/O对象:

EVENT_NAME: wait/synch/mutex/mysys/THR_LOCK_heap

*
1)、OBJECT_SCHEMA列值为NULL

OBJECT _INSTANCE_BEGIN: 32492032

* 2)、OBJECT_NAME列是文件名

COUNT_STAR: 0

* 3)、OBJECT_TYPE列为FILE

SUM _TIMER_WAIT: 0

*
4)、OBJECT_INSTANCE_BEGIN列是内存中的地方,解释同上

MIN _TIMER_WAIT: 0

* 对于套接字对象:

AVG _TIMER_WAIT: 0

* 1)、OBJECT_NAME列是套接字的IP:PORT值

MAX _TIMER_WAIT: 0

*
2)、OBJECT_INSTANCE_BEGIN列是内部存款和储蓄器中的地方,解释同上

1 row in set (0.00 sec)

* 对于表I/O对象:

# events_waits_summary_by_thread_by_event_name表

* 1)、OBJECT_SCHEMA列是带有该表的库名称

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

* 2)、OBJECT_NAME列是表名

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

*
3)、OBJECT_TYPE列值对于基表恐怕TEMPORACRUISERY
TABLE有的时候表,该值是table,注意:对于在join查询中select_type为DE景逸SUVIVED,subquery等的表或然不记录事件消息也不实行总结

THREAD_ID: 1

*
4)、OBJECT_INSTANCE_BEGIN列是内部存款和储蓄器中的地点,解释同上

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

INDEX_NAME:表示使用的目录的名称。PEnclaveIMAEnclaveY表示使用到了主键。 NULL代表尚无行使索引

COUNT_STAR: 0

NESTING_EVENT_ID:表示该行新闻中的EVENT_ID事件是嵌套在哪个事件中,即父事件的EVENT_ID

SUM _TIMER_WAIT: 0

NESTING_EVENT_TYPE:表示该行消息中的EVENT_ID事件嵌套的事件类型。有效值有:TRANSACTION,STATEMENT,STAGE或WAIT,即父事件的风浪类型,即便为TRANSACTION则必要到事情事件表中找对应NESTING_EVENT_ID值的平地风波,别的项目同理

MIN _TIMER_WAIT: 0

OPERATION:推行的操作类型,如:lock、read、write、timed_wait

AVG _TIMER_WAIT: 0

NUMBER_OF_BYTES:操作读取或写入的字节数或行数。对于文本IO等待,该列值表示字节数;对于表I/O等待(wait/io/table/sql/handler
instruments的事件),该列值表示行数。假若值当先1,则代表该事件对应一个批量I/O操作。以下分别对单个表IO和批量表IO的区分进行描述:

MAX _TIMER_WAIT: 0

  • MySQL的join查询利用嵌套循环达成。performance_schema
    instruments的作用是在join查询中提供对每一个表的扫视行数和实行时间开展总结。示例:join查询语句:SELECT
    … FROM t1 JOIN t2 ON … JOIN t3 ON …,假诺join顺序是t1,t2,t3
  • 在join查询中,多个表在查询时与别的表张开联合查询之后,该表的扫视行数只怕扩大也恐怕缩短,举例:借使t3表扇出超乎1,则大部分row
    fetch操作都以针对t3表,若是join查询从t1表采访10行记录,然后利用t1表驱动查询t2表,t1表的每一行都会扫描t2表的20行记录,然后使用t2表驱动查询t3表,t2表的每一行都会扫描t3表的30行记录,那么,在动用单行输出时,instruments计算操作的平地风波新闻总行数为:10
    +(10 * 20)+(10 * 20 * 30)= 6210
  • 经过对表中行扫描时的instruments总括操作举行联谊(即,每一个t1和t2的围观行数在instruments总括中能够算作贰个批量重组),那样就足以减小instruments计算操作的数量。通过批量I/O输出情势,performance_schema每一次对最内层表t3的扫视减弱为二个平地风波总计音讯并非每一行扫描都生成二个事件信息,此时对此instruments总括操作的轩然大波行数量收缩到:10
    +(10 * 20)+(10 * 20)=
    410,那样在该join查询中对于performance_schema中的行总结操作就收缩了93%,批量出口攻略通过压缩输骑行数量来显着裁减表I/O的performance_schema总计开支。不过相对于每行数据都单身实行总结操作,会损失对时间总结的准确度。在join查询中,批量I/O计算的日子满含用于连接缓冲、聚合和再次回到行到顾客端的操作所花费的时光(即就是整整join语句的实行时间)

1 row in set (0.00 sec)

FLAGS:留作以往采用

# events_waits_summary_by_user_by_event_name表

PS:events_waits_current表允许使用TRUNCATE TABLE语句

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

events_waits_history 表

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

events_waits_history表包括各种线程这段日子的N个等待事件。
在server运转时,N的值会自动调度。
假设要显式设置那个N大小,能够在server运维以前调节系统参数performance_schema_events_waits_history_size的值。
等待事件要求举办完成时才被增加到events_waits_history表中(未有完毕时保留在events_waits_current表)。当增添新事件到events_waits_history表时,若是该表已满,则会舍弃各种线程较旧的风浪

USER: NULL

events_waits_history与events_waits_current表定义一样

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

PS:允许实践TRUNCATE TABLE语句

COUNT_STAR: 0

events_waits_history_long 表

SUM _TIMER_WAIT: 0

events_waits_history_long表包罗近日的N个等待事件(全体线程的事件)。在server运行时,N的值会自动调度。
假使要显式设置这几个N大小,能够在server运营之前调度系统参数

MIN _TIMER_WAIT: 0

performance_schema_events_waits_history_long_size的值。等待事件要求奉行完成时才会被增添到events_waits_history_long表中(未有截至时保留在events_waits_current表),当增加新事件到events_waits_history_long表时,借使该表已满,则会放任该表中较旧的平地风波。

AVG _TIMER_WAIT: 0

events_waits_history_long与events_waits_current表结构相同

MAX _TIMER_WAIT: 0

PS:允许使用TRUNCATE TABLE语句

1 row in set (0.00 sec)

品级事件表

# events_waits_summary_global_by_event_name表

等级事件记录表与等待事件记录表同样,也是有三张表,那么些表记录了近年来与近期在MySQL实例中产生了什么样阶段事件,时间消耗是有个别。阶段指的是语句实行进度中的步骤,比方:parsing
、opening tables、filesort操作等。

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

在昔日大家查阅语句实践的等级状态,平日使用SHOW
PROCESSLIST语句或询问INFORMATION_SCHEMA.PROCESSLIST表来获取,但processlist方式能够查询到的新闻相比较有限且时而即逝,大家日常供给组合profiling效能来特别计算深入分析语句实施的相继阶段的花费等,今后,大家无需那样麻烦,间接使用performance_schema的阶段事件就不仅可以够查询到具备的言语执行等第,也可以查询到种种阶段对应的支出,因为是记录在表中,所以更可以运用SQL语句对这个数量开展排序、总结等操作

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

要注意:阶段事件相关配置中,setup_instruments表中stage/开首的大部instruments配置暗中同意未有开启(少数stage/初步的instruments除却,如DDL语句试行进度的stage/innodb/alter*千帆竞发的instruments暗中认可开启的),setup_consumers表中stages相关的consumers配置默许没有张开

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

events_stages_current 表

COUNT_STAR: 0

events_stages_current表包罗当前阶段事件的监督检查音信,每一种线程一行记录展现线程正在实行的stage事件的情景

SUM _TIMER_WAIT: 0

在蕴藏stage事件记录的表中,events_stages_current是基准表,包括stage事件记录的别样表(如:events_stages_history和events_stages_history_long表)的数码在逻辑上都来源于events_stages_current表(汇总表除此而外)

MIN _TIMER_WAIT: 0

表记录内容示例(以下依然是三个进行select
sleep(100);语句的线程,但此处是阶段事件音信)

AVG _TIMER_WAIT: 0

root@localhost : performance _schema 12:24:40> select * from
events_stages _current where EVENT_NAME=’stage/sql/User sleep’G;

MAX _TIMER_WAIT: 0

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

1 row in set (0.00 sec)

THREAD_ID: 46

从上边表中的言传身教记录消息中,大家得以见见:

EVENT_ID: 280

种种表都有各自的二个或八个分组列,以显著什么聚合事件信息(全数表都有EVENT_NAME列,列值与setup_instruments表中NAME列值对应),如下:

END _EVENT_ID: NULL

events_waits_summary_by_account_by_event_name表:按照列EVENT_NAME、USEGL450、HOST实行分组事件消息

EVENT_NAME: stage/sql/User sleep

events_waits_summary_by_host_by_event_name表:按照列EVENT_NAME、HOST进行分组事件消息

SOURCE: item_func.cc:6056

events_waits_summary_by_instance表:按照列EVENT_NAME、OBJECT_INSTANCE_BEGIN进行分组事件音讯。假使三个instruments(event_name)创立有多少个实例,则每一个实例都怀有独一的OBJECT_INSTANCE_BEGIN值,因而各种实例会进行单独分组

TIMER_START: 14645080545642000

events_waits_summary_by_thread_by_event_name表:按照列THREAD_ID、EVENT_NAME进行分组事件消息

TIMER_END: 14698320697396000

events_waits_summary_by_user_by_event_name表:按照列EVENT_NAME、USEQashqai实行分组事件新闻

TIMER_WAIT: 53240151754000

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

WORK_COMPLETED: NULL

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

WORK_ESTIMATED: NULL

COUNT_STA奥迪Q5:事件被实施的多少。此值包涵具有事件的实施次数,要求启用等待事件的instruments

NESTING _EVENT_ID: 266

SUM_TIMER_WAIT:总结给定计时事件的总等待时间。此值仅针对有计时坚守的事件instruments或开启了计时作用事件的instruments,如若有些事件的instruments不援助计时要么尚未开启计时功效,则该字段为NULL。其余xxx_TIMER_WAIT字段值类似

NESTING _EVENT_TYPE: STATEMENT

MIN_TIMER_WAIT:给定计时事件的纤维等待时间

1 row in set (0.00 sec)

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

如上的输出结果与话语的等候事件方式类似,这里不再赘述,events_stages_current表完整的字段含义如下

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

THREAD_ID,EVENT_ID:与事件波及的线程ID和当前事变ID,能够利用THREAD_ID和EVENT_ID列值来独一标志该行,这两行的值作为整合条件时不会并发一样的数据行

PS:等待事件总括表允许利用TRUNCATE
TABLE语句。

END_EVENT_ID:当贰个事变早先实践时,对应行记录的该列值被设置为NULL,当叁个风浪实践达成时,对应的行记录的该列值被更新为该事件的ID

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

EVENT_NAME:产惹事件的instruments的称号。该列值来自setup_instruments表的NAME值。instruments名称或然全体八个部分并摇身一变档案的次序结构,如:”stage/sql/Slave has read all relay log;
waiting for more updates”,在那之中stage是甲级名称,sql是二级名称,Slave has read all relay log; waiting for more
updates是第三级称号。详见链接:

对于未依据帐户、主机、顾客集中的总计表,truncate语句会将计算列值重新恢复设置为零,并非剔除行。

对于依照帐户、主机、客户集中的总括表,truncate语句会删除已初步连接的帐户,主机或客户对应的行,并将另外有连日的行的总计列值重新设置为零(实地度量跟未根据帐号、主机、客户集中的总计表同样,只会被重新设置不会被删除)。

SOURCE:源文件的名目及其用于检查测验该事件的代码位于源文件中的行号

别的,根据帐户、主机、顾客、线程聚合的各种等待事件总计表大概events_waits_summary_global_by_event_name表,若是借助的连接表(accounts、hosts、users表)推行truncate时,那么信赖的这个表中的总结数据也会同一时候被隐式truncate

TIMER_START,TIMER_END,TIMER_WAIT:事件的年华消息。这个值的单位是阿秒(万亿分之一秒)。TIMEXC90_START和TIMER_END值表示事件的发端时间和甘休时间。TIME奔驰M级_WAIT是事件推行消耗的时日(持续时间)

注意:那几个表只针对等候事件消息进行总括,即含有setup_instruments表中的wait/%始发的访谈器+
idle空闲搜聚器,各类等待事件在各种表中的总结记录行数要求看怎么分组(比方:依照客户分组总括的表中,有稍许个活泼客户,表中就能够有微微条相同收罗器的笔录),其他,总结计数器是不是见效还索要看setup_instruments表中相应的守候事件收罗器是不是启用。

  • 若果事件未试行到位,则TIME凯雷德_END为当前时间,TIMETiguan_WAIT为近来得了所经过的光阴(TIME凯雷德_END –
    TIMER_START)
  • 如果instruments配置表setup_instruments中对应的instruments
    的TIMED字段棉被服装置为
    NO,则该instruments禁止使用时间访谈成效,那么事件访谈的音信记录中,TIMEWrangler_START,TIMER_END和TIMER_WAIT字段值均为NULL

| 阶段事件计算表

WORK_COMPLETED,WORK_ESTIMATED:这个列提供了阶段事件进程音讯

performance_schema把阶段事件计算表也遵守与等待事件总括表类似的法则实行归类聚合,阶段事件也是有一部分是暗中认可禁止使用的,一部分是开启的,阶段事件总计表包涵如下几张表:

  • 表中的WORK_COMPLETED和WORK_ESTIMATED两列,它们一同同盟显示每一行的进度显示:

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

*
1)、WORK_COMPLETED:展现阶段事件已做到的干活单元数

+——————————————————–+

*
2)、WORK_ESTIMATED:呈现猜度阶段事件将要实现的行事单元数

| Tables_in_performance_schema (%events_stages_summary%) |

  • 假设instruments未有提供进程相关的法力,则该instruments试行事件访谈时就不会有速度音讯展示,WOEscortK_COMPLETED和WORK_ESTIMATED列都会来得为NULL。假诺进程消息可用,则进程音讯如何展现决定于instruments的执涨势况。performance_schema表提供了三个积攒进度数据的器皿,但不会倘令你会定义何种衡量单位来利用这么些进程数据:

+——————————————————–+

*
1)、“工作单元”是在施行进度中随时间扩大而充实的卡尺头度量,举例实践进程中的字节数、行数、文件数或表数。对于特定instruments的“职业单元”的概念留给提供数据的instruments代码

| events_stages_summary_by_account_by_event_name |

*
2)、WORK_COMPLETED值根据检查实验的代码不一样,能够叁次增添叁个或四个单元

| events_stages_summary_by_host_by_event_name |

*
3)、WORK_ESTIMATED值根据检查评定代码,大概在等第事件实行进程中产生变化

| events_stages_summary_by_thread_by_event_name |

  • 品级事件进程提示器的表现作为有以下两种状态:

| events_stages_summary_by_user_by_event_name |

*
1)、instruments不协理进程:未有可用进程数据,
WO汉兰达K_COMPLETED和WORK_ESTIMATED列都来得为NULL

| events_stages_summary_global_by_event_name |

* 2)
、instruments帮衬进程但对应的劳作负荷总专门的学业量不可预估(Infiniti进程):独有WO奥迪Q5K_COMPLETED列有含义(因为她显得正在奉行的进程呈现),WOWranglerK_ESTIMATED列此时不算,展现为0,因为没有可预估的总进度数据。通过查询events_stages_current表来监视会话,监察和控制应用程序到近期截至实行了多少干活,但爱莫能助告知对应的干活是还是不是临近达成

+——————————————————–+

*
3)、instruments补助进度,总职业量可预估(有限进程):WOGL450K_COMPLETED和WORK_ESTIMATED列值有效。那类别型的快慢显示可用于online
DDL时期的copy表阶段监视。通过查询events_stages_current表,可监察和控制应用程序当前早就做到了不怎么干活,并且可以通过WOTiguanK_COMPLETED
/ WORK_ESTIMATED总结的比率来预估某些阶段总体造成比例

5rows inset ( 0. 00sec)

NESTING_EVENT_ID:事件的嵌套事件EVENT_ID值(父事件ID)

大家先来寻访那几个表中记录的总结音信是何等体统的。

NESTING_EVENT_TYPE:嵌套事件类型。有效值为:TRANSACTION,STATEMENT,STAGE,WAIT。阶段事件的嵌套事件数见不鲜是statement

# events_stages_summary_by_account_by_event_name表

对于events_stages_current表允许使用TRUNCATE
TABLE语句来拓展清理

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

PS:stage事件具有三个速度展示效果,我们得以采纳该进度浮现效果来打听部分长日子实践的SQL的速度百分比,譬喻:对于急需利用COPY格局推行的online
ddl,那么供给copy的数据量是必定的,可以明显的,so..那就足认为”stage/sql/copy
to tmp table stage”
instruments提供二个有甘休边界参照的快慢数据信息,这些instruments所接纳的干活单元就是急需复制的数码行数,此时WOOdysseyK_COMPLETED和WORK_ESTIMATED列值都以立竿见影的可用的,两个的计算比例就表示近些日子copy表达成copy的行数据百分比。

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

  • 要查阅copy表阶段事件的正在实行的快慢监视作用,必要展开相关的instruments和consumers,然后查看events_stages_current表,如下:

USER: root

# 配置相关instruments和consumers

HOST: localhost

UPDATEsetup_instruments SETENABLED= ‘YES’WHERENAME= ‘stage/sql/copy to
tmp table’;

EVENT_NAME: stage/sql/After create

UPDATEsetup_consumers SETENABLED=
‘YES’WHERENAMELIKE’events_stages_%’;

COUNT_STAR: 0

# 然后在实行ALTEOdyssey TABLE语句时期,查看events_stages_current表

SUM _TIMER_WAIT: 0

events_stages_history 表

MIN _TIMER_WAIT: 0

events_stages_history表蕴涵各样线程最新的N个阶段事件。
在server运转时,N的值会自动调度。
假设要显式设置N值大小,能够在server运营从前安装系统变量performance_schema_events_stages_history_size的值。stages事件在实施达成时才加多到events_stages_history表中。
当增添新事件到events_stages_history表时,如果events_stages_history表已满,则会甩掉对应线程较旧的轩然大波events_stages_history与events_stages_current表结构同样

AVG _TIMER_WAIT: 0

PS:允许行使TRUNCATE TABLE语句

MAX _TIMER_WAIT: 0

events_stages_history_long 表

1 row in set (0.01 sec)

events_stages_history_long表富含近日的N个阶段事件。
在server运转时,N的值会自动调节。
要是要显式设置N值大小,能够在server运行在此以前设置系统变量performance_schema_events_stages_history_long_size的值。stages事件推行完结时才会增多到events_stages_history_long表中,当增添新事件到events_stages_history_long表时,如果events_stages_history_long表已满,则会扬弃该表中较旧的事件events_stages_history_long与events_stages_current表结构同样

# events_stages_summary_by_host_by_event_name表

PS:允许利用TRUNCATE TABLE语句

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

讲话事件记录表与等待事件记录表同样,也可以有三张表,那个表记录了日前与前段时间在MySQL实例中产生了怎么语句事件,时间消耗是有个别。记录了美妙绝伦的讲话推行暴发的讲话事件消息。

HOST: localhost

要注意:语句事件相关布署中,setup_instruments表中statement/*始发的享有instruments配置暗中认可开启,setup_consumers表中statements相关的consumers配置暗中认可开启了events_statements_current、events_statements_history、statements_digest(对应events_statements_summary_by_digest表,详见后续章节)但未有开启events_statements_history_long。

EVENT_NAME: stage/sql/After create

events_statements_current 表

COUNT_STAR: 0

events_statements_current表包罗当前讲话事件,各种线程只体现一行方今被监视语句事件的当前情景。

SUM _TIMER_WAIT: 0

在含有语句事件行的表中,events_statements_current当前风浪表是基础表。其余包罗语句事件表中的多寡在逻辑上来自当前事变表(汇总表除此而外)。比如:events_statements_history和events_statements_history_long表是多年来的说话事件历史的集中,events_statements_history表中种种线程暗中认可保留10行事件历史新闻,events_statements_history_long表中暗许全体线程保留10000行事件历史新闻

MIN _TIMER_WAIT: 0

表记录内容示例(以下消息依然来自select
sleep(100);语句的口舌事件音信)

AVG _TIMER_WAIT: 0

root@localhost : performance_schema 12: 36: 35> select * from
events_statements_current where SQL_TEXT= ‘select sleep(100)’G;

MAX _TIMER_WAIT: 0

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

1 row in set (0.00 sec)

THREAD_ID: 46

# events_stages_summary_by_thread_by_event_name表

EVENT_ID: 334

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

END_EVENT_ID: NULL

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

EVENT_NAME: statement/sql/select

THREAD_ID: 1

SOURCE: socket_connection.cc: 101

EVENT_NAME: stage/sql/After create

TIMER_START: 15354770719802000

COUNT_STAR: 0

TIMER_END: 15396587017809000

SUM _TIMER_WAIT: 0

TIMER_WAIT: 41816298007000

MIN _TIMER_WAIT: 0

LOCK_TIME: 0

AVG _TIMER_WAIT: 0

SQL_TEXT: select sleep( 100)

MAX _TIMER_WAIT: 0

DIGEST: NULL

1 row in set (0.01 sec)

DIGEST_TEXT: NULL

# events_stages_summary_by_user_by_event_name表

CURRENT_SCHEMA: NULL

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

OBJECT_TYPE: NULL

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

OBJECT_SCHEMA: NULL

USER: root

OBJECT_NAME: NULL

EVENT_NAME: stage/sql/After create

OBJECT_INSTANCE_BEGIN: NULL

COUNT_STAR: 0

MYSQL_ERRNO: 0

SUM _TIMER_WAIT: 0

RETURNED_SQLSTATE: NULL

MIN _TIMER_WAIT: 0

MESSAGE_TEXT: NULL

AVG _TIMER_WAIT: 0

ERRORS: 0

MAX _TIMER_WAIT: 0

WARNINGS: 0

1 row in set (0.00 sec)

ROWS_AFFECTED: 0

# events_stages_summary_global_by_event_name表

ROWS_SENT: 0

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

ROWS_EXAMINED: 0

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

CREATED_TMP_DISK_TABLES: 0

EVENT_NAME: stage/sql/After create

CREATED_TMP_TABLES: 0

COUNT_STAR: 0

SELECT_FULL_JOIN: 0

SUM _TIMER_WAIT: 0

SELECT_FULL_RANGE_JOIN: 0

MIN _TIMER_WAIT: 0

SELECT_RANGE: 0

AVG _TIMER_WAIT: 0

SELECT_RANGE_CHECK: 0

MAX _TIMER_WAIT: 0

SELECT_SCAN: 0

1 row in set (0.00 sec)

SORT_MERGE_PASSES: 0

从上边表中的身体力行记录音讯中,大家得以看来,同样与等待事件类似,依据客商、主机、顾客+主机、线程等纬度实行分组与总结的列,那一个列的含义与等待事件类似,这里不再赘述。

SORT_RANGE: 0

注意:那个表只针对阶段事件音信举办总括,即包含setup_instruments表中的stage/%开头的搜罗器,每一种阶段事件在各种表中的计算记录行数必要看怎么着分组(举例:依照客户分组总计的表中,有稍许个活泼客户,表中就能够有微微条同样采撷器的笔录),其它,计臆想数器是不是见效还索要看setup_instruments表中相应的阶段事件收集器是还是不是启用。

SORT_ROWS: 0

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

SORT_SCAN: 0

| 事务事件总括表

NO_INDEX_USED: 0

performance_schema把业务事件总结表也如约与等待事件总括表类似的准则举行分类总计,事务事件instruments独有三个transaction,暗中认可禁止使用,事务事件计算表有如下几张表:

NO_GOOD_INDEX_USED: 0

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

NESTING_EVENT_ID: NULL

+————————————————————–+

NESTING_EVENT_TYPE: NULL

| Tables_in_performance_schema (%events_transactions_summary%) |

NESTING_EVENT_LEVEL: 0

+————————————————————–+

1row in set ( 0.00sec)

| events_transactions_summary_by_account_by_event_name |

如上的输出结果与话语的守候事件情势类似,这里不再赘言,events_statements_current表完整的字段含义如下:

| events_transactions_summary_by_host_by_event_name |

THREAD_ID,EVENT_ID:与事件涉及的线程号和事件运行时的平地风波编号,能够采取THREAD_ID和EVENT_ID列值来独一标志该行,这两行的值作为整合条件时不会冒出同样的数据行

| events_transactions_summary_by_thread_by_event_name |

END_EVENT_ID:当多少个事件始于实行时,对应行记录的该列值被安装为NULL,当一个事变实践落成时,对应的行记录的该列值被更新为该事件的ID

| events_transactions_summary_by_user_by_event_name |

EVENT_NAME:产滋事件的监视仪器的名号。该列值来自setup_instruments表的NAME值。对于SQL语句,EVENT_NAME值最先的instruments是statement/com/Query,直到语句被解析之后,会改造为更适于的具体instruments名称,如:statement/sql/insert

| events_transactions_summary_global_by_event_name |

SOURCE:源文件的称谓及其用于检查测量试验该事件的代码位于源文件中的行号,您能够检查源代码来鲜明涉及的代码

+————————————————————–+

TIMER_START,TIMER_END,TIMER_WAIT:事件的日子音信。这么些值的单位是阿秒(万亿分之一秒)。
TIMEEvoque_START和TIMER_END值表示事件的始发时间和了结时间。TIMEEscort_WAIT是事件实践消耗的小时(持续时间)

5rows inset ( 0. 00sec)

  • 一旦事件未推行到位,则TIMERubicon_END为当下光阴,TIME翼虎_WAIT为日前得了所通过的年华(TIMELAND_END –
    TIMER_START)。
  • 设若监视仪器配置表setup_instruments中对应的监视器TIMED字段被设置为
    NO,则不会搜集该监视器的时刻消息,那么对于该事件访谈的信息记录中,TIME哈弗_START,TIMER_END和TIMER_WAIT字段值均为NULL

笔者们先来看看那个表中著录的总结音讯是什么样子的(由于单行记录较长,这里只列出events_transactions_summary_by_account_by_event_name表中的示例数据,其他表的示范数据省略掉一部分雷同字段)。

LOCK_TIME:等待表锁的年华。该值以微秒进行计算,但结尾转变为阿秒展现,以便更便于与别的performance_schema中的电磁打点计时器举行相比

# events_transactions_summary_by_account_by_event_name表

SQL_TEXT:SQL语句的文件。要是该行事件是与SQL语句毫无干系的command事件,则该列值为NULL。私下认可情形下,语句最大呈现长度为1024字节。假如要修改,则在server运营此前设置系统变量performance_schema_max_sql_text_length的值

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

DIGEST:语句摘抄的MD5
hash值,为三十七位十六进制字符串,假若在setup_consumers表中statement_digest配置行未有拉开,则语句事件中该列值为NULL

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

DIGEST_TEXT:标准化转变过的言语摘抄文本,若是setup_consumers表中statements_digest配置行未有拉开,则语句事件中该列值为NULL。performance_schema_max_digest_length系统变量支配着在存入该表时的最大摘要语句文本的字节长度(默感觉1024字节),要留意:用于总括摘要语句文本的原始语句文本字节长度由系统变量max_digest_length调控,而存入表中的字节长度由系统变量performance_schema_max_digest_length控制,所以,如果performance_schema_max_digest_length小于max_digest_length时,总结出的摘要语句文本一经超(英文名:jīng chāo)出了performance_schema_max_digest_length定义的长度会被截断

USER: root

CURRENT_SCHEMA:语句使用的暗许数据库(使用use
db_name语句就可以钦命暗许数据库),若无则为NULL

HOST: localhost

OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE:对于嵌套语句(存款和储蓄程序最后是经过说话调用的,所以倘若叁个讲话是由存款和储蓄程序调用的,尽管说那几个讲话事件是嵌套在蕴藏程序中的,可是事实上对于事件类型来说,还是是嵌套在言语事件中),这个列包罗关于父语句的音讯。假如不是嵌套语句恐怕是父语句作者暴发的事件,则那几个列值为NULL

EVENT_NAME: transaction

OBJECT_INSTANCE_BEGIN:语句的有一无二标记,该列值是内部存款和储蓄器中对象的地址

COUNT_STAR: 7

MYSQL_E奇骏LX570NO:语句实践的不当号,此值来自代码区域的讲话会诊区域

SUM _TIMER_WAIT: 8649707000

RETURNED_SQLSTATE:语句施行的SQLSTATE值,此值来自代码区域的口舌检查判断区域

MIN _TIMER_WAIT: 57571000

MESSAGE_TEXT:语句试行的有血有肉错误新闻,此值来自代码区域的讲话检查判断区域

AVG _TIMER_WAIT: 1235672000

E奥迪Q5ROQX56S:语句实施是还是不是发生错误。要是SQLSTATE值以00(完结)或01(警告)初步,则该列值为0。别的任何SQLSTATE值时,该列值为1

MAX _TIMER_WAIT: 2427645000

WA中华VNINGS:语句警告数,此值来自代码区域的口舌会诊区域

COUNT _READ_WRITE: 6

ROWS_AFFECTED:受该语句影响的行数。有关“受影响”的意思的叙述,参见连接:

SUM _TIMER_READ_WRITE: 8592136000

  • 使用mysql_query()或mysql_real_query()函数实行语句后,恐怕会立马调用mysql_affected_rows()函数。借使是UPDATE,DELETE或INSERT,则赶回最终一条语句改换、删除、插入的行数。对于SELECT语句,mysql_affected_rows()的行事章程与mysql_num_rows()一样(在执行结果最后回到的新闻中看不到effected总计音讯)
  • 对此UPDATE语句,受影响的行值默以为实际改造的行数。假诺在接连到mysqld时钦命了CLIENT_FOUND_ROWS标志给mysql_real_connect()函数,那么affected-rows的值是“found”的行数。即WHERE子句相称到的行数
  • 对此REPLACE语句,倘使爆发新旧行替换操作,则受影响的行值为2,因为在这种状态下,实际上是先删除旧值,后插入新值三个行操作
  • 对于INSERT … ON DUPLICATE KEY
    UPDATE语句,假设行作为新行插入,则每行的affected计数为1,假设发生旧行更新为新行则每行affected计数为2,若无发出任何插入和换代,则每行的affected计数为0
    (但万一钦点了CLIENT_FOUND_ROWS标记,则未有发生其余的插入和翻新时,即set值就为这两天的值时,每行的受影响行值计数为1并非0)
  • 在仓库储存进程的CALL语句调用之后,mysql_affected_rows()再次回到的震慑行数是储存程序中的最终八个讲话推行的影响行数值,假若该语句重返-1,则存款和储蓄程序最终再次回到0受影响。所以在仓库储存程序实行时回来的震慑行数并不保障,可是你能够自动在存储程序中贯彻叁个计数器变量在SQL等级使用ROW_COUNT()来赢得各样语句的受影响的行值并相加,最终通过存款和储蓄程序重临那一个变量值。
  • 在MySQL
    5.7中,mysql_affected_rows()为越多的言辞重临叁个有意义的值。

MIN _TIMER_READ_WRITE: 87193000

*
1)、对于DDL语句,row_count()函数重返0,比如:CREATE TABLE、ALTER
TABLE、DROP TABLE之类的语句

AVG _TIMER_READ_WRITE: 1432022000

*
2)、对于除SELECT之外的DML语句:row_count()函数再次回到实际多少变动的行数。举个例子:UPDATE、INSERT、DELETE语句,今后也适用于LOAD
DATA
INFILE之类的语句,大于0的重临值表示DML语句做了数量变动,假设回去为0,则意味DML语句未有做任何数据变动,或然尚未与where子句相称的记录,假诺回去-1则代表语句重回了不当

MAX _TIMER_READ_WRITE: 2427645000

*
3)、对于SELECT语句:row_count()函数重返-1,比方:SELECT * FROM
t1语句,ROW_COUNT()返回-1(对于select语句,在调用mysql_store_result()此前调用了mysql_affected_rows()再次回到了)。然则对于SELECT
* FROM t1 INTO
OUTFILE’file_name’那样的语句,ROW_COUNT()函数将再次回到实际写入文件中的数据行数

COUNT _READ_ONLY: 1

*
4)、对于SIGNAL语句:row_count()函数再次回到0

SUM _TIMER_READ_ONLY: 57571000

*
5)、因为mysql_affected_rows()再次来到的是贰个无符号值,所以row_count()函数重返值小于等于0时都改变为0值再次回到或然不回去给effected值,row_count()函数重返值大于0时则赶回给effected值

MIN _TIMER_READ_ONLY: 57571000

ROWS_SENT:语句重返给客商端的数目行数

AVG _TIMER_READ_ONLY: 57571000

ROWS_EXAMINED:在试行语句时期从存款和储蓄引擎读取的多寡行数

MAX _TIMER_READ_ONLY: 57571000

CREATED_TMP_DISK_TABLES:像Created_tmp_disk_tables状态变量同样的计数值,然而此间只用于那一个事件中的语句计算而不针对全局、会话等级

1 row in set (0.00 sec)

CREATED_TMP_TABLES:像Created_tmp_tables状态变量同样的计数值,可是此地只用于那些事件中的语句总括而不对准全局、会话等第

# events_transactions_summary_by_host_by_event_name表

SELECT_FULL_JOIN:像Select_full_join状态变量同样的计数值,可是这里只用于这么些事件中的语句总计而不针对全局、会话等级

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

SELECT_FULL_RANGE_JOIN:像Select_full_range_join状态变量同样的计数值,不过此间只用于那些事件中的语句总括而不对准全局、会话等第

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

SELECT_RANGE:就像Select_range状态变量同样的计数值,可是此地只用于那一个事件中的语句计算而不针对全局、会话等第

HOST: localhost

SELECT_RANGE_CHECK:像Select_range_check状态变量一样的计数值,不过这里只用于这一个事件中的语句总计而不对准全局、会话品级

EVENT_NAME: transaction

SELECT_SCAN:像Select_scan状态变量一样的计数值,可是此间只用于那些事件中的语句总括而不针对全局、会话品级

COUNT_STAR: 7

SORT_MERGE_PASSES:像Sort_merge_passes状态变量同样的计数值,可是此地只用于这一个事件中的语句总计而不对准全局、会话等第

……

SORT_RANGE:像Sort_range状态变量同样的计数值,不过这里只用于这一个事件中的语句总括而不针对全局、会话等第

1 row in set (0.00 sec)

SORT_ROWS:像Sort_rows状态变量同样的计数值,可是此间只用于那个事件中的语句总括而不对准全局、会话等级

# events_transactions_summary_by_thread_by_event_name表

SORT_SCAN:像Sort_scan状态变量同样的计数值,但是这里只用于这么些事件中的语句总括而不对准全局、会话等级

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

NO_INDEX_USED:若是语句实践表扫描而不接纳索引,则该列值为1,不然为0

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

NO_GOOD_INDEX_USED:假如服务器找不到用于该语句的合适索引,则该列值为1,不然为0

THREAD_ID: 46

NESTING_EVENT_ID,NESTING_EVENT_TYPE,NESTING_EVENT_LEVEL:那三列与任何列结合一齐行使,为一品(未知抽象的说话可能说是父语句)语句和嵌套语句(在存款和储蓄的前后相继中实施的讲话)提供以下事件新闻

EVENT_NAME: transaction

  • 对此顶尖语句:

COUNT_STAR: 7

OBJECT_TYPE = NULL,OBJECT_SCHEMA =
NULL,OBJECT_NAME = NULL,NESTING_EVENT_ID = NULL,NESTING_EVENT_TYPE
= NULL,NESTING_LEVEL = 0

……

  • 对此嵌套语句:OBJECT_TYPE =父语句对象类型,OBJECT_SCHEMA
    =父语句数据库级名称,OBJECT_NAME
    =父语句表级对象名称,NESTING_EVENT_ID
    =父语句EVENT_ID,NESTING_EVENT_TYPE =’STATEMENT’,NESTING_LEVEL
    =父语句NESTING_LEVEL加一,比如:1,表示父语句的下一层嵌套语句

1 row in set (0.00 sec)

允许选择TRUNCATE TABLE语句

# events_transactions_summary_by_user_by_event_name表

events_statements_history 表

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

events_statements_history表富含种种线程最新的N个语句事件。
在server运营时,N的值会自动调治。
要显式设置N的大大小小,能够在server运维之前安装系统变量performance_schema_events_statements_history_size的值。
statement事件试行到位时才会增加到该表中。
当加多新事件到该表时,若是对应线程的事件在该表中的分配的定额已满,则会甩掉对应线程的较旧的风云

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

events_statements_history与events_statements_current表结构同样

USER: root

PS:允许使用TRUNCATE TABLE语句

EVENT_NAME: transaction

events_statements_history_long 表

COUNT_STAR: 7

events_statements_history_long表满含方今的N个语句事件。在server运维时,N的值会自动调治。
要显式设置N的尺寸,能够在server运维此前设置系统变量performance_schema_events_statements_history_long_size的值。
statement事件供给实施实现时才会增多到该表中。
当增加新事件到该表时,倘使该表的全局分配的定额已满,则会抛弃该表中较旧的事件

……

events_statements_history_long与events_statements_current表结构一样

1 row in set (0.00 sec)

PS:允许行使TRUNCATE TABLE语句

# 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

专门的学问事件记录表与等待事件记录表一样,也可能有三张表,这一个表记录了当前与那二日在MySQL实例中发生了什么样事情事件,时间消耗是多少

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

要潜心:事务事件有关配置中,setup_instruments表中独有贰个名字为transaction的instrument,暗中同意关闭,setup_consumers表中transactions相关的consumers配置暗许关闭了

EVENT_NAME: transaction

events_transactions_current 表

COUNT_STAR: 7

events_transactions_current表满含当前事情事件音信,每一种线程只保留一行近年来政工的政工事件

……

在蕴藏事务事件新闻的表中,events_transactions_current是基础表。其余包含事务事件新闻的表中的数据逻辑上来自当前事件表。比方:events_transactions_history和events_transactions_history_long表分别满含每种线程方今10行事务事件音信和大局方今10000行事务事件音讯

1 row in set (0.00 sec)

表记录内容示例(以下新闻来自对某表实践了贰遍select等值查询的业务事件新闻)

从地点表中的事必躬亲记录音讯中,我们能够看到,一样与等待事件类似,依照客商、主机、顾客+主机、线程等纬度进行分组与总结的列,这几个列的意义与等待事件类似,这里不再赘述,但对于工作总结事件,针对读写事务和只读事务还独自做了总括(xx_READ_WRITE和xx_READ_ONLY列,只读事务供给安装只读事务变量transaction_read_only=on才会进展计算)。

root@localhost : performance _schema 12:50:10> select * from
events_transactions_currentG;

注意:那些表只针对职业事件音讯进行总括,即含有且仅包涵setup_instruments表中的transaction采撷器,种种事情事件在每一个表中的计算记录行数必要看什么分组(举个例子:依据顾客分组计算的表中,有多少个活泼客商,表中就能够有稍许条同样收罗器的记录),其余,总结计数器是不是见效还需求看transaction搜罗器是不是启用。

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

作业聚合总结法规

THREAD_ID: 46

*
事务事件的征集不思考隔断等第,访谈格局或自行提交方式

EVENT_ID: 38685

*
读写作业日常比只读事务占用越来越多能源,由那件事务总计表包括了用来读写和只读事务的单身总结列

END_EVENT_ID: 38707

*
事务所占用的财富须要多少也说不定会因业务隔开等级有所差别(比方:锁能源)。不过:每一个server或者是应用同样的隔开等级,所以不单独提供隔开分离等第相关的计算列

EVENT_NAME: transaction

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

STATE: COMMITTED

| 语句事件总计表

TRX_ID: 422045139261264

performance_schema把语句事件总计表也如约与等待事件总计表类似的法则进行分类总结,语句事件instruments私下认可全体展开,所以,语句事件总括表中暗中认可会记录全部的言语事件总结新闻,言辞事件总结表包涵如下几张表:

GTID: AUTOMATIC

events_statements_summary_by_account_by_event_name:依据每种帐户和语句事件名称进行总结

XID_FORMAT_ID: NULL

events_statements_summary_by_digest:根据各种库等级对象和话语事件的原始语句文本总结值(md5
hash字符串)实行总计,该总括值是依照事件的原始语句文本实行简易(原始语句调换为尺度语句),每行数据中的相关数值字段是独具同等总计值的总括结果。

XID_GTRID: NULL

events_statements_summary_by_host_by_event_name:根据各样主机名和事件名称进行总括的Statement事件

XID_BQUAL: NULL

events_statements_summary_by_program:根据每种存款和储蓄程序(存款和储蓄进程和函数,触发器和事件)的轩然大波名称进行总计的Statement事件

XA_STATE: NULL

events_statements_summary_by_thread_by_event_name:根据每一个线程和事件名称举办总结的Statement事件

SOURCE: handler.cc:1421

events_statements_summary_by_user_by_event_name:根据每一个客户名和事件名称进行总括的Statement事件

TIMER_START: 16184509764409000

events_statements_summary_global_by_event_name:依据各类事件名称进行总结的Statement事件

TIMER_END: 16184509824175000

prepared_statements_instances:依照每一个prepare语句实例聚合的计算音讯

TIMER_WAIT: 59766000

可通过如下语句查看语句事件总计表:

ACCESS_MODE: READ WRITE

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

ISOLATION_LEVEL: READ COMMITTED

+————————————————————+

AUTOCOMMIT: YES

| Tables_in_performance_schema (%events_statements_summary%) |

NUMBER_OF_SAVEPOINTS: 0

+————————————————————+

NUMBER _OF_ROLLBACK _TO_SAVEPOINT: 0

| events_statements_summary_by_account_by_event_name |

NUMBER _OF_RELEASE_SAVEPOINT: 0

| events_statements_summary_by_digest |

OBJECT_INSTANCE_BEGIN: NULL

| events_statements_summary_by_host_by_event_name |

NESTING_EVENT_ID: 38667

| events_statements_summary_by_program |

NESTING_EVENT_TYPE: STATEMENT

| events_statements_summary_by_thread_by_event_name |

1 row in set (0.00 sec)

| events_statements_summary_by_user_by_event_name |

上述的出口结果与话语的等候事件格局类似,这里不再赘述,events_transactions_current表完整字段含义如下:

| events_statements_summary_global_by_event_name |

THREAD_ID,EVENT_ID:与事件涉及的线程号和事件运营时的事件编号,能够接纳THREAD_ID和EVENT_ID列值来独一标记该行,这两行的值作为整合条件时不会见世一样的数据行

+————————————————————+

END_EVENT_ID:当叁个平地风波先河奉行时,对应行记录的该列值被装置为NULL,当贰个事变实施达成时,对应的行记录的该列值被更新为该事件的ID

7rows inset ( 0. 00sec)

EVENT_NAME:搜集该业务事件的instruments的称呼。来自setup_instruments表的NAME列值

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

STATE:当前作业状态。有效值为:ACTIVE(实践了START
TRANSACTION或BEGIN语句之后,事务未提交或未回滚以前)、COMMITTED(试行了COMMIT之后)、ROLLED
BACK(实行了ROLLBACK语句之后)

+——————————————+

TRX_ID:未利用,字段值总是为NULL

| Tables_in_performance_schema (%prepare%) |

GTID:包含gtid_next系统变量的值,其值大概是格式为:UUID:NUMBEENCORE的GTID,也恐怕是:ANONYMOUS、AUTOMATIC。对于AUTOMATIC列值的事务事件,GTID列在业务提交和对应事务的GTID实际分配时都展销会开更换(如若gtid_mode系统变量为ON或ON_PERMISSIVE,则GTID列将改成为业务的GTID,假诺gtid_mode为OFF或OFF_PERMISSIVE,则GTID列将改成为ANONYMOUS)

+——————————————+

XID_FORMAT_ID,XID_GTRID和XID_BQUAL:XA事务标记符的组件。关于XA事务语法详见链接:

| prepared_statements_instances |

XA_STATE:XA事务的情景。有效值为:ACTIVE(实行了XA
START之后,未举办另外后续XA语句在此之前)、IDLE(施行了XA
END语句之后,未执行其它后续XA语句在此之前)、PREPARED(实践了XA
PREPARE语句之后,未举行别的后续XA语句在此以前)、ROLLED BACK(施行了XA
ROLLBACK语句之后,未奉行别的后续XA语句在此以前)、COMMITTED(实践了XA
COMMIT语句之后)

+——————————————+

SOURCE:源文件的名目及其用于检查评定该事件的代码位于源文件中的行号,您能够检查源代码来分明涉及的代码

1row inset ( 0. 00sec)

TIMER_START,TIMER_END,TIMER_WAIT:事件的日子信息。这么些值的单位是阿秒(万亿分之一秒)。TIME中华V_START和TIMER_END值表示事件的发端时间和终结时间。TIMECRUISER_WAIT是事件实行消耗的小时(持续时间)

笔者们先来探视那么些表中著录的总计音信是怎么着体统的(由于单行记录较长,这里只列出events_statements_summary_by_account_by_event_name
表中的示例数据,其他表的演示数据省略掉一部分雷同字段)。

  • 只要事件未进行到位,则TIME奔驰G级_END为日前光阴,TIME福睿斯_WAIT为当下终止所经过的时光(TIME凯雷德_END –
    TIMER_START)
  • 假定监视仪器配置表setup_instruments中对应的监视器TIMED字段被设置为
    NO,则不会采撷该监视器的时间音讯,那么对于该事件采访的消息记录中,TIMEQashqai_START,TIMER_END和TIMER_WAIT字段值均为NULL

# events_statements_summary_by_account_by_event_name表

ACCESS_MODE:事务访问方式。有效值为:READ ONLY或READ WCRUISERITE

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

ISOLATION_LEVEL:事务隔开等级。有效值为:REPEATABLE READ、READ COMMITTED、READ
UNCOMMITTED、SEQX56IALIZABLE

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

AUTOCOMMIT:在事情开始时是否启用了自行提交形式,借使启用则为YES,未有启用则为NO

USER: root

NUMBER_OF_SAVEPOINTS,NUMBER_OF_ROLLBACK_TO_SAVEPOINT,NUMBER_OF_RELEASE_SAVEPOINT:在事行业内部进行的SAVEPOINT,ROLLBACK
TO SAVEPOINT和RELEASE SAVEPOINT语句的数额

HOST: localhost

OBJECT_INSTANCE_BEGIN:未使用,字段值总是为NULL

EVENT_NAME: statement/sql/select

NESTING_EVENT_ID:嵌套事务事件的父事件EVENT_ID值

COUNT_STAR: 53

NESTING_EVENT_TYPE:嵌套事件类型。有效值为:TRANSACTION、STATEMENT、STAGE、WAIT
(由于作业不可能嵌套,由此该列值不会晤世TRANSACTION)

SUM_TIMER_WAIT: 234614735000

同意利用TRUNCATE TABLE语句

MIN_TIMER_WAIT: 72775000

events_transactions_history 表

AVG_TIMER_WAIT: 4426693000

events_transactions_history表包涵每一个线程近期的N个事务事件。
在server运转时,N的值会自动调解。
要显式设置N的轻重缓急,能够在server运转在此以前安装系统变量

MAX_TIMER_WAIT: 80968744000

performance_schema_events_transactions_history_size的值。事务事件未施行到位此前不会增添到该表中。当有新的事体育赛事件增多到该表时,借使该表已满,则会丢弃对应线程较旧的职业事件

SUM_LOCK_TIME: 26026000000

events_transactions_history与events_transactions_current表结构同样

SUM_ERRORS: 2

PS:允许行使TRUNCATE TABLE语句

SUM_WARNINGS: 0

events_transactions_history_long 表

SUM_ROWS_AFFECTED: 0

events_transactions_history_long表包涵全局这两天的N个事务事件。在server运营时,N的值会自动调治。
要显式设置N的大大小小,能够在server运行在此以前安装系统变量

SUM_ROWS_SENT: 1635

performance_schema_events_transactions_history_long_size的值。事务事件在实施完从前不会增加到该表中。当加多新业务事件时,假诺该表已满,则会扬弃较旧的事件

SUM_ROWS_EXAMINED: 39718

events_transactions_history_long与events_transactions_current表结构同样

SUM _CREATED_TMP _DISK_TABLES: 3

PS:允许采取TRUNCATE TABLE语句

SUM _CREATED_TMP_TABLES: 10

下一篇将为我们分享 《事件计算 |
performance_schema 全方位介绍》
,谢谢您的读书,大家不见不散!归来新浪,查看更加多

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表中新插队一行总结信息,FIPRADOST_SEEN和LAST_SEEN列都施用当前岁月

*
假若给定语句的总括消息行在events_statements_summary_by_digest表中尚无已存在行,且events_statements_summary_by_digest表空间范围已满的意况下,则该语句的总括新闻将增进到DIGEST
列值为
NULL的特有“catch-all”行,假如该极其行不设有则新插入一行,FIENVISIONST_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_STAEnclave列值侵占整个表中全数总括新闻的COUNT_STATucson列值的比例大于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将重新初始化为CUEnclaveRENT_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全方位介绍》
,多谢你的开卷,大家不见不散!回来新浪,查看更多

网编:

相关文章