365体育备用事件统计,数据库对象事件与属性统计

|admin | localhost |1| 1 |

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

MySQL Performance-Schema(二) 理论篇,performanceschema

     MySQL
Performance-Schema中累计包罗五13个表,主要分为几类:Setup表,Instance表,Wait
Event表,Stage 伊夫nt表Statement
伊芙nt表,Connection表和Summary表。上1篇文章已经首要讲了Setup表,那篇小说将会独家就各类档次的表做详细的叙述。

Instance表
   
 instance中关键含有了5张表:cond_instances,file_instances,mutex_instances,rwlock_instances和socket_instances。
(1)cond_instances:条件等待对象实例
表中著录了系统中应用的标准变量的目的,OBJECT_INSTANCE_BEGIN为对象的内部存款和储蓄器地址。比如线程池的timer_cond实例的name为:wait/synch/cond/threadpool/timer_cond

(2)file_instances:文件实例
表中著录了系统中开辟了文件的指标,包括ibdata文件,redo文件,binlog文件,用户的表文件等,比如redo日志文件:/u01/my3306/data/ib_logfile0。open_count显示当前文件打开的数量,假设重来未有打开过,不会现出在表中。

(3)mutex_instances:互斥同步对象实例
表中记录了系统中动用互斥量对象的具备记录,在那之中name为:wait/synch/mutex/*。比如打开文件的互斥量:wait/synch/mutex/mysys/TH卡宴_LOCK_open。LOCKED_BY_THREAD_ID呈现哪个线程正持有mutex,若没有线程持有,则为NULL。

(4)rwlock_instances: 读写锁同步对象实例
表中记录了系统中利用读写锁对象的持有记录,其中name为
wait/synch/rwlock/*。WRITE_LOCKED_BY_THREAD_ID为正在有着该对象的thread_id,若没有线程持有,则为NULL,READ_LOCKED_BY_COUNT为记录了并且有稍许个读者持有读锁。通过
events_waits_current
表可以领略,哪个线程在伺机锁;通过rwlock_instances知道哪位线程持有锁。rwlock_instances的缺点是,只可以记录持有写锁的线程,对于读锁则无从。

(5)socket_instances:活跃会话对象实例
表中著录了thread_id,socket_id,ip和port,其余表能够经过thread_id与socket_instance实行关联,获取IP-PO帕杰罗T音信,能够与使用接入起来。
event_name主要涵盖三类:
wait/io/socket/sql/server_unix_socket,服务端unix监听socket
wait/io/socket/sql/server_tcpip_socket,服务端tcp监听socket
wait/io/socket/sql/client_connection,客户端socket

Wait Event表
     
Wait表首要含有贰个表,events_waits_current,events_waits_history和events_waits_history_long,通过thread_id+event_id能够唯1鲜明一条记下。current表记录了当前线程等待的轩然大波,history表记录了各个线程近来守候的十三个事件,而history_long表则记录了多年来具有线程产生的壹仟0个事件,这里的拾和一千0都是足以布置的。那三个表表结构同样,history和history_long表数据都来源于current表。current表和history表中只怕会有再一次事件,并且history表中的事件都是成就了的,未有完成的风浪不会进入到history表中。
THREAD_ID:线程ID
EVENT_ID:当前线程的风云ID,和THREAD_ID组成二个Primary Key。
END_EVENT_ID:当事件开首时,那1列棉被服装置为NULL。当事件甘休时,再创新为近期的轩然大波ID。
SOUPRADOCE:该事件时有产生时的源码文件
TIMER_START, TIMER_END,
TIMER_WAIT:事件始于/结束和等候的时光,单位为微秒(picoseconds)

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE视境况而定
对此联合对象(cond, mutex, rwlock),这么些1个值均为NULL
对此文本IO对象,OBJECT_SCHEMA为NULL,OBJECT_NAME为文件名,OBJECT_TYPE为FILE
对于SOCKET对象,OBJECT_NAME为该socket的IP:SOCK值
对于表I/O对象,OBJECT_SCHEMA是表的SCHEMA名,OBJECT_NAME是表名,OBJECT_TYPE为TABLE或者TEMPORARY
TABLE
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT, STAGE, WAIT)
OPERATION:操作类型(lock, read, write)

Stage Event表 

     
 Stage表重要涵盖一个表,events_stages_current,events_stages_history和events_stages_history_long,通过thread_id+event_id能够唯1显著一条记下。表中记录了脚下线程所处的推行阶段,由于能够知道各种阶段的履行时间,由此通过stage表能够博得SQL在每种阶段消耗的时刻。

THREAD_ID:线程ID
EVENT_ID:事件ID
END_EVENT_ID:刚截至的轩然大波ID
SOU帕杰罗CE:源码地点
TIMER_START, TIMER_END,
TIMER_WAIT:事件开首/甘休和等候的岁月,单位为纳秒(picoseconds)
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT, STAGE, WAIT)

Statement Event表
     
Statement表主要包括一个表,events_statements_current,events_statements_history和events_statements_history_long。通过thread_id+event_id可以唯一鲜明一条记下。Statments表只记录最顶层的恳求,SQL语句或是COMMAND,每条语句1行,对于嵌套的子查询或许存款和储蓄进程不会独自列出。event_name形式为statement/sql/*,或statement/com/*
SQL_TEXT:记录SQL语句
DIGEST:对SQL_TEXT做MD伍发生的33人字符串。倘使为consumer表中绝非打开statement_digest选项,则为NULL。
DIGEST_TEXT:将讲话中值部分用问号代替,用于SQL语句归类。倘使为consumer表中一向不打开statement_digest选项,则为NULL。
CURRENT_SCHEMA:暗许的数目库名
OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE:保留字段,全部为NULL
ROWS_AFFECTED:影响的多寡
ROWS_SENT:重返的记录数
ROWS_EXAMINED:读取的笔录数据
CREATED_TMP_DISK_TABLES:创造物理临时表数目
CREATED_TMP_TABLES:成立一时半刻表数目
SELECT_FULL_JOIN:join时,第一个表为全表扫描的数码
SELECT_FULL_RANGE_JOIN:join时,引用表选用range格局扫描的多少
SELECT_RANGE:join时,第5个表采取range形式扫描的数目
SELECT_SCAN:join时,第1个表位全表扫描的多少
SORT_ROWS:排序的笔录数据
NESTING_EVENT_ID,NESTING_EVENT_TYPE,保留字段,为NULL。

Connection表
   
 Connection表记录了客户端的音讯,首要包蕴三张表:users,hosts和account表,accounts包蕴hosts和users的音信。
USER:用户名
HOST:用户的IP

Summary表
   
Summary表聚集了逐条维度的总计新闻包蕴表维度,索引维度,会话维度,语句维度和锁维度的总计音讯。
(1).wait-summary表
events_waits_summary_global_by_event_name
现象:按等待事件类型聚合,每一个事件一条记下。
events_waits_summary_by_instance
地方:按等待事件目的聚合,同一种等待事件,只怕有四个实例,每种实例有两样的内部存款和储蓄器地址,由此
event_name+object_instance_begin唯1显著一条记下。
events_waits_summary_by_thread_by_event_name
此情此景:按每一种线程和事件来总括,thread_id+event_name唯一分明一条记下。
COUNT_STA宝马X5:事件计数
SUM_TIMER_WAIT:总的等待时间
MIN_TIMER_WAIT:最小等待时间
MAX_TIMER_WAIT:最大等待时间
AVG_TIMER_WAIT:平均等待时间

(2).stage-summary表
events_stages_summary_by_thread_by_event_name
events_stages_summary_global_by_event_name
与前方类似

(3).statements-summary表
events_statements_summary_by_thread_by_event_name表和events_statements_summary_global_by_event_name表与近年来类似。对于events_statements_summary_by_digest表,
FIRST_SEEN_TIMESTAMP:第二个语句执行的时光
LAST_SEEN_TIMESTAMP:最终八个话语执行的大运
情景:用于总计某一段时间内top SQL

(4).file I/O summary表
file_summary_by_event_name [按事件类型总括]
file_summary_by_instance [按实际文件总结]
场景:物理IO维度
FILE_NAME:具体文件名,比如:/u01/my3306/data/tcbuyer_0168/tc_biz_order_2695.ibd
EVENT_NAME:事件名,比如:wait/io/file/innodb/innodb_data_file
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT
统计IO操作
COUNT_READ,SUM_TIMER_READ,MIN_TIMER_READ,AVG_TIMER_READ,MAX_TIMER_READ,
SUM_NUMBER_OF_BYTES_READ
统计读
COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,
SUM_NUMBER_OF_BYTES_WRITE
统计写
COUNT_MISC,SUM_TIMER_MISC,MIN_TIMER_MISC,AVG_TIMER_MISC,MAX_TIMER_MISC
总计其他IO事件,比如create,delete,open,close等

(5).Table I/O and Lock Wait Summaries-表
table_io_waits_summary_by_table
遵照wait/io/table/sql/handler,聚合各样表的I/O操作,[逻辑IO]
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT
统计IO操作
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT
统计读
COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,
MAX_TIMER_WRITE
统计写
COUNT_FETCH,SUM_TIMER_FETCH,MIN_TIMER_FETCH,AVG_TIMER_FETCH,
MAX_TIMER_FETCH
与读相同
COUNT_INSERT,SUM_TIMER_INSERT,MIN_TIMER_INSERT,AVG_TIMER_INSERT,MAX_TIMER_INSERT
INSE翼虎T总计,相应的还有DELETE和UPDATE总计。

(6).table_io_waits_summary_by_index_usage
与table_io_waits_summary_by_table类似,按索引维度计算

(7).table_lock_waits_summary_by_table
汇集了表锁等待事件,包含internal lock 和 external lock。
internal lock通过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

external lock则经过接口函数handler::external_lock调用存款和储蓄引擎层,
OPERATION列的值为:
read external
write external

(8).Connection Summaries表
events_waits_summary_by_account_by_event_name
events_waits_summary_by_user_by_event_name
events_waits_summary_by_host_by_event_name
events_stages_summary_by_account_by_event_name
events_stages_summary_by_user_by_event_name
events_stages_summary_by_host_by_event_name
events_statements_summary_by_account_by_event_name
events_statements_summary_by_user_by_event_name
events_statements_summary_by_host_by_event_name

(9).socket-summaries表
socket_summary_by_instance
socket_summary_by_event_name

其它表
performance_timers: 系统辅助的总结时间单位
threads: 监视服务端的日前运营的线程

Performance-Schema(2)
理论篇,performanceschema MySQL
Performance-Schema中总共包涵52个表,重要分为几类:Setup表,Instance表,Wait
伊芙nt表,Stage Ev…

4 rows in set (0.00 sec)

SUM _CREATED_TMP_TABLES: 10

·OBJECT_SCHEMA:该锁来自于哪个库级别的靶子;

SUM _TIMER_WAIT: 0

·OBJECT_INSTANCE_BEGIN:读写锁实例的内部存款和储蓄器地址;

performance_schema把等待事件总结表遵照分化的分组列(不相同纬度)对等候事件有关的数码开始展览联谊(聚合计算数据列包含:事件时有爆发次数,总等待时间,最小、最大、平均等待时间),注意:等待事件的采访效率有部分默认是禁止使用的,须求的时候能够透过setup_instruments和setup_objects表动态开启,等待事件总结表包括如下几张表:

·USELacrosse:某连续的客户端用户名。假设是二个内部线程创立的连天,或然是无能为力求证的用户成立的连日,则该字段为NULL;

1 row in set (0.00 sec)

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

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

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

*
LOW_COUNT_USED,HIGH_COUNT_USED:对应CURRENT_COUNT_USED列的低和高水位标记

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

THREAD_ID: 47

(1)metadata_locks表

*
以前缀memory/performance_schema命名的instruments能够搜集performance_schema自己消耗的在那之中缓存区大小等音信。memory/performance_schema/*
instruments默许启用,不恐怕在运行时或运营时关闭。performance_schema自己相关的内部存储器总计新闻只保存在memory_summary_global_by_event_name表中,不会保存在依据帐户,主机,用户或线程分类聚合的内部存款和储蓄器总括表中

truncate
*_summary_global总括表也会隐式地truncate其对应的连接和线程总结表中的新闻。例如:truncate
events_waits_summary_global_by_event_name会隐式地truncate依照帐户,主机,用户或线程总计的等候事件计算表。

1 row in set (0.01 sec)

咱们先来看望表中著录的总计消息是如何样子的。

MIN _TIMER_WAIT: 0

* _thread:客户端线程ID(仅适用于Windows)

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

COUNT_EXECUTE: 0

SUM_xxx:针对events_statements_*事件记录表中相应的xxx列进行总括。例如:语句总结表中的SUM_LOCK_TIME和SUM_ERRORS列对events_statements_current事件记录表中LOCK_TIME和EPRADORO卡宴S列进行计算

1row inset ( 0. 00sec)

events_waits_summary_by_user_by_event_name表:按照列EVENT_NAME、USE福特Explorer进行分组事件消息

rwlock_instances表列出了server执行rwlock
instruments时performance_schema所见的兼具rwlock(读写锁)实例。rwlock是在代码中使用的联名机制,用于强制在给定时间内线程能够依照有个别规则访问一些公共财富。能够认为rwlock尊敬着这几个能源不被别的线程随意抢占。访问格局能够是共享的(多少个线程能够而且具有共享读锁)、排他的(同时唯有三个线程在给定时间足以有所排他写锁)或共享独占的(有个别线程持有排他锁定时,同时同意任何线程执行不一致性读)。共享独占访问被称为sxlock,该访问情势在读写场景下能够增加并发性和可扩大性。

内部存储器事件总计表有如下几张表:

*
performance_schema截断超越长度的属性数据,并追加Performance_schema_session_connect_attrs_lost状态变量值,截断1次扩大二遍,即该变量表示连接属性被截断了稍稍次

注意:这几个表只针对工作事件信息进行总计,即包括且仅包罗setup_instruments表中的transaction采集器,各类事情事件在各种表中的总计记录行数要求看怎么分组(例如:根据用户分组计算的表中,有多少个活泼用户,表中就会有稍许条相同采集器的记录),其余,总括计数器是或不是见效还索要看transaction采集器是或不是启用。

·OBJECT_INSTANCE_BEGIN:prepare语句事件的instruments
实例内部存款和储蓄器地址。

1 row in set (0.00 sec)

table_io_waits_summary_by_table表:

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

rwlock_instances表不容许行使TRUNCATE TABLE语句。

*
假如给定语句的总括新闻行在events_statements_summary_by_digest表中向来不已存在行,且events_statements_summary_by_digest表空间范围已满的场地下,则该语句的计算消息将增加到DIGEST
列值为
NULL的超过常规规“catch-all”行,如若该特别行不存在则新插入1行,FI福特ExplorerST_SEEN和LAST_SEEN列为当昨天子。假设该特别行已存在则更新该行的音信,LAST_SEEN为当前时间

PS:socket计算表不会计算空闲事件生成的等候事件音讯,空闲事件的等待音信是记录在伺机事件总计表中进行计算的。

| 内部存款和储蓄器事件计算表

admin@localhost : performance_schema 09 :50:01> select * from
users;

1 row in set (0.00 sec)

·IP:客户端IP地址。该值能够是IPv肆或IPv六地址,也得以是空手,表示那是3个Unix套接字文件延续;

| memory_summary_by_thread_by_event_name |

mutex_instances表列出了server执行mutex
instruments时performance_schema所见的全部互斥量。互斥是在代码中采用的一种共同机制,以强制在加以时间内唯有2个线程能够访问一些公共财富。能够认为mutex爱抚着这个公共财富不被随便抢占。

COUNT_STAR: 0

+——————————————————-+———————–+—————————+———————-+

EVENT_NAME: memory/innodb/fil0fil

02

# events_statements_summary_by_account_by_event_name表

从表中的笔录内容能够看出,依据库xiaoboluo下的表test举行分组,总括了表相关的等候事件调用次数,总括、最小、平均、最大延迟时间音信,利用这几个音信,大家能够大体精通InnoDB中表的造访功效排名计算情状,一定水平上反应了对存款和储蓄引擎接口调用的功效。

1 row in set (0.00 sec)

当在server中同时履行的多个线程(例如,同时执行查询的多个用户会话)必要拜访同1的能源(例如:文件、缓冲区或有个别数据)时,那八个线程互相竞争,因而首先个成功赢获得互斥体的询问将会堵塞别的会话的查询,直到成功获取到互斥体的对话执行到位并释放掉这么些互斥体,别的会话的查询才能够被实施。

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

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

# memory_summary_by_host_by_event_name表

# file_summary_by_instance表

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

AVG _TIMER_WAIT: 56688392

*
LOW_NUMBER_OF_BYTES_USED:如果CURRENT_NUMBER_OF_BYTES_USED减少N之后是3个新的最低值,则该字段相应核减

·当互斥体被销毁时,从mutex_instances表中删去相应的排挤体行。

# events_waits_summary_global_by_event_name表

1row inset ( 0. 00sec)

EVENT_NAME: stage/sql/After create

EVENT_NAME: wait/io/socket/sql/server_unix_socket

EVENT_NAME: transaction

·LOCKED_BY_THREAD_ID:当3个线程当前拥有3个排斥锁定时,LOCKED_BY_THREAD_ID列显示所无线程的THREAD_ID,借使未有被其余线程持有,则该列值为NULL。

events_statements_summary_global_by_event_name:根据各类事件名称进行总括的Statement事件

*
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字段,用于记录具体的磁盘文件有关音信。

MAX _TIMER_WAIT: 0

可透过如下语句查看:

AVG_TIMER_WAIT: 4426693000

·libmysqlclient客户端库(在MySQL和MySQL Connector /
C发行版中提供)提供以下属性:

*
将COUNT_ALLOC和COUNT_FREE列重置,并再次初始计数(等于内部存款和储蓄器计算消息以重置后的数值作为规范数据)

·ORDINAL_POSITION:将接连属性添加到连年属性集的次第。

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

·当监听套接字检测到两次三番时,srever将三番五次转移给一个由独立线程管理的新套接字。新连接线程的instruments具有client_connection的socket_type值,组成对应的instruments名称;

COUNT _READ_ONLY: 1

……

SUM _TIMER_WAIT: 0

友谊提示:下文中的计算表中多数字段含义与上1篇
《事件总计 | performance_schema全方位介绍》
中涉嫌的总括表字段含义相同,下文中不再赘述。其它,由于一些计算表中的记录内容过长,限于篇幅会简单部分文件,如有须求请自行安装MySQL
伍.柒.1壹之上版本跟随本文实行同步操作查看。

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

| NULL |41| 45 |

SUM _TIMER_WAIT: 0

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

咱俩先来看看那一个表中记录的计算消息是什么体统的(由于单行记录较长,那里只列出events_transactions_summary_by_account_by_event_name表中的示例数据,别的表的以身作则数据省略掉1部分雷同字段)。

1 row in set (0.00 sec)

| events_stages_summary_by_account_by_event_name |

SQL_TEXT: SELECT 1

大家先来看望这么些表中著录的总计音信是什么样子的(由于单行记录较长,那里只列出memory_summary_by_account_by_event_name
表中的示例数据,别的表的言传身教数据省略掉一部分同样字段)。

MIN_TIMER_READ_NORMAL: 0

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

OBJECT _INSTANCE_BEGIN: 2658004160

# events_statements_summary_global_by_event_name表

| table_lock_waits_summary_by_table |#
依照每一个表展开计算的表锁等待事件

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

| NAME |OBJECT_INSTANCE_BEGIN | WRITE_LOCKED_BY_THREAD_ID
|READ_LOCKED_BY_COUNT |

*
LOW_COUNT_USED:如果CURRENT_COUNT_USED收缩一以往是二个新的最低值,则该字段相应核减

·已呼吁但未给予的锁(呈现怎么会话正在守候哪些元数据锁);

1 row in set (0.01 sec)

| NULL |41| 45 |

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

*
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT:这个列总括全部I/O操作数量和操作时间

COUNT_STAR: 7

一连总括音讯表允许利用TRUNCATE
TABLE。它会同时删除计算表中从未连接的帐户,主机或用户对应的行,重置有连接的帐户,主机或用户对应的行的并将其余行的CURubiconRENT_CONNECTIONS和TOTAL_CONNECTIONS列值。

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

AVG _TIMER_WAIT: 3496961251500

| memory_summary_global_by_event_name |

| FILE_NAME |EVENT_NAME | OPEN_COUNT |

1 row in set (0.00 sec)

从上边表中的记录新闻大家得以看出(与公事I/O事件计算类似,两张表也各自依据socket事件类型计算与服从socket
instance进行总结)

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

·OBJECT_SCHEMA:该锁来自于哪个库级其余对象;

*
倘若该线程在threads表中并未有打开采集作用大概说在setup_instruments中对应的instruments未有打开,则该线程分配的内部存款和储蓄器块不会被监督

·MySQL Connector/Net定义了如下属性:

  • SUM_NUMBER_OF_BYTES_FREE

+———————————-+———————–+

* CURRENT_NUMBER_OF_BYTES_USED:减少N

·FILE_NAME:磁盘文件名称;

# 假设须要总结内部存储器事件音信,须要敞开内部存款和储蓄器事件采集器

AVG_TIMER_EXECUTE: 0

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

·EXTERNAL_LOCK:在蕴藏引擎级别使用的表锁。有效值为:READ
EXTE锐界NAL、W宝马X5ITE EXTE揽胜极光NAL。

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

| NAME |OBJECT_INSTANCE_BEGIN |

| 阶段事件总计表

OWNER _EVENT_ID: 49

……

OWNER_OBJECT_SCHEMA: NULL

SUM_TIMER_WAIT: 234614735000

·HOST:某总是的客户端主机名。假设是1个里头线程创制的连天,恐怕是心有余而力不足验证的用户创立的连日,则该字段为NULL;

1 row in set (0.00 sec)

admin@localhost : performance_schema 10:49:34> select * from
socket_instances;

HOST: NULL

……

质量事件总结表在setup_consumers表中只受控于”global_instrumentation”配置项,也正是说一旦”global_instrumentation”配置项关闭,全体的总结表的总括条目都不履行总括(总结列值为0);

* _client_version:客户端libmysql库版本

# events_stages_summary_by_account_by_event_name表

| 3 |_client_name | libmysql |1|

关于内部存款和储蓄器事件的一颦一笑监督装置与注意事项

·OBJECT_INSTANCE_BEGIN:mutex instruments实例的内部存款和储蓄器地址;

# 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

质量总计表

从地点表中的示范记录音讯中,大家能够见见,同样与等待事件类似,遵照用户、主机、用户+主机、线程等纬度进行分组与总计的列,分组列与等待事件类似,那里不再赘言,但对于内部存储器总计事件,总括列与其它两种事件总结列差别(因为内部存款和储蓄器事件不总计时间支付,所以与任何三种事件类型相比无一致计算列),如下:

(2)users表

SUM _NO_GOOD _INDEX_USED: 0

MIN _TIMER_READ _WITH_SHARED_LOCKS: 0

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

·OWNER_THREAD_ID:请求元数据锁的线程ID;

| events_statements_summary_global_by_event_name |

|4| _os |linux-glibc2. 5| 0 |

# memory_summary_by_user_by_event_name表

OBJECT_TYPE: TABLE

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

3rows inset ( 0. 00sec)

| events_waits_summary_by_thread_by_event_name |

·socket_summary_by_instance表:按照EVENT_NAME(该列有效值为wait/io/socket/sql/client_connection、wait/io/socket/sql/server_tcpip_socket、wait/io/socket/sql/server_unix_socket:)、OBJECT_INSTANCE_BEGIN列进行分组

LOW_COUNT_USED: 0

performance_schema还总括后台线程和不能证实用户的一连,对于这一个连接总括行音讯,USELAND和HOST列值为NULL。

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

·server只接受的接连属性数据的总计大小限制为64KB。假若客户端尝试发送当先64KB(正好是五个表全部字段定义长度的总限制长度)的属性数据,则server将拒绝该连接;

PS:内部存款和储蓄器总结表不带有计时新闻,因为内部存款和储蓄器事件不帮忙时间音讯收集。

·OWNER_EVENT_ID:触发table
handles被打开的事件ID,即持有该handles锁的事件ID;

COUNT_STAR: 0

admin@localhost : performance_schema 03:23:47> select * from
mutex_instances limit 1;

COUNT_STAR: 11

SUM _NUMBER_OF _BYTES_READ: 0

performance_schema把内部存款和储蓄器事件总括表也根据与等待事件总结表类似的规则进行归类总括。

……

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

OWNER_EVENT_ID: 54

从地点表中的言传身教记录新闻中,大家得以看到,同样与等待事件类似,根据用户、主机、用户+主机、线程等纬度进行分组与总结的列,那么些列的意思与等待事件类似,那里不再赘述。

·cond_instances:wait sync相关的condition对象实例;

# events_waits_summary_by_instance表

四.套接字事件总结

LAST_SEEN: 2018-05-20 10:24:42

| OBJECT_TYPE |OBJECT_SCHEMA | OBJECT_NAME |OBJECT_INSTANCE_BEGIN |
OWNER_THREAD_ID |OWNER_EVENT_ID | INTERNAL_LOCK |EXTERNAL_LOCK |

THREAD_ID: 1

LOCK_TYPE: SHARED_READ

*
FIRST_SEEN,LAST_SEEN:呈现某给定语句第1遍插入
events_statements_summary_by_digest表和最后三回创新该表的岁月戳

·users:依据用户名对每一种客户端连接进行总括。

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

| table_io_waits_summary_by_table |#
依照每一个表展开总括的表I/O等待事件

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

* _runtime_vendor:Java运维环境(JRE)供应商名称

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

·OWNER_EVENT_ID:请求元数据锁的事件ID。

* 如果DIGEST =
NULL行的COUNT_STAHummerH二列值占据整个表中全数总计新闻的COUNT_STAEscort列值的比重大于0%,则象征存在由于该表限制已满导致部分语句总结音讯不可能归类保存,就算您要求保留全数语句的总计音信,能够在server运维从前调整系统变量performance_schema_digests_size的值,默许大小为200

365体育备用 1

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

| HOST |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |

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

对于代码中的每个互斥体,performance_schema提供了以下音信:

MAX _TIMER_WAIT: 0

SUM_TIMER_WAIT: 62379854922

* COUNT_FREE:增加1

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

MIN _TIMER_WAIT: 0

咱俩先来看看表中记录的总括音讯是何等体统的。

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

小编们先来探视表中著录的计算音讯是如何样子的。

SUM _TIMER_WAIT: 0

上边对那些表分别举行介绍。

EVENT_NAME: wait/synch/mutex/mysys/THR_LOCK_heap

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

由于performance_schema表内部存款和储蓄器限制,所以珍视了DIGEST
= NULL的异样行。
当events_statements_summary_by_digest表限制体量已满的意况下,且新的言辞总计音讯在要求插入到该表时又未有在该表中找到匹配的DIGEST列值时,就会把这几个语句总计信息都总结到
DIGEST =
NULL的行中。此行可帮忙你预计events_statements_summary_by_digest表的限量是还是不是须要调动

COUNT_READ: 1

COUNT_ALLOC: 158

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

COUNT_STAR: 58

连天音信表accounts中的user和host字段含义与mysql系统数据库中的MySQL
grant表(user表)中的字段含义类似。

SUM _NUMBER_OF _BYTES_ALLOC: 3296

·OBJECT_INSTANCE_BEGIN:instruments对象的内部存款和储蓄器地址;

COUNT_STAR: 0

·hosts:依据host名称对种种客户端连接进行总计;

MIN_TIMER_WAIT:给定计时事件的蝇头等待时间

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

SUM _SORT_MERGE_PASSES: 0

# socket_summary_by_instance表

1 row in set (0.00 sec)

·不少MySQL客户端程序设置的属性值与客户端名称相等的1个program_name属性。例如:mysqladmin和mysqldump分别将program_name连接属性设置为mysqladmin和mysqldump,别的1些MySQL客户端程序还定义了附加属性:

SUM_SORT_ROWS: 170

*************************** 2. row
***************************

SUM _SELECT_FULL_JOIN: 21

metadata_locks表是只读的,不可能创新。私下认可保留行数会活动调整,就算要配置该表大小,能够在server运转在此以前安装系统变量performance_schema_max_metadata_locks的值。

*
COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE:执行prepare语句对象的总结新闻

OBJECT _INSTANCE_BEGIN: 2655350784

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

·INTERNAL_LOCK:在SQL级别使用的表锁。有效值为:READ、READ WITH
SHARED LOCKS、READ HIGH PBMWX伍IO奥迪Q5ITY、READ NO INSECR-VT、W奥迪Q三ITE ALLOW
WRubiconITE、WSportageITE CONCUEscortRENT INSE福特ExplorerT、W福特ExplorerITE LOW
PEscortIO索罗德ITY、WLX570ITE。有关那几个锁类型的详细消息,请参阅include/thr_lock.h源文件;

root@localhost : performance _schema 11:55:11> select * from
memory_summary _by_thread _by_event _name where COUNT_ALLOC!=0
limit 1G

·其间锁对应SQL层中的锁。是透过调用thr_lock()函数来落到实处的。(官方手册上说有3个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。但在该表的概念上并从未见到该字段)

AVG _TIMER_WAIT: 0

– END –

*
COUNT_ALLOC,COUNT_FREE:对内部存款和储蓄器分配和假释内部存款和储蓄器函数的调用总次数

table_io_waits_summary_by_index_usage表:

*
即便2个线程未有开启采集作用,不过内部存储器相关的instruments启用了,则该内部存款和储蓄器释放的操作会被监察和控制到,计算数据会爆发变动,那也是如今提到的为什么反复在运转时修改memory
instruments恐怕导致计算数据为负数的原委

# file_summary_by_event_name表

MAX _TIMER_WAIT: 0

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

| prepared_statements_instances |

·PO福睿斯T:TCP/IP端口号,取值范围为0〜6553伍;

* 对于memory
instruments,setup_instruments表中的TIMED列无效,因为内部存款和储蓄器操作不协助时间计算

MAX_TIMER_WAIT: 18446696808701862260

events_waits_summary_by_host_by_event_name表:按照列EVENT_NAME、HOST举行分组事件信息

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

对此各类线程的计算音信,适用以下规则。

+—————————————-+———————–+———–+———–+——————–+——-+——–+

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

(2)table_handles表

USER: root

下卷将为大家分享 《复制状态与变量记录表 |
performance_schema全方位介绍》 ,多谢你的开卷,大家不见不散!归来搜狐,查看越来越多

*
平日,truncate操作会重置总括消息的标准数据(即清空以前的数目),但不会修改当前server的内部存款和储蓄器分配等气象。也正是说,truncate内部存款和储蓄器总括表不会自由已分配内部存款和储蓄器

·NAME:与rwlock关联的instruments名称;

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

PS:MySQL
server使用二种缓存技术通过缓存从文件中读取的音讯来制止文件I/O操作。当然,假若内部存款和储蓄器不够时或然内部存款和储蓄器竞争相比大时可能导致查询功效低下,那年你恐怕需求经过刷新缓存恐怕重启server来让其数量通过文件I/O重返而不是经过缓存重临。

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

· NAME:与condition相关联的instruments名称;

可由此如下语句查看语句事件总计表:

prepared_statements_instances表字段含义如下:

CURRENT _NUMBER_OF _BYTES_USED: 0

MAX _TIMER_WAIT: 56688392

| Tables_in_performance_schema (%events_stages_summary%) |

OWNER_OBJECT_TYPE: NULL

MAX _TIMER_WAIT: 0

| localhost |1| 1 |

对此较高级别的聚集(全局,按帐户,按用户,按主机)计算表中,低水位和高水位适用于如下规则

performance_schema通过如下表来记录相关的锁音信:

IT从业多年,历任运行工程师、高级运维工程师、运转老总、数据库工程师,曾子与版本发表系列、轻量级监察和控制系统、运转管理平台、数据库管理平台的宏图与编写制定,熟稔MySQL种类布局,Innodb存款和储蓄引擎,喜好专研开源技术,追求百发百中。

该表的分组列与table_io_waits_summary_by_table表相同

| Tables_in_performance_schema (%events_statements_summary%) |

套接字总括表允许行使TRUNCATE
TABLE语句(除events_statements_summary_by_digest之外),只将总结列重置为零,而不是剔除行。

prepared_statements_instances:遵照每一个prepare语句实例聚合的总结消息

七.锁对象记录表

…………

·rwlock_instances:查看当前rwlock行的片段锁音信(独占锁被哪些线程持有,共享锁被有个别个线程持有等)。

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

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

| events_statements_summary_by_thread_by_event_name |

* _client_version:客户端库版本

AVG _TIMER_WAIT: 0

从客户端发送到服务器的总是属性数据量存在限制:客户端在连接从前客户端有一个祥和的定位长度限制(不可配置)、在客户端连接server时服务端也有一个稳住长度限制、以及在客户端连接server时的连天属性值在存入performance_schema中时也有1个可安插的尺寸限制。

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

……

SUM_ROWS_SENT: 1635

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

下1篇将为大家分享
《数据库对象事件总结与特性总括 | performance_schema全方位介绍》
,谢谢您的翻阅,大家不见不散!回去天涯论坛,查看越来越多

对于使用C
API运维的总是,libmysqlclient库对客户端上的客户端面连接属性数据的计算大小的定位长度限制为64KB:超出限制时调用mysql_options()函数会报C福睿斯_INVALID_PARAMETER_NO错误。其余MySQL连接器恐怕会设置自个儿的客户端面包车型大巴接连属性长度限制。

| 等待事件总结表

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

AVG _TIMER_WAIT: 0

1 row in set (0.00 sec)

| events_waits_summary_by_user_by_event_name |

·LOCK_TYPE:元数据锁子系统中的锁类型。有效值为:INTENTION_EXCLUSIVE、SHARED、SHARED_HIGH_PRIO、SHARED_READ、SHARED_WRITE、SHARED_UPGRADABLE、SHARED_NO_WRITE、SHARED_NO_READ_WRITE、EXCLUSIVE;

* SUM_NUMBER_OF_BYTES_ALLOC:增加N

OBJECT _INSTANCE_BEGIN: 2658003840

# events_stages_summary_by_user_by_event_name表

|4| _platform |x86_64 | 4 |

*
其余,根据帐户,主机,用户或线程分类计算的内部存款和储蓄器计算表或memory_summary_global_by_event_name表,如若在对其借助的accounts、hosts、users表执行truncate时,会隐式对那一个内部存款和储蓄器总计表执行truncate语句

·OBJECT_INSTANCE_BEGIN:此列是套接字实例对象的唯一标识。该值是内部存款和储蓄器中对象的地点;

5rows inset ( 0. 00sec)

admin@localhost : performance_schema 10:28:45> select * from
rwlock_instances limit 1;

| events_waits_summary_by_instance |

在服务器端面,会对接二连三属性数据实行长度检查:

| memory_summary_by_account_by_event_name |

SUM _TIMER_READ _WITH_SHARED_LOCKS: 0

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

* 使用mysqlnd编译:只有_client_name属性,值为mysqlnd

events_waits_summary_by_instance表:按照列EVENT_NAME、OBJECT_INSTANCE_BEGIN进行分组事件消息。如若叁个instruments(event_name)创制有七个实例,则每一种实例都独具唯一的OBJECT_INSTANCE_BEGIN值,由此各类实例会议及展览开独立分组

LOCK_DURATION: TRANSACTION

SUM _SELECT_FULL _RANGE_JOIN: 0

14 rows inset (0.01 sec)

1 row in set (0.00 sec)

·TOTAL_CONNECTIONS:某主机的总连接数。

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

……

# events_statements_summary_by_user_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

该表允许利用TRUNCATE
TABLE语句。只将总计列重置为零,而不是去除行。该表执行truncate时也会隐式触发table_io_waits_summary_by_table表的truncate操作。别的利用DDL语句更改索引结构时,会造成该表的有所索引总结音讯被重置

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

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

COUNT_STAR: 0

COUNT_READ_NORMAL: 0

内部存储器行为监督装置:

笔者们先来探视表中著录的总计音讯是哪些体统的。

MIN _TIMER_WAIT: 0

OBJECT _INSTANCE_BEGIN: 139968890586816

COUNT_STAR: 0

OBJECT _INSTANCE_BEGIN: 140568048055488

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

performance_schema通过table_handles表记录表锁音讯,以对最近种种打开的表所持有的表锁进行追踪记录。table_handles输出表锁instruments采集的始末。那几个新闻体现server中已开辟了何等表,锁定格局是怎么着以及被哪些会话持有。

COUNT_STAR: 0

users表包括连接到MySQL
server的种种用户的延续音讯,每种用户壹行。该表将对准用户名作为唯一标识进行总结当前连接数和总连接数,server运维时,表的大大小小会自动调整。
要显式设置该表大小,能够在server运行在此之前安装系统变量performance_schema_users_size的值。该变量设置为0时期表禁止使用users计算音信。

DIGEST: 4fb483fe710f27d1d06f83573c5ce11c

OBJECT_SCHEMA: xiaoboluo

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

·VICTIM,TIMEOUT和KILLED状态值停留时间非常粗略,当3个锁处于这一个情状时,那么表示该锁行音讯就要被删去(手动执行SQL只怕因为时间原因查看不到,能够行使程序抓取);

质量事件总结表中的数目条目是不能够去除的,只好把相应总结字段清零;

那个表列出了等候事件中的sync子类事件相关的靶子、文件、连接。个中wait
sync相关的对象类型有三种:cond、mutex、rwlock。每一个实例表都有3个EVENT_NAME或NAME列,用于体现与每行记录相关联的instruments名称。instruments名称可能拥有三个部分并形成层次结构,详见”配置详解
| performance_schema全方位介绍”。

从地点表中的演示记录音信中,我们能够看到,同样与等待事件类似,依照用户、主机、用户+主机、线程等纬度举办分组与计算的列,这一个列的含义与等待事件类似,那里不再赘言,但对于工作总括事件,针对读写事务和只读事务还独立做了总括(xx_READ_WRITE和xx_READ_ONLY列,只读事务须求安装只读事务变量transaction_read_only=on才会进行计算)。

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

Rows matched: 377 Changed: 377 Warnings: 0

SUM_TIMER_WAIT: 412754363625

COUNT _READ_WRITE: 6

咱俩先来看看表中著录的总括音讯是何等样子的。

USER: root

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

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

file_instances表差异意选取TRUNCATE TABLE语句。

| Tables_in_performance_schema (%events_waits_summary%) |

IP:PO奥迪Q伍T列组合值可用以标识3个连连。该组合值在events_waits_xxx表的“OBJECT_NAME”列中使用,以标识那些事件音讯是发源哪个套接字连接的:

THREAD_ID: 46

1row inset ( 0. 00sec)

SUM _TIMER_WAIT: 0

MAX_TIMER_READ: 9498247500

# events_statements_summary_by_thread_by_event_name表

·CURRENT_CONNECTIONS:某主机的近来连接数;

COUNT_STAR: 55

·当待处理的锁请求超时,会回去错误音信(E大切诺基_LOCK_WAIT_TIMEOUT)给请求锁的对话,锁状态从PENDING更新为TIMEOUT;

COUNT_STAR: 0

OBJECT_NAME: test

当某给定对象被实践时,其相应的总括音讯将记录在events_statements_summary_by_program表中并拓展总括。

·MySQL
Connector/J定义了之类属性:

USER: root

OPEN_COUNT:文件当前已开拓句柄的计数。假设文件打开然后关门,则打开一回,但OPEN_COUNT列将加一然后减1,因为OPEN_COUNT列只计算当前已打开的公文句柄数,已关闭的文件句柄会从中减去。要列出server中当前打开的保有文件消息,能够动用where
WHERE OPEN_COUNT> 0子句举办查看。

HOST: localhost

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

*
事务所占用的能源供给多少也或者会因作业隔开分离级别有所出入(例如:锁财富)。可是:每一个server恐怕是运用相同的割裂级别,所以不独立提供隔开级别相关的总括列

那么些音信使您能够明白会话之间的元数据锁依赖关系。不仅能够看看会话正在守候哪个锁,还足以见见眼下全数该锁的会话ID。

| events_statements_summary_by_account_by_event_name |

·当server中有的代码成立了2个互斥量时,在mutex_instances表中会添加一行对应的互斥体音信(除非无法再次创下制mutex
instruments
instance就不会添加行)。OBJECT_INSTANCE_BEGIN列值是互斥体的唯一标识属性;

MIN _TIMER_WAIT: 0

|wait/synch/cond/sql/COND_manager | 31903008 |

SUM _TIMER_WAIT: 0

……

| events_transactions_summary_global_by_event_name |

·EVENT_NAME:生成事件新闻的instruments
名称。与setup_instruments表中的NAME值对应;

……

从上边表中的记录消息大家得以观察,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等待时间,这一个表的分组和计算列含义请大家自行举壹反3,那里不再赘述,上面针对那三张表做壹些少不了的验证:

365体育备用 2

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

events_statements_summary_by_thread_by_event_name:根据每一个线程和事件名称进行计算的Statement事件

·当呼吁元数据锁不能立即收获时,将插入状态为PENDING的锁音信行;

| events_transactions_summary_by_user_by_event_name |

+————-+—————+————-+———————–+—————–+—————-+—————+—————+

# events_transactions_summary_by_host_by_event_name表

| 4 |_client_name | libmysql |1|

MAX _TIMER_READ_WRITE: 2427645000

admin@localhost : performance_schema 06:53:42> show tables like
‘%socket%summary%’;

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

+——————————————————-+———————–+—————————+———————-+

# events_statements_summary_by_digest表

COUNT_STAR: 33

*
内存instruments在setup_instruments表中装有memory/code_area/instrument_name格式的称谓。但暗许情状下超过四分之二instruments都被剥夺了,暗中认可只开启了memory/performance_schema/*开头的instruments

应用程序能够动用部分键/值对转移一些总是属性,在对mysql
server成立连接时传递给server。对于C
API,使用mysql_options()和mysql_options肆()函数定义属性集。其余MySQL连接器可以行使壹些自定义连接属性方法。

COUNT_STAKuga:事件被执行的数目。此值蕴含富有事件的履行次数,须求启用等待事件的instruments

发表评论

电子邮件地址不会被公开。 必填项已用*标注