原标题:数据库对象事件与质量总括 | performance_schema全方位介绍(五)

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

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

明日有人问有没有点子查看表的注释,或询问所有表的注释。那里所说的表或表字段等的诠释,其实是数据库对象的恢宏属性。在MSSQL中,辅助把一部分注释性的情节放到数据库或数据库对象中,增强可读性,有助于将来的管理和护卫工作。扩张属性的内容可以经过SSMS添加、修改或删除,也得以透过系统视图查询,通过实践有关的仓储进度来尊崇。

ca88国际娱乐城 1

ca88国际娱乐城 2

ca88国际娱乐城 3

成立一张测试表:

上一篇 《事件统计 |
performance_schema全方位介绍》详细介绍了performance_schema的事件计算表,但这几个统计数据粒度太粗,仅仅依据事件的5大项目+用户、线程等维度举行归类统计,但有时候大家须要从更细粒度的维度进行分拣总括,例如:某个表的IO开支多少、锁成本多少、以及用户连接的有的属性总计音讯等。此时就须求查阅数据库对象事件计算表与性能总计表了。明日将辅导大家一齐踏上铺天盖地第五篇的道路(全系共7个篇章),本期将为我们无微不至授课performance_schema中目标事件总括表与特性统计表。下边,请随行我们一起起来performance_schema系统的读书之旅吧~

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

导语

IF OBJECT_ID(N'T8') IS NOT NULL
BEGIN
    DROP TABLE T8
END
GO

CREATE TABLE T8 (
    id INT NOT NULL,
    name NVARCHAR(100)
)
GO

友谊提示:下文中的统计表中多数字段含义与上一篇
《事件总结 | performance_schema全方位介绍》
中关系的计算表字段含义相同,下文中不再赘言。其它,由于局地总结表中的笔录内容过长,限于篇幅会简单部分文件,如有需求请自行安装MySQL
5.7.11以上版本跟随本文举行同步操作查看。

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

在上一篇 《配置详解 |
performance_schema全方位介绍》中,我们详细介绍了performance_schema的配置表,锲而不舍读完的是真爱,也恭喜大家翻过了一座火焰山。相信有很多个人读完事后,已经十万火急的想要蓄势待发了,今日将教导我们一块儿踏上铺天盖地第三篇的征途(全系共6个篇章),在这一期里,大家将为大家无微不至授课performance_schema中事件原本记录表。下边,请随行咱们一起起来performance_schema系统的学习之旅吧。

code-1

01

IT从业多年,历任运维工程师、高级运维工程师、运维CEO、数据库工程师,曾插足版本宣布连串、轻量级监控体系、运维管理平台、数据库管理平台的设计与编制,熟稔MySQL连串布局,Innodb存储引擎,喜好专研开源技术,追求完善。

等候事件表

 

数据库对象计算表

| 导语

一般,大家在遇见质量瓶颈时,假如其余的格局难以找出性能瓶颈的时候(例如:硬件负载不高、SQL优化和库表结构优化都不便奏效的时候),大家平日需求依靠等待事件来进展剖析,找出在MySQL
Server内部,到底数据库响应慢是慢在哪儿。

添加表的壮大属性:在Object Explorer中找到新建的表,右键选用属性。

1.数目库表级别对象等待事件统计

在上一篇《事件记录 |
performance_schema全方位介绍”》中,我们详细介绍了performance_schema的风浪记录表,恭喜大家在就学performance_schema的路上度过了三个最费力的时日。现在,相信大家早就比较清楚什么是事件了,但偶尔我们不须要通晓每时每刻暴发的每一条事件记录新闻,
例如:我们希望精晓数据库运行以来一段时间的风云总结数据,这些时候就要求查阅事件计算表了。前天将教导大家一齐踏上聚讼纷繁第四篇的道路(全系共7个篇章),在这一期里,大家将为大家无微不至授课performance_schema中事件计算表。总结事件表分为5个门类,分别为等候事件、阶段事件、语句事件、事务事件、内存事件。上面,请跟随大家联合起来performance_schema系统的学习之旅吧。

等待事件记录表包罗三张表,那么些表记录了方今与近日在MySQL实例中爆发了哪些等待事件,时间花费是有点。

ca88国际娱乐城 4

遵守数据库对象名称(库级别对象和表级别对象,如:库名和表名)进行总计的等候事件。根据OBJECT_TYPE、OBJECT_SCHEMA、OBJECT_NAME列举办分组,依据COUNT_STAR、xxx_TIMER_WAIT字段举行计算。包括一张objects_summary_global_by_type表。

| 等待事件总计表

  • events_waits_current表:记录当前正在履行的等待事件的,每个线程只记录1行记录
  • events_waits_history表:记录已经举行完的近年的等候事件历史,默许每个线程只记录10行记录
  • events_waits_history_long表:记录已经施行完的近年的等候事件历史,默许所有线程的总记录行数为10000行

 figure-1

大家先来探视表中记录的总计信息是什么样体统的。

performance_schema把等待事件计算表依照分裂的分组列(分歧纬度)对等候事件相关的数目举行联谊(聚合总结数据列包罗:事件暴发次数,总等待时间,最小、最大、平均等待时间),注意:等待事件的采访功能有一些默许是剥夺的,必要的时候能够经过setup_instruments和setup_objects表动态开启,等待事件计算表包含如下几张表:

要注意:等待事件有关配置中,setup_instruments表中多方面的守候事件instruments都并未拉开(IO相关的等候事件instruments默许大多数已开启),setup_consumers表中waits相关的consumers配置默许没有开启

 

admin@localhost : performance _schema 11:10:42> select * from
objects_summary _global_by _type where SUM_TIMER_WAIT!=0G;

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

events_waits_current 表

点击扩张属性,即可举行添加、修改和删除。

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

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

events_waits_current表包括当前的等待事件消息,每个线程只展示一行近期监视的等候事件的当前事态

ca88国际娱乐城 5

OBJECT_TYPE: TABLE

| Tables_in_performance_schema (%events_waits_summary%) |

在富有包蕴等待事件行的表中,events_waits_current表是最基础的数码来源于。别的包涵等待事件数据表在逻辑上是来自events_waits_current表中的当前事变音讯(汇总表除外)。例如,events_waits_history和events_waits_事件统计,数据库对象事件与属性统计。history_long表中的数据是events_waits_current表数据的一个小集合汇总(具体存放多少行数据集合有各自的变量支配)

 figure-2

OBJECT_SCHEMA: xiaoboluo

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

表记录内容示例(那是一个推行select
sleep(100);语句的线程等待事件消息)

 

OBJECT_NAME: test

| events_waits_summary_by_account_by_event_name |

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

添加字段的扩张属性。

COUNT_STAR: 56

| events_waits_summary_by_host_by_event_name |

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

ca88国际娱乐城 6

SUM _TIMER_WAIT: 195829830101250

| events_waits_summary_by_instance |

THREAD_ID: 46

 figure-3

MIN _TIMER_WAIT: 2971125

| events_waits_summary_by_thread_by_event_name |

EVENT_ID: 140

 

AVG _TIMER_WAIT: 3496961251500

| events_waits_summary_by_user_by_event_name |

END_EVENT_ID: NULL

字段属性——描述,添加注释内容。

MAX _TIMER_WAIT: 121025235946125

| events_waits_summary_global_by_event_name |

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

ca88国际娱乐城 7

1 row in set (0.00 sec)

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

SOURCE: item_func.cc:5261

 figure-4

从表中的记录内容可以看出,根据库xiaoboluo下的表test举办分组,总计了表相关的等候事件调用次数,总结、最小、平均、最大延迟时间新闻,利用这个音讯,我们可以大体驾驭InnoDB中表的走访功用名次计算情状,一定水平上影响了对存储引擎接口调用的频率。

6rows inset ( 0. 00sec)

TIMER_START: 14128809267002592

 

2.表I/O等待和锁等待事件总括

我们先来看望那些表中著录的计算音信是何许样子的。

TIMER_END: 14132636159944419

 

与objects_summary_global_by_type
表计算音信类似,表I/O等待和锁等待事件统计新闻更是精细,细分了各类表的增删改查的实践次数,总等待时间,最小、最大、平均等待时间,甚至精细到某个索引的增删改查的等候时间,表IO等待和锁等待事件instruments(wait/io/table/sql/handler和wait/lock/table/sql/handler
)默许开启,在setup_consumers表中无具体的附和配置,默许表IO等待和锁等待事件计算表中就会总括有关事件音信。包蕴如下几张表:

# events_waits_summary_by_account_by_event_name表

TIMER_WAIT: 3826892941827

保存后,即可已毕对字段扩张属性的拉长。可经过系统视图sys.extended_properties举办询问。

admin@localhost : performance_schema 06:50:03> show tables like
‘%table%summary%’;

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

SPINS: NULL

SELECT *,OBJECT_NAME(major_id) AS obj_name FROM sys.extended_properties

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

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

OBJECT_SCHEMA: NULL

 code-2

| Tables_in_performance_schema (%table%summary%) |

USER: NULL

OBJECT_NAME: NULL

 

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

HOST: NULL

INDEX_NAME: NULL

从下图可观察,刚才在SSMS上加上的习性已经被询问出来。默许的伸张属性名是MS_Description。

| table_io_waits_summary_by_index_usage |#
按照每个索引进行计算的表I/O等待事件

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

OBJECT_TYPE: NULL

ca88国际娱乐城 8

| table_io_waits_summary_by_table |#
根据每个表实行统计的表I/O等待事件

COUNT_STAR: 0

OBJECT _INSTANCE_BEGIN: 140568905519072

 figure-5

| table_lock_waits_summary_by_table |#
根据每个表举办计算的表锁等待事件

SUM _TIMER_WAIT: 0

NESTING _EVENT_ID: 116

 

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

MIN _TIMER_WAIT: 0

NESTING _EVENT_TYPE: STATEMENT

系统视图sys.extended_properties每个字段的详实表达,可查看SQL联机从书。除了系统视图,也可以通过函数fn_listextendedproperty查询。

3rows inset ( 0. 00sec)

AVG _TIMER_WAIT: 0

OPERATION: timed_wait

SELECT objtype, objname, name, value
FROM fn_listextendedproperty(default, 'SCHEMA', 'dbo', 'TABLE', 'T8', default, default);

SELECT objtype,objname,name,value
FROM fn_listextendedproperty(default, 'SCHEMA', 'dbo', 'TABLE', 'T8', 'COLUMN', 'id');

SELECT objtype,objname,name,value
FROM fn_listextendedproperty(default, 'SCHEMA', 'dbo', 'TABLE', 'T8', 'COLUMN', 'name');

俺们先来探视表中著录的总结信息是怎么着体统的。

MAX _TIMER_WAIT: 0

NUMBER _OF_BYTES: NULL

 code-3

# table_ca88国际娱乐城,io_waits_summary_by_index_usage表

1 row in set (0.00 sec)

FLAGS: NULL

 

admin@localhost : performance _schema 01:55:49> select * from
table_io _waits_summary _by_index _usage where
SUM_TIMER_WAIT!=0G;

# events_waits_summary_by_host_by_event_name表

1 row in set (0.00 sec)

ca88国际娱乐城 9

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

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

地点的出口结果中,TIMER_WAIT字段即表示该事件的时辰支出,单位是微秒,在骨子里的利用场景中,大家可以接纳该字段音讯举行倒序排序,以便找出时间支付最大的等候事件。

figure-6

OBJECT_TYPE: TABLE

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

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

 

OBJECT_SCHEMA: xiaoboluo

HOST: NULL

THREAD_ID,EVENT_ID:与事件涉及的线程ID和当前风浪ID。THREAD_ID和EVENT_ID值构成了该事件信息行的绝无仅有标识(不会有再一次的THREAD_ID+EVENT_ID值)

扩大属性可以选取有关的存储进程举行爱护。再实行code-1的代码,重建测试表,相关的性质也会去除。执行存储进程sp_addextendedproperty
进行添加。存储进程的参数使用,请查阅文档,本文末尾提供链接。

OBJECT_NAME: test

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

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

EXEC sp_addextendedproperty 
@name = N'MS_Description',
@value = N'This is a table description on [T8](2).',
@level0type = N'SCHEMA', @level0name = N'dbo',
@level1type = N'TABLE', @level1name = N'T8'
GO

EXEC sp_addextendedproperty 
@name = N'MS_Description',
@value = N'This is a column description on [id](2).',
@level0type = N'SCHEMA', @level0name = N'dbo',
@level1type = N'TABLE', @level1name = N'T8',
@level2type = N'COLUMN', @level2name = N'id'
GO

EXEC sp_addextendedproperty 
@name = N'MS_Description',
@value = N'This is a column description on [name](2).',
@level0type = N'SCHEMA', @level0name = N'dbo',
@level1type = N'TABLE', @level1name = N'T8',
@level2type = N'COLUMN', @level2name = N'name'
GO

INDEX_NAME: PRIMARY

COUNT_STAR: 0

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

code-4

COUNT_STAR: 1

SUM _TIMER_WAIT: 0

SOURCE:暴发该事件的instruments所在的源文件名称以及检测到该事件暴发点的代码行号。您可以查看源代码来确定涉及的代码。例如,假如互斥锁、锁被堵塞,您可以检查爆发那种场合的上下文环境

 

SUM _TIMER_WAIT: 56688392

MIN _TIMER_WAIT: 0

TIMER_START,TIMER_END,TIMER_WAIT:事件的光阴音讯。单位毫秒(万亿分之一秒)。
TIMER_START和TIMER_END值表示事件始于和竣事时间。
TIMER_WAIT是事件经过岁月(即事件实施了多短期)

查询sys.extended_properties,已经成功添加表和字段的扩张属性。

MIN _TIMER_WAIT: 56688392

AVG _TIMER_WAIT: 0

  • 即使事件未履行到位,则TIMER_END为近来计时器时间值(当前时刻),TIMER_WAIT为如今为止所经过的岁月(TIMER_END –
    TIMER_START)
  • 只要采集该事件的instruments配置项TIMED =
    NO,则不会采集事件的时日新闻,TIMER_START,TIMER_END和TIMER_WAIT在那种场地下均记录为NULL

ca88国际娱乐城 10

AVG _TIMER_WAIT: 56688392

MAX _TIMER_WAIT: 0

SPINS:对于互斥量和自旋次数。如果该列值为NULL,则象征代码中平昔不应用自旋或者说自旋没有被监控起来

figure-7

MAX _TIMER_WAIT: 56688392

1 row in set (0.00 sec)

OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE,OBJECT_INSTANCE_BEGIN:那几个列标识了一个正在被实践的靶子,所以那一个列记录的信息意义要求看对象是何等类型,下边根据不相同目的类型分别对那几个列的意思举行求证:

 

COUNT_READ: 1

# events_waits_summary_by_instance表

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

执行sp_dropextendedproperty删除现有扩大属性。

SUM _TIMER_READ: 56688392

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

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

EXEC sp_dropextendedproperty 
@name = N'MS_Description',
@level0type = N'SCHEMA', @level0name = N'dbo',
@level1type = N'TABLE', @level1name = N'T8',
@level2type = N'COLUMN', @level2name = N'name'
GO

MIN _TIMER_READ: 56688392

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

*
2)、OBJECT_INSTANCE_BEGIN列是内存中同步对象的地方。OBJECT_INSTANCE_BEGIN除了差其余值标记差其他靶子之外,其值本身并未意思。但OBJECT_INSTANCE_BEGIN值可用以调试。例如,它能够与GROUP BY
OBJECT_INSTANCE_BEGIN子句一起利用来查看1,000个互斥体(例如:尊敬1,000个页或数据块)上的载荷是或不是是均匀分布仍旧爆发了一部分瓶颈。假如在日记文件或任何调试、质量工具中来看与该语句查看的结果中有雷同的对象地址,那么,在你分析质量难题时,可以把那么些语句查看到的音信与其余工具查看到的音信涉及起来。

code-5

AVG _TIMER_READ: 56688392

EVENT_NAME: wait/synch/mutex/mysys/THR_LOCK_heap

* 对于文本I/O对象:

 

MAX _TIMER_READ: 56688392

OBJECT _INSTANCE_BEGIN: 32492032

*
1)、OBJECT_SCHEMA列值为NULL

再查询sys.extended_properties,字段name的增加属性已经被剔除。

……

COUNT_STAR: 0

* 2)、OBJECT_NAME列是文本名

ca88国际娱乐城 11

1 row in set (0.00 sec)

SUM _TIMER_WAIT: 0

* 3)、OBJECT_TYPE列为FILE

 figure-8

# table_io_waits_summary_by_table表

MIN _TIMER_WAIT: 0

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

 

admin@localhost : performance _schema 01:56:16> select * from
table_io _waits_summary _by_table where SUM _TIMER_WAIT!=0G;

AVG _TIMER_WAIT: 0

* 对于套接字对象:

使用sp_updateextendedproperty更新扩充属性。

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

MAX _TIMER_WAIT: 0

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

EXEC sp_updateextendedproperty 
@name = N'MS_Description',
@value = N'This is a column description on [id](3).',
@level0type = N'SCHEMA', @level0name = N'dbo',
@level1type = N'TABLE', @level1name = N'T8',
@level2type = N'COLUMN', @level2name = N'id'
GO

OBJECT_TYPE: TABLE

1 row in set (0.00 sec)

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

code-6

OBJECT_SCHEMA: xiaoboluo

# events_waits_summary_by_thread_by_event_name表

* 对于表I/O对象:

 

OBJECT_NAME: test

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

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

ca88国际娱乐城 12

COUNT_STAR: 1

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

* 2)、OBJECT_NAME列是表名

figure-9

…………

THREAD_ID: 1

*
3)、OBJECT_TYPE列值对于基表或者TEMPORARY
TABLE临时表,该值是table,注意:对于在join查询中select_type为DERIVED,subquery等的表可能不记录事件音信也不开展总括

 

1 row in set (0.00 sec)

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

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

不仅仅表可以增加增添属性,其余数据库对象也得以,如数据库,索引等。

# table_lock_waits_summary_by_table表

COUNT_STAR: 0

INDEX_NAME:表示使用的目录的称呼。PRIMARY表示使用到了主键。 NULL代表从没采用索引

USE AdventureWorks2008R2;
GO

SELECT *,OBJECT_NAME(major_id) AS obj_name FROM sys.extended_properties
GO

admin@localhost : performance _schema 01:57:20> select * from
table_lock _waits_summary _by_table where SUM _TIMER_WAIT!=0G;

SUM _TIMER_WAIT: 0

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

code-7

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

MIN _TIMER_WAIT: 0

NESTING_EVENT_TYPE:表示该行新闻中的EVENT_ID事件嵌套的轩然大波类型。有效值有:TRANSACTION,STATEMENT,STAGE或WAIT,即父事件的事件类型,如果为TRANSACTION则须要到业务事件表中找对应NESTING_EVENT_ID值的风浪,其余种类同理

 

OBJECT_TYPE: TABLE

AVG _TIMER_WAIT: 0

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

ca88国际娱乐城 13

OBJECT_SCHEMA: xiaoboluo

MAX _TIMER_WAIT: 0

NUMBER_OF_BYTES:操作读取或写入的字节数或行数。对于文本IO等待,该列值表示字节数;对于表I/O等待(wait/io/table/sql/handler
instruments的风浪),该列值表示行数。如若值大于1,则象征该事件对应一个批量I/O操作。以下分别对单个表IO和批量表IO的界别展开描述:

figure-10

OBJECT_NAME: test

1 row in set (0.00 sec)

  • 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语句的施行时间)

 

…………

# events_waits_summary_by_user_by_event_name表

FLAGS:留作未来使用

ca88国际娱乐城 14

COUNT_READ_NORMAL: 0

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

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

figure-11

SUM_TIMER_READ_NORMAL: 0

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

events_waits_history 表

 

MIN_TIMER_READ_NORMAL: 0

USER: NULL

events_waits_history表包含每个线程目前的N个等待事件。
在server启动时,N的值会自动调整。
如若要显式设置这一个N大小,可以在server启动此前调整系统参数performance_schema_events_waits_history_size的值。
等待事件须要举办达成时才被添加到events_waits_history表中(没有达成时保留在events_waits_current表)。当添加新事件到events_waits_history表时,如若该表已满,则会抛弃每个线程较旧的事件

 

AVG_TIMER_READ_NORMAL: 0

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

events_waits_history与events_waits_current表定义相同

参考文档:

MAX_TIMER_READ_NORMAL: 0

COUNT_STAR: 0

PS:允许实施TRUNCATE TABLE语句

对数据库对象使用扩张属性:

COUNT _READ_WITH _SHARED_LOCKS: 0

SUM _TIMER_WAIT: 0

events_waits_history_long 表

SUM _TIMER_READ _WITH_SHARED_LOCKS: 0

MIN _TIMER_WAIT: 0

events_waits_history_long表包涵近来的N个等待事件(所有线程的风云)。在server启动时,N的值会自动调整。
若是要显式设置这些N大小,可以在server启动以前调整系统参数

翻开增添属性:

MIN _TIMER_READ _WITH_SHARED_LOCKS: 0

AVG _TIMER_WAIT: 0

performance_schema_events_waits_history_long_size的值。等待事件须要实践完成时才会被添加到events_waits_history_long表中(没有终止时保留在events_waits_current表),当添加新事件到events_waits_history_long表时,假如该表已满,则会扬弃该表中较旧的事件。

AVG _TIMER_READ _WITH_SHARED_LOCKS: 0

MAX _TIMER_WAIT: 0

events_waits_history_long与events_waits_current表结构同样

sys.extended_properties:

MAX _TIMER_READ _WITH_SHARED_LOCKS: 0

1 row in set (0.00 sec)

PS:允许使用TRUNCATE TABLE语句

……

# events_waits_summary_global_by_event_name表

等级事件表

sp_addextendedproperty:

1 row in set (0.00 sec)

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

等级事件记录表与等待事件记录表一样,也有三张表,那一个表记录了脚下与近日在MySQL实例中生出了什么阶段事件,时间费用是稍微。阶段指的是语句执行进度中的步骤,例如:parsing
、opening tables、filesort操作等。

从上边表中的记录新闻大家得以看出,table_io_waits_summary_by_index_usage表和table_io_waits_summary_by_table有着类似的统计列,但table_io_waits_summary_by_table表是带有全部表的增删改查等待事件分类总括,table_io_waits_summary_by_index_usage区分了各样表的目录的增删改查等待事件分类统计,而table_lock_waits_summary_by_table表计算纬度类似,但它是用以总计增删改核对应的锁等待时间,而不是IO等待时间,那一个表的分组和统计列含义请大家自行举一反三,那里不再赘言,下边针对那三张表做一些少不了的辨证:

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

在过去大家查阅语句执行的等级状态,日常使用SHOW
PROCESSLIST语句或询问INFORMATION_SCHEMA.PROCESSLIST表来博取,但processlist形式可以查询到的信息相比较有限且时而即逝,大家寻常须要整合profiling作用来一发总结分析语句执行的次第阶段的用度等,现在,大家不必要如此劳顿,直接动用performance_schema的等级事件就既可以查询到持有的讲话执行阶段,也足以查询到种种阶段对应的支付,因为是记录在表中,所以更可以选用SQL语句对这么些数据举办排序、统计等操作

sp_dropextendedproperty:

table_io_waits_summary_by_table表:

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

要注意:阶段事件有关安排中,setup_instruments表中stage/开端的绝一大半instruments配置默许没有打开(少数stage/开始的instruments除外,如DDL语句执行进度的stage/innodb/alter*初步的instruments默许开启的),setup_consumers表中stages相关的consumers配置默许没有拉开

该表允许选用TRUNCATE
TABLE语句。只将计算列重置为零,而不是剔除行。对该表执行truncate还会隐式truncate
table_io_waits_summary_by_index_usage表

COUNT_STAR: 0

events_stages_current 表

sp_updateextendedproperty:

table_io_waits_summary_by_index_usage表:

SUM _TIMER_WAIT: 0

events_stages_current表包罗当前阶段事件的监察音讯,每个线程一行记录突显线程正在实施的stage事件的事态

按照与table_io_waits_summary_by_table的分组列+INDEX_NAME列进行分组,INDEX_NAME有如下三种:

MIN _TIMER_WAIT: 0

在富含stage事件记录的表中,events_stages_current是基准表,包蕴stage事件记录的其余表(如:events_stages_history和events_stages_history_long表)的数目在逻辑上都源于events_stages_current表(汇总表除外)

fn_listextendedproperty:

·假使利用到了目录,则那里显示索引的名字,如果为PRIMARY,则表示表I/O使用到了主键索引

AVG _TIMER_WAIT: 0

表记录内容示例(以下如故是一个履行select
sleep(100);语句的线程,但那边是阶段事件音讯)

·比方值为NULL,则意味着表I/O没有使用到目录

MAX _TIMER_WAIT: 0

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

 

·一经是插入操作,则无从选拔到目录,此时的计算值是坚守INDEX_NAME =
NULL计算的

1 row in set (0.00 sec)

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

该表允许行使TRUNCATE
TABLE语句。只将总括列重置为零,而不是剔除行。该表执行truncate时也会隐式触发table_io_waits_summary_by_table表的truncate操作。此外利用DDL语句更改索引结构时,会导致该表的保有索引计算音信被重置

从下面表中的示范记录信息中,大家得以看看:

THREAD_ID: 46

table_lock_waits_summary_by_table表:

每个表都有分其余一个或七个分组列,以确定什么聚合事件音信(所有表都有EVENT_NAME列,列值与setup_instruments表中NAME列值对应),如下:

EVENT_ID: 280

该表的分组列与table_io_waits_summary_by_table表相同

events_waits_summary_by_account_by_event_name表:按照列EVENT_NAME、USER、HOST举行分组事件音信

END _EVENT_ID: NULL

该表包罗关于内部和表面锁的音讯:

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

EVENT_NAME: stage/sql/User sleep

·中间锁对应SQL层中的锁。是由此调用thr_lock()函数来落到实处的。(官方手册上说有一个OPERATION列来差异锁类型,该列有效值为:read
normal、read with shared locks、read high priority、read no
insert、write allow write、write concurrent insert、write delayed、write
low priority、write normal。但在该表的定义上并不曾见到该字段)

events_waits_summary_by_instance表:按照列EVENT_NAME、OBJECT_INSTANCE_BEGIN举行分组事件音讯。即使一个instruments(event_name)创立有三个实例,则每个实例都抱有唯一的OBJECT_INSTANCE_BEGIN值,因而各类实例会举办单独分组

SOURCE: item_func.cc:6056

·表面锁对应存储引擎层中的锁。通过调用handler::external_lock()函数来落到实处。(官方手册上说有一个OPERATION列来区分锁类型,该列有效值为:read
external、write external。但在该表的概念上并不曾观看该字段)

events_waits_summary_by_thread_by_event_name表:按照列THREAD_ID、EVENT_NAME进行分组事件音信

TIMER_START: 14645080545642000

该表允许利用TRUNCATE TABLE语句。只将计算列重置为零,而不是删除行。

events_waits_summary_by_user_by_event_name表:按照列EVENT_NAME、USER进行分组事件音讯

TIMER_END: 14698320697396000

3.文书I/O事件计算

events_waits_summary_global_by_event_name表:按照EVENT_NAME列举行分组事件音信

TIMER_WAIT: 53240151754000

文本I/O事件计算表只记录等待事件中的IO事件(不包罗table和socket子序列),文件I/O事件instruments默许开启,在setup_consumers表中无实际的照应配置。它涵盖如下两张表:

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

WORK_COMPLETED: NULL

admin@localhost : performance_schema 06:48:12> show tables like
‘%file_summary%’;

COUNT_STAR:事件被实践的多少。此值蕴含持有事件的实施次数,必要启用等待事件的instruments

WORK_ESTIMATED: NULL

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

SUM_TIMER_WAIT:总括给定计时事件的总等待时间。此值仅针对有计时效劳的事件instruments或开启了计时作用事件的instruments,即使某事件的instruments不协助计时要么尚未开启计时效用,则该字段为NULL。其余xxx_TIMER_WAIT字段值类似

NESTING _EVENT_ID: 266

| Tables_in_performance_schema (%file_summary%) |

MIN_TIMER_WAIT:给定计时事件的矮小等待时间

NESTING _EVENT_TYPE: STATEMENT

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

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

1 row in set (0.00 sec)

| file_summary_by_event_name |

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

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

| file_summary_by_instance |

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

THREAD_ID,EVENT_ID:与事件波及的线程ID和近日风云ID,可以运用THREAD_ID和EVENT_ID列值来唯一标识该行,这两行的值作为整合条件时不会产出相同的数据行

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

实践该语句时有如下行为:

END_EVENT_ID:当一个轩然大波先河执行时,对应行记录的该列值被设置为NULL,当一个事件实施完成时,对应的行记录的该列值被更新为该事件的ID

2rows inset ( 0. 00sec)

对此未根据帐户、主机、用户聚集的统计表,truncate语句会将计算列值重置为零,而不是删除行。

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语句会删除已初阶连接的帐户,主机或用户对应的行,并将别的有连接的行的统计列值重置为零(实测跟未依据帐号、主机、用户聚集的总括表一样,只会被重置不会被去除)。

·file_summary_by_event_name:依据每个事件名称进行计算的文本IO等待事件

除此以外,依照帐户、主机、用户、线程聚合的每个等待事件统计表或者events_waits_summary_global_by_event_name表,即使借助的连接表(accounts、hosts、users表)执行truncate时,那么着重的那么些表中的总结数据也会同时被隐式truncate

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

·file_summary_by_instance:按照每个文件实例(对应现实的每个磁盘文件,例如:表sbtest1的表空间文件sbtest1.ibd)进行计算的文件IO等待事件

注意:那么些表只针对等候事件音信进行计算,即含有setup_instruments表中的wait/%初叶的搜集器+
idle空闲采集器,每个等待事件在每个表中的计算记录行数须求看怎么着分组(例如:依据用户分组总结的表中,有多少个活泼用户,表中就会有稍许条相同采集器的记录),此外,计预计数器是或不是见效还索要看setup_instruments表中相应的等候事件采集器是或不是启用。

TIMER_START,TIMER_END,TIMER_WAIT:事件的时日音信。那个值的单位是飞秒(万亿分之一秒)。TIMER_START和TIMER_END值表示事件的启幕时间和得了时间。TIMER_WAIT是事件实施消耗的年月(持续时间)

大家先来探望表中记录的统计信息是什么体统的。

| 阶段事件总计表

  • 假使事件未举行到位,则TIMER_END为当下岁月,TIMER_WAIT为眼前终止所经过的年月(TIMER_END –
    TIMER_START)
  • 如果instruments配置表setup_instruments中对应的instruments
    的TIMED字段被设置为
    NO,则该instruments禁用时间采访功能,那么事件采访的新闻记录中,TIMER_START,TIMER_END和TIMER_WAIT字段值均为NULL

# file_summary_by_event_name表

performance_schema把阶段事件总计表也如约与等待事件总结表类似的规则实行分拣聚合,阶段事件也有一对是默许禁用的,一部分是翻开的,阶段事件计算表包涵如下几张表:

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

admin@localhost : performance _schema 11:00:44> select * from
file_summary _by_event _name where SUM_TIMER _WAIT !=0 and
EVENT_NAME like ‘%innodb%’ limit 1G;

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

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

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

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

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

EVENT_NAME: wait/io/file/innodb/innodb_data_file

| Tables_in_performance_schema (%events_stages_summary%) |

*
2)、WORK_ESTIMATED:显示推测阶段事件将要落成的行事单元数

COUNT_STAR: 802

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

  • 即使instruments没有提供进程相关的成效,则该instruments执行事件采访时就不会有速度新闻呈现,WORK_COMPLETED和WORK_ESTIMATED列都会来得为NULL。如若进程音信可用,则进程音信如何显示取决于instruments的推行处境。performance_schema表提供了一个仓储过程数据的容器,但不会假使你会定义何种度量单位来使用这个进程数据:

SUM_TIMER_WAIT: 412754363625

| events_stages_summary_by_account_by_event_name |

*
1)、“工作单元”是在履行进度中随时间增添而充实的平头度量,例如执行进度中的字节数、行数、文件数或表数。对于特定instruments的“工作单元”的概念留给提供数据的instruments代码

MIN_TIMER_WAIT: 0

| events_stages_summary_by_host_by_event_name |

*
2)、WORK_COMPLETED值根据检测的代码分歧,可以一回扩大一个或三个单元

AVG_TIMER_WAIT: 514656000

| events_stages_summary_by_thread_by_event_name |

*
3)、WORK_ESTIMATED值依照检测代码,可能在等级事件实施进程中发生变化

MAX_TIMER_WAIT: 9498247500

| events_stages_summary_by_user_by_event_name |

  • 等级事件进程提示器的突显作为有以下三种状态:

COUNT_READ: 577

| events_stages_summary_global_by_event_name |

*
1)、instruments不扶助进程:没有可用进度数据,
WORK_COMPLETED和WORK_ESTIMATED列都突显为NULL

SUM_TIMER_READ: 305970952875

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

* 2)
、instruments帮助进程但相应的工作负荷总工作量不可预估(无限进度):只有WORK_COMPLETED列有含义(因为她突显正在实施的进程显示),WORK_ESTIMATED列此时不行,突显为0,因为从没可预估的总进程数据。通过查询events_stages_current表来监视会话,监控应用程序到近日为止执行了稍稍工作,但无能为力告知对应的做事是还是不是接近成功

MIN_TIMER_READ: 15213375

5rows inset ( 0. 00sec)

*
3)、instruments接济进程,总工作量可预估(有限进程):WORK_COMPLETED和WORK_ESTIMATED列值有效。那连串型的进程显示可用于online
DDL时期的copy表阶段监视。通过查询events_stages_current表,可监控应用程序当前已经达成了稍稍办事,并且能够由此WORK_COMPLETED
/ WORK_ESTIMATED统计的比值来预估某个阶段总体已毕比例

AVG_TIMER_READ: 530278875

大家先来探望那一个表中著录的计算音信是怎么体统的。

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

MAX_TIMER_READ: 9498247500

# events_stages_summary_by_account_by_event_name表

NESTING_EVENT_TYPE:嵌套事件类型。有效值为:TRANSACTION,STATEMENT,STAGE,WAIT。阶段事件的嵌套事件司空眼惯是statement

SUM _NUMBER_OF _BYTES_READ: 11567104

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

对于events_stages_current表允许利用TRUNCATE
TABLE语句来进展清理

……

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

PS:stage事件拥有一个进程浮现效果,我们能够使用该进程浮现效果来打探一些长日子实施的SQL的速度百分比,例如:对于必要利用COPY格局实施的online
ddl,那么必要copy的数据量是必定的,可以显然的,so..那就足以为”stage/sql/copy
to tmp table stage”
instruments提供一个有收尾边界参照的快慢数据音讯,这几个instruments所选取的干活单元就是内需复制的数码行数,此时WORK_COMPLETED和WORK_ESTIMATED列值都是立见功能的可用的,两者的总计比例就象征方今copy表达成copy的行数据百分比。

1 row in set (0.00 sec)

USER: root

  • 要查看copy表阶段事件的正在执行的快慢监视功效,要求开拓相关的instruments和consumers,然后查看events_stages_current表,如下:

# file_summary_by_instance表

HOST: localhost

# 配置相关instruments和consumers

admin@localhost : performance _schema 11:01:23> select * from
file_summary _by_instance where SUM _TIMER_WAIT!=0 and EVENT_NAME
like ‘%innodb%’ limit 1G;

EVENT_NAME: stage/sql/After create

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

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

COUNT_STAR: 0

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

FILE_NAME: /data/mysqldata1/innodb_ts/ibdata1

SUM _TIMER_WAIT: 0

# 然后在执行ALTER TABLE语句期间,查看events_stages_current表

EVENT_NAME: wait/io/file/innodb/innodb_data_file

MIN _TIMER_WAIT: 0

events_stages_history 表

OBJECT _INSTANCE_BEGIN: 139882156936704

AVG _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表结构同样

COUNT_STAR: 33

MAX _TIMER_WAIT: 0

PS:允许使用TRUNCATE TABLE语句

…………

1 row in set (0.01 sec)

events_stages_history_long 表

1 row in set (0.00 sec)

# events_stages_summary_by_host_by_event_name表

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表结构同样

从地点表中的笔录音讯大家可以看到:

root@localhost : performance _schema 11:29:27> select * from
events_stages _summary_by _host_by _event_name where HOST is not
null limit 1G

PS:允许使用TRUNCATE TABLE语句

·每个文件I/O总结表都有一个或多个分组列,以标明怎样计算那些事件音讯。那几个表中的事件名称来自setup_instruments表中的name字段:

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

话语事件表

* file_summary_by_event_name表:按照EVENT_NAME列举办分组 ;

HOST: localhost

话语事件记录表与等待事件记录表一样,也有三张表,那个表记录了如今与近期在MySQL实例中生出了什么样语句事件,时间用度是有点。记录了四种多样的言语执行暴发的言辞事件信息。

*
file_summary_by_instance表:有非凡的FILE_NAME、OBJECT_INSTANCE_BEGIN列,按照FILE_NAME、EVENT_NAME列进行分组,与file_summary_by_event_name
表相比,file_summary_by_instance表多了FILE_NAME和OBJECT_INSTANCE_BEGIN字段,用于记录具体的磁盘文件有关信息。

EVENT_NAME: stage/sql/After create

要留心:语句事件有关配置中,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。

·每个文件I/O事件计算表有如下计算字段:

COUNT_STAR: 0

events_statements_current 表

*
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT:那么些列统计所有I/O操作数量和操作时间

SUM _TIMER_WAIT: 0

events_statements_current表包蕴当前讲话事件,每个线程只呈现一行近期被监视语句事件的此时此刻事态。

*
COUNT_READ,SUM_TIMER_READ,MIN_TIMER_READ,AVG_TIMER_READ,MAX_TIMER_READ,SUM_NUMBER_OF_BYTES_READ:这么些列总结了独具文件读取操作,包含FGETS,FGETC,FREAD和READ系统调用,还包含了那么些I/O操作的多少字节数

MIN _TIMER_WAIT: 0

在含蓄语句事件行的表中,events_statements_current当前事变表是基础表。其他包涵语句事件表中的多少在逻辑上源于当前事件表(汇总表除外)。例如:events_statements_history和events_statements_history_long表是近来的言辞事件历史的联谊,events_statements_history表中每个线程默许保留10行事件历史新闻,events_statements_history_long表中默认所无线程保留10000行事件历史音信

*
COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_WRITE:那么些列计算了颇具文件写操作,包含FPUTS,FPUTC,FPRINTF,VFPRINTF,FWRITE和PWRITE系统调用,还包蕴了那几个I/O操作的多寡字节数

AVG _TIMER_WAIT: 0

表记录内容示例(以下信息仍然来自select
sleep(100);语句的说话事件新闻)

*
COUNT_MISC,SUM_TIMER_MISC,MIN_TIMER_MISC,AVG_TIMER_MISC,MAX_TIMER_MISC:这一个列总括了拥有其余文件I/O操作,包括CREATE,DELETE,OPEN,CLOSE,STREAM_OPEN,STREAM_CLOSE,SEEK,TELL,FLUSH,STAT,FSTAT,CHSIZE,RENAME和SYNC系统调用。注意:这个文件I/O操作没有字节计数新闻。

MAX _TIMER_WAIT: 0

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

文件I/O事件计算表允许行使TRUNCATE
TABLE语句。但只将计算列重置为零,而不是剔除行。

1 row in set (0.00 sec)

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

PS:MySQL
server使用两种缓存技术通过缓存从文件中读取的信息来制止文件I/O操作。当然,即便内存不够时要么内存竞争相比大时可能造成查询功效低下,那么些时候你可能须要通过刷新缓存或者重启server来让其数额经过文件I/O再次来到而不是经过缓存返回。

# events_stages_summary_by_thread_by_event_name表

THREAD_ID: 46

4.套接字事件计算

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

EVENT_ID: 334

套接字事件总计了套接字的读写调用次数和发送接收字节计数音信,socket事件instruments默许关闭,在setup_consumers表中无实际的照应配置,包蕴如下两张表:

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

END_EVENT_ID: NULL

·socket_summary_by_instance:针对种种socket实例的具备 socket
I/O操作,那一个socket操作相关的操作次数、时间和殡葬接收字节信息由wait/io/socket/*
instruments爆发。但当连接中断时,在该表中对应socket连接的新闻就要被剔除(这里的socket是指的当前活跃的连年创造的socket实例)

THREAD_ID: 1

EVENT_NAME: statement/sql/select

·socket_summary_by_event_name:针对各样socket I/O
instruments,这几个socket操作相关的操作次数、时间和发送接收字节新闻由wait/io/socket/*
instruments爆发(那里的socket是指的脚下活蹦乱跳的总是创制的socket实例)

EVENT_NAME: stage/sql/After create

SOURCE: socket_connection.cc: 101

网站地图xml地图