金沙js29992

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

四月 5th, 2019  |  金沙js29992

instance表记录了何等类型的目的被检验。那个表中著录了轩然大波名称(提供收集功用的instruments名称)及其一些解释性的情况新闻(例如:file_instances表中的FILE_NAME文件名称和OPEN_COUNT文件打开次数),instance表首要有如下多少个:

# events_stages_summary_by_account_by_event_name表

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

     MySQL
Performance-Schema中总共包括53个表,首要分为几类:Setup表,Instance表,Wait
伊芙nt表,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奥迪Q7_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能够唯一分明一条记下。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:当事件始于时,这一列被安装为NULL。当事件结束时,再革新为近日的风浪ID。
SOU奥迪Q5CE:该事件发生时的源码文件
TIMER_START, TIMER_END,
TIMER_WAIT:事件开头/截止和等候的时刻,单位为微秒(picoseconds)

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE视情况而定
对于联合对象(cond, mutex, rwlock),这么些二个值均为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能够唯一分明一条记下。表中记录了当下线程所处的施行阶段,由于能够精通各种阶段的实施时间,由此通过stage表能够博得SQL在各种阶段消耗的时光。

THREAD_ID:线程ID
EVENT_ID:事件ID
END_EVENT_ID:刚甘休的风云ID
SOU奥迪Q5CE:源码地方
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能够唯1分明一条记下。Statments表只记录最顶层的乞求,SQL语句或是COMMAND,每条语句一行,对于嵌套的子查询只怕存款和储蓄进度不会独自列出。event_name形式为statement/sql/*,或statement/com/*
SQL_TEXT:记录SQL语句
DIGEST:对SQL_TEXT做MD五发出的三拾1位字符串。若是为consumer表中绝非打开statement_digest选项,则为NULL。
DIGEST_TEXT:将讲话中值部分用问号代替,用于SQL语句归类。假诺为consumer表中并未有打开statement_金沙js29992,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时,第1个表为全表扫描的多寡
SELECT_FULL_RANGE_JOIN:join时,引用表选拔range格局扫描的数量
SELECT_RANGE:join时,第1个表采纳range格局扫描的数额
SELECT_SCAN:join时,第一个表位全表扫描的多寡
SORT_ROWS:排序的记录数据
NESTING_EVENT_ID,NESTING_EVENT_TYPE,保留字段,为NULL。

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

Summary表
   
Summary表聚集了11维度的计算新闻包罗表维度,索引维度,会话维度,语句维度和锁维度的总括音讯。
(1).wait-summary表
events_waits_summary_global_by_event_name
现象:按等待事件类型聚合,每一种事件一条记下。
events_waits_summary_by_instance
情景:按等待事件目的聚合,同壹种等待事件,可能有七个实例,每一种实例有两样的内部存款和储蓄器地址,因而
event_name+object_instance_begin唯一明显一条记下。
events_waits_summary_by_thread_by_event_name
场合:按各种线程和事件来总计,thread_id+event_name唯1分明一条记下。
COUNT_STA酷威:事件计数
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:最后1个言语执行的年月
此情此景:用于总结某壹段时间内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(贰)
理论篇,performanceschema MySQL
Performance-Schema中一起蕴涵55个表,主要分为几类:Setup表,Instance表,Wait
伊芙nt表,Stage Ev…

hosts表字段含义如下:

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

·COUNT_READ,SUM_TIMER_READ,MIN_TIMER_READ,AVG_TIMER_READ,MAX_TIMER_READ,SUM_NUMBER_OF_BYTES_READ:那么些列计算全部接受操作(socket的RECV、RECVFROM、RECVMS类型操作,即以server为参考的socket读取数据的操作)相关的次数、时间、接收字节数等音讯

EVENT_NAME: transaction

MIN _TIMER_WAIT: 2971125

| events_statements_summary_by_user_by_event_name |

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

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

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

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

SUM_TIMER_READ: 0

HOST: localhost

·当server中1些代码成立了三个互斥量时,在mutex_instances表中会添加1行对应的互斥体消息(除非无法再成立mutex
instruments
instance就不会添加行)。OBJECT_INSTANCE_BEGIN列值是互斥体的唯1标识属性;

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

file_instances表字段含义如下:

USER: root

COUNT_STAR: 1

SUM _SELECT_FULL _RANGE_JOIN: 0

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

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

COUNT_STAR: 213055844

HOST: localhost

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

HIGH _NUMBER_OF _BYTES_USED: 32

AVG _TIMER_READ: 56688392

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

·ATTR_VALUE:连接属性值;

SUM_LOCK_TIME: 26026000000

rwlock_instances表字段含义如下:

COUNT_STAR: 0

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

1 row in set (0.00 sec)

| file_summary_by_event_name |

内部存款和储蓄器事件在setup_consumers表中并未有单身的安插项,且memory/performance_schema/*
instruments暗中认可启用,不可能在运转时或运营时关闭。performance_schema相关的内存总计信息只保存在memory_summary_global_by_event_name表中,不会保存在依据帐户,主机,用户或线程分类聚合的内部存款和储蓄器总计表中。

允许实施TRUNCATE TABLE语句,可是TRUNCATE
TABLE只是重置prepared_statements_instances表的总计音讯列,可是不会删除该表中的记录,该表中的记录会在prepare对象被销毁释放的时候自动删除。

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

[Warning] Connection attributes oflength N were truncated

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

3rows inset ( 0. 00sec)

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

·OBJECT_TYPE:元数据锁子系统中央银行使的锁类型(类似setup_objects表中的OBJECT_TYPE列值):有效值为:GLOBAL、SCHEMA、TABLE、FUNCTION、PROCEDURE、TRAV四IGGEQX56(当前未选用)、EVENT、COMMIT、USE途乐LEVEL LOCK、TABLESPACE、LOCKING SEQX56VICE,USEKoleos LEVEL
LOCK值表示该锁是行使GET_LOCK()函数获取的锁。LOCKING
SELANDVICE值表示使用锁服务获得的锁;

COUNT_STAR: 59

6.instance 统计表

1 row in set (0.00 sec)

……

MAX_TIMER_WAIT: 80968744000

OBJECT_NAME: test

MIN_TIMER_WAIT:给定计时事件的细微等待时间

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

AVG _TIMER_WAIT: 0

应用程序能够动用部分键/值对转移1些连接属性,在对mysql
server创造连接时传递给server。对于C
API,使用mysql_options()和mysql_options四()函数定义属性集。其余MySQL连接器能够运用部分自定义连接属性方法。

# memory_summary_global_by_event_name表

OBJECT _INSTANCE_BEGIN: 2658004160

*
LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED将重置为CU路虎极光RENT_NUMBER_OF_BYTES_USED列值

3rows inset ( 0. 00sec)

1row inset ( 0. 00sec)

·对于Unix
domain套接字(server_unix_socket)的server端监听器,端口为0,IP为空白;

COUNT_STAR: 0

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

SUM_NO_INDEX_USED: 42

OBJECT _INSTANCE_BEGIN: 140568048055488

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

SUM_TIMER_EXECUTE: 0

EVENT_NAME: memory/innodb/fil0fil

accounts表字段含义如下:

*
假如给定语句的计算信息行在events_statements_summary_by_digest表中未有已存在行,并且events_statements_summary_by_digest表空间范围未满的情事下,会在events_statements_summary_by_digest表中新插队一行统计音信,FISportageST_SEEN和LAST_SEEN列都使用当前时刻

·server
监听三个socket以便为互连网连接协议提供帮衬。对于监听TCP/IP或Unix套接字文件再而三来说,分别有3个名称为server_tcpip_socket和server_unix_socket的socket_type值,组成对应的instruments名称;

COUNT_STAR: 0

table_lock_waits_summary_by_table表:

| events_waits_summary_by_account_by_event_name |

PS:socket总结表不会总结空闲事件生成的等候事件音信,空闲事件的守候信息是记录在等候事件总计表中开始展览总括的。

SUM _TIMER_WAIT: 0

多少个老是可知的接连属性集合取决于与mysql
server建立连接的客户端平台项目和MySQL连接的客户端类型。

events_statements_summary_by_user_by_event_name:依照各种用户名和事件名称进行总括的Statement事件

performance_schema怎样管理metadata_locks表中著录的情节(使用LOCK_STATUS列来代表各类锁的景况):

*
平时,truncate操作会重置计算音讯的标准化数据(即清空在此以前的多少),但不会修改当前server的内部存储器分配等情事。也正是说,truncate内部存款和储蓄器总括表不会放出已分配内部存储器

·对于因而TCP/IP
套接字(client_connection)的客户端连接,端口是server随机分配的,但不会为0值.
IP是源主机的IP(127.0.0.一或地面主机的:: 一)。

内部存款和储蓄器事件instruments中除了performance_schema自己内部存款和储蓄器分配相关的风浪instruments配置暗中同意开启之外,其余的内部存款和储蓄器事件instruments配置都暗中认可关闭的,且在setup_consumers表中平素不像等待事件、阶段事件、语句事件与事务事件那样的单身布置项。

应用程序能够利用mysql_options()和mysql_options4()C
API函数在一连时提供部分要传送到server的键值对三番五次属性。

SUM_xxx:针对events_statements_*事件记录表中相应的xxx列举行总结。例如:语句总计表中的SUM_LOCK_TIME和SUM_ERRORS列对events_statements_current事件记录表中LOCK_TIME和EOdysseyRO帕杰罗S列实行总括

mutex_instances表字段含义如下:

*
假如给定语句的总计音讯行在events_statements_summary_by_digest表中平素不已存在行,且events_statements_summary_by_digest表空间范围已满的场馆下,则该语句的总计讯息将增加到DIGEST
列值为
NULL的出格“catch-all”行,固然该尤其行不设有则新插入一行,FI奇骏ST_SEEN和LAST_SEEN列为当前时刻。假使该尤其行已存在则更新该行的音讯,LAST_SEEN为近年来岁月

·外表锁对应存款和储蓄引擎层中的锁。通过调用handler::external_lock()函数来促成。(官方手册上说有1个OPERATION列来差别锁类型,该列有效值为:read
external、write external。但在该表的定义上并从未阅览该字段)

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

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

SUM_ERRORS: 2

PS:对于mutexes、conditions和rwlocks,在运作时尽管允许修改配置,且布局能够修改成功,不过有一些instruments不见效,需求在运营时配置才会卓有功能,若是您品尝着使用部分选用场景来追踪锁消息,你恐怕在那几个instance表中不能够查询到相应的音信。

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

SUM _TIMER_WAIT: 195829830101250

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

prepared_statements_instances表字段含义如下:

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

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

COUNT_STAR: 0

·file_summary_by_event_name:根据各个事件名称实行计算的文件IO等待事件

……

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

prepared_statements_instances表有自身额外的总结列:

root@localhost : performance _schema 04:44:00> select * from
socket_summary _by_event_nameG;

EVENT_NAME: stage/sql/After create

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

events_waits_summary_by_thread_by_event_name表:按照列THREAD_ID、EVENT_NAME举行分组事件音讯

| socket_summary_by_event_name |

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

·对此已接受的总是,performance_schema根据performance_schema_session_connect_attrs_size系统变量的值检查计算连接属性大小。倘若属性大小超过此值,则会执行以下操作:

EVENT_NAME: transaction

一. 连连音讯总计表

……

*
events_waits_current表中得以查看到近日正值班守护候互斥体的线程时间音讯(例如:TIME汉兰达_WAIT列表示已经等候的大运)

| events_statements_summary_by_host_by_event_name |

AVG _TIMER_WAIT: 3496961251500

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

| table_io_waits_summary_by_index_usage |#
依据每一种索引举办计算的表I/O等待事件

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

注意:rwlock_instances表中的音讯只好查看到持有写锁的线程ID,然则不能够查看到有着读锁的线程ID,因为写锁W奥德赛ITE_LOCKED_BY_THREAD_ID字段记录的是线程ID,读锁唯有三个READ_LOCKED_BY_COUNT字段来记录读锁被某些个线程持有。

MIN _TIMER_WAIT: 0

……

*
HIGH_NUMBER_OF_BYTES_USED:如果CURRENT_NUMBER_OF_BYTES_USED增添N之后是贰个新的最高值,则该字段值相应增多

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;

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

·USELacrosse:某些连接的用户名,如若是一个中间线程创立的连年,也许是心有余而力不足证实的用户创设的总是,则该字段为NULL;

*
FIRST_SEEN,LAST_SEEN:展现某给定语句第1遍插入
events_statements_summary_by_digest表和尾声一回立异该表的光阴戳

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

COUNT_ALLOC: 193

* mutex_instances表中的THREAD_ID列显示该互斥映以往被哪些线程持有。

1 row in set (0.00 sec)

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

1 row in set (0.00 sec)

从上边表中的笔录音讯大家得以见见,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,那里不再赘述,下边针对那3张表做1些不可或缺的印证:

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

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

| events_waits_summary_by_thread_by_event_name |

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

performance_schema把语句事件总括表也如约与等待事件总括表类似的规则举办分类总结,语句事件instruments暗中同意全体拉开,所以,语句事件总计表中暗中同意会记录全数的言语事件计算音信,话语事件总计表包涵如下几张表:

文件I/O事件总结表只记录等待事件中的IO事件(不分包table和socket子连串),文件I/O事件instruments默许开启,在setup_consumers表中无实际的应和配置。它包含如下两张表:

COUNT_STAR: 55

SUM_ROWS_AFFECTED: 0

大家先来探望这个表中记录的总结音信是何许体统的。

cond_instances表列出了server执行condition instruments
时performance_schema所见的持有condition,condition表示在代码中一定事件时有产生时的一起能量信号机制,使得等待该原则的线程在该condition知足条件时能够回复工作。

工作聚合总计规则

·accounts:根据user@host的样式来对各样客户端的再三再四进行计算;

| events_statements_summary_by_thread_by_event_name |

| wait/synch/mutex/mysys/THR_LOCK_heap |32576832| NULL |

EVENT_NAME: transaction

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

root@localhost : performance _schema 11:04:10> select * from
events_statements _summary_by _user_by _event_name where
COUNT_STAR!=0 limit 1G

* _os:客户端操作系统类型(例如Linux,Win64)

SUM _SELECT_RANGE_CHECK: 0

·万一是插入操作,则无法利用到目录,此时的总结值是根据INDEX_NAME =
NULL计算的

| prepared_statements_instances |

SUM_TIMER_WAIT: 412754363625

COUNT_STAR: 7

COUNT_STAR: 2560

SUM _TIMER_WAIT: 0

大家先来探望表中著录的计算音讯是什么体统的。

MAX _TIMER_WAIT: 0

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

* 对于memory
instruments,setup_instruments表中的TIMED列无效,因为内部存款和储蓄器操作不援救时间总结

……

HOST: NULL

各类套接字总括表都包括如下总计列:

COUNT_STAR: 53

* _client_name:客户端名称(客户端库的libmysql)

| Tables_in_performance_schema (%memory%summary%) |

·STATEMENT_NAME:对于2进制协议的口舌事件,此列值为NULL。对于文本协议的言语事件,此列值是用户分配的外表语句名称。例如:PREPARE
stmt FROM’SELECT 一’;,语句名字为stmt。

USER: NULL

(2)users表

SUM _TIMER_WAIT: 8649707000

performance_schema提供了针对性prepare语句的监督记录,并依据如下方法对表中的剧情开展管理。

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

* _platform:客户端机器平台(例如,x八陆_64)

5rows inset ( 0. 00sec)

AVG_TIMER_READ_NORMAL: 0

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

3rows inset ( 0. 00sec)

1 row in set (0.00 sec)

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

1 row in set (0.00 sec)

表字段含义与session_account_connect_attrs表字段含义相同。

SUM _TIMER_READ_ONLY: 57571000

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

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

·当行音信中CU汉兰达RENT_CONNECTIONS
字段值大于0时,执行truncate语句不会删除那个行,TOTAL_CONNECTIONS字段值被重置为CU普拉多RENT_CONNECTIONS字段值;

从上边表中的以身作则记录音讯中,大家得以见见:

1 row in set (0.00 sec)

质量评定内部存款和储蓄器工作负荷峰值、内部存储器总体的做事负荷稳定性、或者的内部存款和储蓄器泄漏等是重中之重的。

大家先来看望表中著录的总括音信是如何样子的。

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

rwlock_instances表列出了server执行rwlock
instruments时performance_schema所见的装有rwlock(读写锁)实例。rwlock是在代码中选用的同台机制,用于强制在加以时间内线程能够根据有些规则访问一些公共资源。能够认为rwlock爱戴着这一个财富不被其它线程随意抢占。访问方式可以是共享的(多个线程能够而且具有共享读锁)、排他的(同时唯有四个线程在加以时间能够享有排他写锁)或共享独占的(某些线程持有排他锁定时,同时允许别的线程执行不1致性读)。共享独占访问被称为sxlock,该访问方式在读写场景下能够增强并发性和可扩大性。

| events_waits_summary_by_host_by_event_name |

·OBJECT_INSTANCE_BEGIN:instruments对象的内存地址;

MAX _TIMER_WAIT: 0

在服务器端面,会对延续属性数据进行长度检查:

*
LOW_COUNT_USED和HIGH_COUNT_USED将重置为CU福睿斯RENT_COUNT_USED列值

| 4 |program_name | mysql |5|

| 温馨提醒

一.数据库表级别对象等待事件总计

除此以外,遵照帐户、主机、用户、线程聚合的每一个等待事件总结表或然events_waits_summary_global_by_event_name表,如若借助的连接表(accounts、hosts、users表)执行truncate时,那么注重的这一个表中的总结数据也会同时被隐式truncate

| admin |1| 1 |

SUM_WARNINGS: 0

·PROCESSLIST_ID:会话的总是标识符,与show
processlist结果中的ID字段相同;

# events_waits_summary_global_by_event_name表

·OBJECT_TYPE:展现handles锁的类型,表示该表是被哪些table
handles打开的;

由于performance_schema表内部存款和储蓄器限制,所以敬爱了DIGEST
= NULL的非常规行。
当events_statements_summary_by_digest表限制容积已满的情事下,且新的话语总括新闻在要求插入到该表时又未有在该表中找到匹配的DIGEST列值时,就会把这么些语句总括新闻都总结到
DIGEST =
NULL的行中。此行可支持您臆度events_statements_summary_by_digest表的限量是或不是须求调整

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

1 row in set (0.00 sec)

admin@localhost : performance_schema 11:00:45> select * from
session_account_connect_attrs;

SUM _TIMER_WAIT: 0

套接字事件总结了套接字的读写调用次数和出殡和埋葬接收字节计数消息,socket事件instruments暗中同意关闭,在setup_consumers表中无实际的照应配置,包罗如下两张表:

COUNT_STAR: 7

OBJECT_NAME: test

1 row in set (0.00 sec)

OBJECT_SCHEMA: xiaoboluo

performance_schema把业务事件总括表也服从与等待事件总结表类似的规则进行归类计算,事务事件instruments唯有贰个transaction,暗中同意禁止使用,事务事件计算表有如下几张表:

·COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE:执行prepare语句时的连锁总结数据。

下1篇将为大家分享
《数据库对象事件计算与天性总括 | performance_schema全方位介绍》
,谢谢您的翻阅,大家不见不散!回来和讯,查看更加多

·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列实行分组

MIN_TIMER_WAIT: 72775000

table_handles表不允许选择TRUNCATE TABLE语句。

events_statements_summary_by_thread_by_event_name:遵照各样线程和事件名称进行总结的Statement事件

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

# events_transactions_summary_by_account_by_event_name表

下篇将为我们分享 《复制状态与变量记录表 |
performance_schema全方位介绍》 ,感谢您的读书,大家不见不散!再次回到天涯论坛,查看越来越多

HOST: localhost

……

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

| localhost |1| 1 |

SUM _TIMER_WAIT: 0

大家先来看望表中著录的计算新闻是哪些样子的。

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

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

……

OWNER_OBJECT_NAME: NULL

THREAD_ID: 37

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

在上1篇《事件记录 |
performance_schema全方位介绍”》中,大家详细介绍了performance_schema的事件记录表,恭喜大家在学习performance_schema的旅途度过了多少个最狼狈的时期。以往,相信我们早就相比较清楚什么是事件了,但有时候大家不必要精晓每时每刻产生的每一条事件记录音讯,
例如:大家希望明白数据库运转以来壹段时间的轩然大波计算数据,那一年就供给查阅事件总括表了。后天将指点我们1起踏上层层第4篇的道路(全系共九个篇章),在那壹期里,大家将为我们无微不至授课performance_schema中事件计算表。总括事件表分为伍个品类,分别为等候事件、阶段事件、语句事件、事务事件、内部存款和储蓄器事件。上边,请随行大家联合开首performance_schema系统的就学之旅吧。

# socket_summary_by_event_name表

* CURRENT_COUNT_USED:增加1

·当呼吁霎时获得元数据锁时,将插入状态为GRANTED的锁音信行;

7rows inset ( 0. 00sec)

·很多MySQL客户端程序设置的属性值与客户端名称相等的3个program_name属性。例如:mysqladmin和mysqldump分别将program_name连接属性设置为mysqladmin和mysqldump,其它1些MySQL客户端程序还定义了增大属性:

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

| FILE_NAME |EVENT_NAME | OPEN_COUNT |

SUM _TIMER_WAIT: 0

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

*
要是该线程在threads表中尚无开启采集作用或许说在setup_instruments中对应的instruments未有开启,则该线程分配的内部存款和储蓄器块不会被监督

·当呼吁元数据锁无法马上收获时,将插入状态为PENDING的锁消息行;

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

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

# memory_summary_by_user_by_event_name表

| NAME |OBJECT_INSTANCE_BEGIN | WRITE_LOCKED_BY_THREAD_ID
|READ_LOCKED_BY_COUNT |

SUM _NUMBER_OF _BYTES_ALLOC: 3296

·当待处理的锁请求超时,会回去错误音讯(E本田UR-V_LOCK_WAIT_TIMEOUT)给请求锁的对话,锁状态从PENDING更新为TIMEOUT;

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

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

*
将COUNT_ALLOC和COUNT_FREE列重置,同仁一视新开头计数(等于内部存款和储蓄器计算音信以重置后的数值作为标准数据)

OBJECT_SCHEMA: xiaoboluo

| Tables_in_performance_schema (%prepare%) |

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

admin@localhost : performance_schema 06:56:56> show tables like
‘%memory%summary%’;

| HOST |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |

SUM _SORT_MERGE_PASSES: 0

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

SUM_ROWS_EXAMINED: 39718

* file_summary_by_event_name表:按照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 in set (0.00 sec)

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

·CURRENT_CONNECTIONS:某用户的此时此刻连接数;

当某给定对象在server中第3回被利用时(即利用call语句调用了储存进度或自定义存款和储蓄函数时),将在events_statements_summary_by_program表中添加1行总括新闻;

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

| Tables_in_performance_schema (%events_stages_summary%) |

admin@localhost : performance _schema 10:50:38> select * from
prepared_statements_instancesG;

USER: NULL

|admin | localhost |1| 1 |

AVG _TIMER_READ_ONLY: 57571000

·刑释元数据锁时,对应的锁音信行被去除;

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

SUM _NUMBER_OF _BYTES_READ: 0

HOST: localhost

MAX _TIMER_WAIT: 121025235946125

1 row in set (0.00 sec)

MySQL允许应用程序引进新的连日属性,不过以下划线(_)伊始的性子名称保留供内部采取,应用程序不要创设那种格式的两次三番属性。以确认保证内部的连天属性不会与应用程序创造的连天属性相争辩。

MAX _TIMER_READ_WRITE: 2427645000

OWNER_THREAD_ID: 48

AVG _TIMER_WAIT: 0

EVENT_NAME: wait/io/socket/sql/client_connection

*
HIGH_COUNT_USED:如果CURRENT_COUNT_USED扩展1是二个新的最高值,则该字段值相应增多

那个音信使您可以理解会话之间的元数据锁依赖关系。不仅能够见见会话正在守候哪个锁,还足以观察近来全部该锁的会话ID。

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

FILE_NAME: /data/mysqldata1/innodb_ts/ibdata1

大家先来探望这一个表中记录的总括新闻是怎样体统的(由于单行记录较长,那里只列出events_transactions_summary_by_account_by_event_name表中的示例数据,别的表的以身作则数据省略掉1部分雷同字段)。

·当全体互斥体的线程释放互斥体时,mutex_instances表中对应排斥体行的THREAD_ID列被修改为NULL;

*
以前缀memory/performance_schema命名的instruments能够搜集performance_schema自个儿消耗的中间缓存区大小等音讯。memory/performance_schema/*
instruments暗中同意启用,无法在运维时或运营时关闭。performance_schema本身有关的内部存款和储蓄器计算新闻只保存在memory_summary_global_by_event_name表中,不会保存在根据帐户,主机,用户或线程分类聚合的内部存款和储蓄器总计表中

·events_waits_current:查看线程正在等候什么rwlock;

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

*
COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_W中华VITE:这么些列总结了有着文件写操作,包括FPUTS,FPUTC,FP帕杰罗INTF,VFPHighlanderINTF,FW奥迪Q5ITE和PW牧马人ITE系统调用,还富含了那一个I/O操作的数量字节数

*
CURRENT_NUMBER_OF_BYTES_USED:当前已分配的内部存款和储蓄器块但未释放的总括大小。那是2个便捷列,等于SUM_NUMBER_OF_BYTES_ALLOC

数据库对象计算表

MIN _TIMER_WAIT: 0

·当此前请求不能马上赢得的锁在那以往被赋予时,其锁音讯行状态更新为GRANTED;

IT从业多年,历任运行工程师、高级运营工程师、运转COO、数据库工程师,曾插手版本发布连串、轻量级监察和控制种类、运行管理平台、数据库管理平台的设计与编写制定,熟习MySQL种类布局,Innodb存款和储蓄引擎,喜好专研开源技术,追求完美。

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

CURRENT _NUMBER_OF _BYTES_USED: 0

COUNT_EXECUTE: 0

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

cond_instances表字段含义如下:

SUM _NO_GOOD _INDEX_USED: 0

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

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

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

THREAD_ID: 1

·已呼吁但未给予的锁(显示怎么会话正在等待哪些元数据锁);

THREAD_ID: 47

1row inset ( 0. 00sec)

COUNT_ALLOC: 1

·OWNER_EVENT_ID:触发table
handles被打开的轩然大波ID,即持有该handles锁的轩然大波ID;

*
LOW_NUMBER_OF_BYTES_USED,HIGH_NUMBER_OF_BYTES_USED:对应CURRENT_NUMBER_OF_BYTES_USED列的低和高水位标记

STATEMENT_NAME: stmt

# events_waits_summary_by_account_by_event_name表

COUNT_STAR: 56

SUM _TIMER_WAIT: 0

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

CURRENT_COUNT_USED: 0

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

MAX _TIMER_WAIT: 0

root@localhost : performance _schema 05:11:45> select * from
socket_summary _by_instance where COUNT_STAR!=0G;

当八个可被监察和控制的内存块N被假释时,performance_schema会对总结表中的如下列进行翻新:

SUM_ROWS_SENT: 0

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

当在server中并且执行的多少个线程(例如,同时施行查询的几个用户会话)供给拜访同1的能源(例如:文件、缓冲区或少数数据)时,那多个线程相互竞争,因而首先个成功收获到互斥体的查询将会卡住其余会话的查询,直到成功博获得互斥体的对话执行到位并释放掉这些互斥体,其余会话的查询才能够被实践。

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

责编:

COUNT_ALLOC: 103

·EXTERNAL_LOCK:在存款和储蓄引擎级别使用的表锁。有效值为:READ
EXTE冠道NAL、W奥迪Q7ITE EXTE奔驰M级NAL。

# 若是急需计算内部存款和储蓄器事件消息,要求敞开内部存款和储蓄器事件采集器

MAX_TIMER_READ: 9498247500

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

原标题:数据库对象事件与品质总计 | performance_schema全方位介绍(5)

AVG _TIMER_WAIT: 0

| qfsys |1| 1 |

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

# table_lock_waits_summary_by_table表

| events_transactions_summary_by_user_by_event_name |

| EVENT_NAME |OBJECT_INSTANCE_BEGIN | THREAD_ID |SOCKET_ID | IP
|PORT | STATE |

*
LOW_COUNT_USED和LOW_NUMBER_OF_BYTES_USED是较低的低水位预计值。performance_schema输出的低水位值能够保障计算表中的内存分配次数和内部存款和储蓄器小于或等于当前server中真正的内部存款和储蓄器分配值

·execute步骤:语法EXECUTE stmt_name[USING @var_name [,
@var_name] …],示例:execute stmt;
再次回到执行结果为1,此时在prepared_statements_instances表中的总结音信会议及展览开创新;

SUM_SORT_ROWS: 170

AVG_TIMER_WAIT: 24366870

COUNT_STAR: 0

admin@localhost : performance_schema 05:47:55> select * from
table_handles;

USER: root

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

USER: NULL

MIN_TIMER_WAIT: 1905016

……

AVG _TIMER_WAIT: 56688392

对于内部存款和储蓄器块的放走,依照如下规则进行检查测试与聚集:

OBJECT_NAME: test

root@localhost : performance _schema 11:04:31> select * from
events_statements _summary_global _by_event_name limit 1G

OBJECT_TYPE: TABLE

HOST: NULL

从地方表中的记录音信大家可以看来(与公事I/O事件总括类似,两张表也分头根据socket事件类型计算与遵循socket
instance进行计算)

#
events_statements_summary_by_program表(须要调用了储存进度或函数之后才会有多少)

咱俩先来探望表中记录的总结新闻是什么体统的。

EVENT_NAME: stage/sql/After create

metadata_locks表字段含义如下:

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

OBJECT_NAME: test

COUNT_STAR: 0

|4| _pid |3766| 2 |

*
CURRENT_COUNT_USED:那是多个便捷列,等于COUNT_ALLOC – COUNT_FREE

|TABLE | xiaoboluo |test | 140568038528544 |0| 0 |NULL | NULL |

# events_statements_summary_by_account_by_event_name表

……

root@localhost : performance _schema 12:34:43> select * from
events_statements _summary_by_programG;

·当1个线程尝试获得已经被有个别线程持有的互斥体时,在events_waits_current表中会呈现尝试获得那几个互斥体的线程相关等待事件消息,展现它正在等候的mutex
连串(在EVENT_NAME列中得以看出),并体现正在等候的mutex
instance(在OBJECT_INSTANCE_BEGIN列中能够看看);

SUM _CREATED_TMP _DISK_TABLES: 3

# socket_summary_by_instance表

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

·ORDINAL_POSITION:将延续属性添加到连年属性集的相继。

MIN _TIMER_WAIT: 57571000

传闻请求锁的线程数以及所请求的锁的质量,访问格局有:独占方式、共享独占形式、共享格局、也许所请求的锁无法被全部予以,须要先等待别的线程完结并释放。

| events_waits_summary_global_by_event_name |

OBJECT_SCHEMA: xiaoboluo

SUM_SORT_RANGE: 0

*
复制slave连接的program_name属性值被定义为mysqld、定义了_client_role属性,值为binary_log_listener、_client_replication_channel_name属性,值为坦途名称字符串

……

* mysqlbinlog定义了_client_role属性,值为binary_log_listener

AVG _TIMER_READ_WRITE: 1432022000

(5) socket_instances表

PS1:

·LOCK_STATUS:元数据锁子系统的锁状态。有效值为:PENDING、GRANTED、VICTIM、TIMEOUT、KILLED、PRE_ACQUIRE_NOTIFY、POST_RELEASE_NOTIFY。performance_schema依据差异的阶段更改锁状态为这一个值;

SUM _TIMER_WAIT: 0

SUM_TIMER_READ: 305970952875

COUNT_STAR: 7

·session_connect_attrs:全体会话的连天属性。

当某给定对象被剔除时,该指标在events_statements_summary_by_program表中的计算消息就要被删除;

标签:

Your Comments

近期评论

    功能


    网站地图xml地图