菜单

数据库对象事件与质量计算 | performance_schema全方位介绍(5)

2019年4月11日 - 科技杂志
数据库对象事件与质量计算 | performance_schema全方位介绍(5)

STATEMENT_ID: 1

1 row in set (0.00 sec)

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

     MySQL
Performance-Schema中一起蕴含5五个表,首要分为几类:Setup表,Instance表,Wait
伊夫nt表,Stage 伊芙nt表Statement
Event表,Connection表和Summary表。上一篇小说已经首要讲了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/THLX570_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表记录了每一种线程近来守候的13个事件,而history_long表则记录了近日具有线程发生的10000个事件,那里的10和10000都是能够配备的。那多个表表结构同样,history和history_long表数据都出自current表。current表和history表中可能会有重新事件,并且history表中的事件都是落成了的,没有截至的风浪不会加盟到history表中。
THREAD_ID:线程ID
EVENT_ID:当前线程的轩然大波ID,和THREAD_ID组成3个Primary Key。
END_EVENT_ID:当事件开头时,那一列棉被服装置为NULL。当事件停止时,再次创下新为当下的轩然大波ID。
SOU帕杰罗CE:该事件时有发生时的源码文件
TIMER_START, TIMER_END,
TIMER_WAIT:事件始于/甘休和等待的年华,单位为纳秒(picoseconds)

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE视情状而定
对于联合对象(cond, mutex, rwlock),那么些3个值均为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途达CE:源码地点
TIMER_START, TIMER_END,
TIMER_WAIT:事件开端/甘休和等候的小运,单位为阿秒(picoseconds)
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT, STAGE, WAIT)

Statement Event表
     
Statement表首要涵盖1个表,events_statements_current,events_statements_history和events_statements_history_long。通过thread_id+event_id能够唯一鲜明一条记下。Statments表只记录最顶层的央浼,SQL语句或是COMMAND,每条语句一行,对于嵌套的子查询或许存储进度不会独自列出。event_name形式为statement/sql/*,或statement/com/*
SQL_TEXT:记录SQL语句
DIGEST:对SQL_TEXT做MD伍发出的34人字符串。如若为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时,第二个表选取range格局扫描的数量
SELECT_SCAN:join时,第3个表位全表扫描的数额
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唯壹鲜明一条记下。
events_waits_summary_by_thread_by_event_name
意况:按每一种线程和事件来总计,thread_id+event_name唯一明确一条记下。
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:第3个语句执行的时日
LAST_SEEN_TIMESTAMP:末了3个话语执行的光阴
情景:用于总结某一段时间内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
INSEBMWX叁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中一起包蕴五11个表,首要分为几类:Setup表,Instance表,Wait
伊夫nt表,Stage Ev…

(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

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

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

(6).table_io_waits_summary_by_index_usage
与table_io_waits_summary_by_table类似,按索引维度总结

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

SUM _NUMBER_OF _BYTES_ALLOC: 3296

Statement
Event表
     
Statement表首要涵盖二个表,events_statements_current,events_statements_history和events_statements_history_long。通过thread_id+event_id能够唯壹分明一条记下。Statments表只记录最顶层的呼吁,SQL语句或是COMMAND,每条语句壹行,对于嵌套的子查询也许存款和储蓄进度不会单独列出。event_name形式为statement/sql/*,或statement/com/*
SQL_TEXT:记录SQL语句
DIGEST:对SQL_TEXT做MD5生出的三16位字符串。尽管为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时,第一个表位全表扫描的数额
SORT_ROWS:排序的记录数据
NESTING_EVENT_ID,NESTING_EVENT_TYPE,保留字段,为NULL。

(1)metadata_locks表

……

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

mutex_instances表不容许利用TRUNCATE TABLE语句。

COUNT_STAR: 7

Wait Event表
     
Wait表重要包蕴2个表,events_waits_current,events_waits_history和events_waits_history_long,通过thread_id+event_id能够唯1鲜明一条记下。current表记录了当前线程等待的轩然大波,history表记录了每种线程如今守候的拾三个事件,而history_long表则记录了近期全数线程发生的一千0个事件,那里的10和10000都以足以安排的。那多个表表结构同样,history和history_long表数据都来自current表。current表和history表中只怕会有再一次事件,并且history表中的事件都以瓜熟蒂落了的,未有终结的轩然大波不会投入到history表中。
THREAD_ID:线程ID
EVENT_ID:当前线程的事件ID,和THREAD_ID组成多个Primary
Key。
END_EVENT_ID:当事件始于时,这一列被设置为NULL。当事件截止时,再次创下新为近期的风云ID。
SOUCR-VCE:该事件发生时的源码文件
TIMER_START, TIMER_END,
TIMER_WAIT:事件起初/甘休和等候的时光,单位为飞秒(picoseconds)

·metadata_locks:元数据锁的持有和伸手记录;

……

(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

| table_io_waits_summary_by_table |#
依照种种表展开总结的表I/O等待事件

SUM _TIMER_WAIT: 0

events_statements_summary_by_account_by_event_name
events_statements_summary_by_user_by_event_name
events_statements_summary_by_host_by_event_name

OBJECT_TYPE: TABLE

1 row in set (0.00 sec)

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

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

COUNT_FREE: 103

(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等

MAX_TIMER_READ: 0

| events_waits_summary_global_by_event_name |

Stage Event表 

01

COUNT_ALLOC: 158

(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

· OWNER_THREAD_ID:持有该handles锁的线程ID;

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

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

我们先来看望表中记录的总计音信是怎么着样子的。

SUM _NUMBER_OF _BYTES_FREE: 3296

(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

OBJECT_SCHEMA: xiaoboluo

PS1:

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

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

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

THREAD_ID:线程ID
EVENT_ID:事件ID
END_EVENT_ID:刚截止的风云ID
SOUXC60CE:源码地点
TIMER_START, TIMER_END,
TIMER_WAIT:事件始于/结束和等候的大运,单位为皮秒(picoseconds)
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT,
STAGE, WAIT)

元数据锁instruments使用wait/lock/metadata/sql/mdl,暗中认可未张开。

performance_schema把等待事件总括表依据差别的分组列(分化纬度)对等候事件有关的数码实行联谊(聚合计算数据列包涵:事件爆发次数,总等待时间,最小、最大、平均等待时间),注意:等待事件的采访功效有部分暗许是禁止使用的,供给的时候能够透过setup_instruments和setup_objects表动态开启,等待事件总括表包括如下几张表:

(9).socket-summaries表
socket_summary_by_instance
socket_summary_by_event_name

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

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

     MySQL
Performance-Schema中总结包括55个表,首要分为几类:Setup表,Instance表,Wait
伊芙nt表,Stage 伊夫nt表Statement
Event表,Connection表和Summary表。上壹篇文章已经重要讲了Setup表,那篇作品将会独家就每类别型的表做详细的讲述。

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

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

(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奥迪Q伍T总括,相应的还有DELETE和UPDATE计算。

prepared_statements_instances表字段含义如下:

CURRENT _NUMBER_OF _BYTES_USED: 0

(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的老毛病是,只能记录持有写锁的线程,对于读锁则无从。

| USER |HOST | CURRENT_CONNECTIONS |TOTAL_CONNECTIONS |

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

events_stages_summary_by_account_by_event_name
events_stages_summary_by_user_by_event_name
events_stages_summary_by_host_by_event_name

当客户端与server端建立连接时,performance_schema使用符合各种表的唯壹标识值来规定每种连接表中什么进行记录。假使贫乏对应标识值的行,则新添加一行。然后,performance_schema会增多该行中的CU宝马X三RENT_CONNECTIONS和TOTAL_CONNECTIONS列值。

* COUNT_FREE:增加1

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)

·mutex_instances:wait sync相关的Mutex对象实例;

MAX _TIMER_WAIT: 0

     
 Stage表重要包括一个表,events_stages_current,events_stages_history和events_stages_history_long,通过thread_id+event_id可以唯一分明一条记下。表中记录了现阶段线程所处的推行阶段,由于能够知道各种阶段的执行时间,因此通过stage表能够收获SQL在各类阶段消耗的岁月。

| wait/io/socket/sql/client_connection |110668160 | 46 |53| |0| ACTIVE
|

prepared_statements_instances表有协调额外的总计列:

(2)file_instances:文件实例
表中记录了系统中打开了文本的对象,包涵ibdata文件,redo文件,binlog文件,用户的表文件等,比如redo日志文件:/u01/my3306/data/ib_logfile0。open_count呈现当前文件打开的多寡,要是重来未有打开过,不会油然则生在表中。

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

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

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唯1分明一条记下。
COUNT_STA奥迪Q7:事件计数
SUM_TIMER_WAIT:总的等待时间
MIN_TIMER_WAIT:最小等待时间
MAX_TIMER_WAIT:最大等待时间
AVG_TIMER_WAIT:平均等待时间

·OWNER_THREAD_ID,OWNER_EVENT_ID:这个列表示成立prepare语句的线程ID和事件ID。

OBJECT_TYPE: PROCEDURE

(3)mutex_instances:互斥同步对象实例
表中著录了系统中使用互斥量对象的拥有记录,其中name为:wait/synch/mutex/*。比如打开文件的互斥量:wait/synch/mutex/mysys/THPRADO_LOCK_open。LOCKED_BY_THREAD_ID展现哪个线程正持有mutex,若未有线程持有,则为NULL。

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

EVENT_NAME: statement/sql/select

其它表
performance_timers:
系统帮助的计算时间单位
threads:
监视服务端的当前运转的线程

OBJECT_TYPE: TABLE

| memory_summary_by_user_by_event_name |

COUNT_STAR: 213055844

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

(2)file_instances表

*
假设该线程在threads表中从不开启采集功效或许说在setup_instruments中对应的instruments未有打开,则该线程分配的内部存款和储蓄器块不会被监督

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

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

我们先来看望表中记录的计算新闻是怎么着体统的。

AVG _TIMER_WAIT: 1235672000

*************************** 4. row
***************************

| 导语

·hosts:根据host名称对各样客户端连接实行总括;

AVG _TIMER_WAIT: 0

MAX _TIMER_WAIT: 56688392

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

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

COUNT_STAR: 11

3 rows in set (0.00 sec)

5rows inset ( 0. 00sec)

1row inset ( 0. 00sec)

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

与objects_summary_global_by_type
表总结音讯类似,表I/O等待和锁等待事件总括信息进而精细,细分了每一个表的增加和删除改查的执行次数,总等待时间,最小、最大、平均等待时间,甚至精细到有些索引的增加和删除改查的守候时间,表IO等待和锁等待事件instruments(wait/io/table/sql/handler和wait/lock/table/sql/handler
)暗许开启,在setup_consumers表中无具体的相应配置,默许表IO等待和锁等待事件总计表中就会总结有关事件音信。包蕴如下几张表:

root@localhost : performance _schema 11:50:46> update
setup_instruments set enabled=’yes’,timed=’yes’ where name like
‘memory/%’;

我们先来看望表中著录的总括新闻是怎样样子的。

| Tables_in_performance_schema (%events_waits_summary%) |

MAX_TIMER_READ: 9498247500

SUM _SORT_MERGE_PASSES: 0

AVG_TIMER_EXECUTE: 0

内存事件在setup_consumers表中从未单身的布局项,且memory/performance_schema/*
instruments暗中认可启用,不能够在运维时或运营时关闭。performance_schema相关的内部存款和储蓄器总结音信只保存在memory_summary_global_by_event_name表中,不会保存在根据帐户,主机,用户或线程分类聚合的内部存款和储蓄器总括表中。

下边对那些表分别展开介绍。

THREAD_ID: 46

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

| memory_summary_by_thread_by_event_name |

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

HOST: NULL

AVG _TIMER_WAIT: 56688392

1 row in set (0.00 sec)

·session_account_connect_attrs:记录当前对话及其相关联的别的会话的连年属性;

业务聚合总计规则

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

1 row in set (0.00 sec)

各样套接字计算表都包蕴如下计算列:

SUM _SELECT_RANGE_CHECK: 0

·COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_WLANDITE:这一个列计算了装有发送操作(socket的SEND、SENDTO、SENDMSG类型操作,即以server为参照的socket写入数据的操作)相关的次数、时间、接收字节数等新闻

*
FIRST_SEEN,LAST_SEEN:展现某给定语句第壹遍插入
events_statements_summary_by_digest表和终极贰遍立异该表的日子戳

1row inset ( 0. 00sec)

SUM_TIMER_WAIT:总结给定计时事件的总等待时间。此值仅针对有计时效果的风云instruments或打开了计时作用事件的instruments,要是某事件的instruments不补助计时大概未有拉开计时成效,则该字段为NULL。其余xxx_TIMER_WAIT字段值类似

accounts表包罗连接到MySQL
server的种种account的笔录。对于每个帐户,没个user+host唯1标识一行,每行单独计算该帐号的近年来连接数和总连接数。server运营时,表的大小会活动调整。要显式设置表大小,能够在server运营以前设置系统变量performance_schema_accounts_size的值。该类别变量设置为0时,表示禁止使用accounts表的总计音讯意义。

AVG _TIMER_WAIT: 0

·PS:cond_instances表区别意采纳TRUNCATE TABLE语句。

SUM_NO_INDEX_USED: 42

|admin | localhost |1| 1 |

SUM_ROWS_SENT: 1635

OBJECT _INSTANCE_BEGIN: 139968890586816

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

二. 一而再属性总结表

performance_schema把语句事件总括表也如约与等待事件总括表类似的规则进行分类总结,语句事件instruments暗中同意全部开启,所以,语句事件计算表中默许会记录全体的话语事件总计音信,言语事件总括表包罗如下几张表:

OWNER_EVENT_ID: 54

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

OBJECT _INSTANCE_BEGIN: 2655350784

*
假设三个线程开启了征集功效,不过内部存款和储蓄器相关的instruments未有启用,则该内部存款和储蓄器释放操作不会被监督到,计算数据也不会生出转移

cond_instances表字段含义如下:

AVG_TIMER_WAIT: 4426693000

(3)mutex_instances表

MAX _TIMER_WAIT: 0

相应的instruments为wait/io/table/sql/handler和wait/lock/table/sql/handler,暗中认可开启。

EVENT_NAME: statement/sql/select

套接字instruments具有wait/io/socket/sql/socket_type方式的称号,如下:

属性事件总计表在setup_consumers表中只受控于”global_instrumentation”配置项,相当于说壹旦”global_instrumentation”配置项关闭,全数的计算表的总计条目都不履行总结(计算列值为0);

·socket_summary_by_event_name:针对每一个socket I/O
instruments,这个socket操作相关的操作次数、时间和出殡和埋葬接收字节消息由wait/io/socket/*
instruments产生(那里的socket是指的脚下活跃的接连创立的socket实例)

EVENT_NAME: stage/sql/After create

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

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

*
已到位的守候事件将助长到events_waits_history和events_waits_history_long表中

OBJECT_NAME: ps_setup_enable_consumer

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

*
尽管贰个线程未有打开采集功效,不过内部存款和储蓄器相关的instruments启用了,则该内部存款和储蓄器释放的操作会被监督到,总结数据会发生改变,那也是前面提到的干什么反复在运行时修改memory
instruments大概引致总括数据为负数的因由

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

AVG _TIMER_WAIT: 0

performance_schema还总结后台线程和不能印证用户的连天,对于那个连接总括行消息,USE中华V和HOST列值为NULL。

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

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

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

图片 1

COUNT_STAR: 7

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

performance_schema把阶段事件总括表也遵循与等待事件计算表类似的规则举办分类聚合,阶段事件也有一对是默许禁止使用的,1部分是开启的,阶段事件总结表包括如下几张表:

·TOTAL_CONNECTIONS:某帐号的总连接数(新增添1个一而再累计三个,不会像当前连接数那样连接断开会收缩)。

USER: NULL

COUNT_READ_NORMAL: 0

* 注意:要是在server运营之后再修改memory
instruments,大概会导致由于丢失以前的分配操作数据而致使在放出之后内部存款和储蓄器计算新闻出现负值,所以不提议在运维时1再开关memory
instruments,若是有内部存款和储蓄器事件总结须要,提出在server运维以前就在my.cnf中配置好内需计算的轩然大波采访

| qfsys |10.10. 20.15| 1 |1|

MIN _TIMER_WAIT: 0

·依傍于连接表中国国投息的summary表在对那个连接表执行truncate时会同时被隐式地执行truncate,performance_schema维护着根据accounts,hosts或users计算种种风浪总结表。这几个表在名称包涵:_summary_by_account,_summary_by_host,*_summary_by_user

SUM_xxx:针对events_statements_*事件记录表中相应的xxx列实行总计。例如:语句总计表中的SUM_LOCK_TIME和SUM_ERRORS列对events_statements_current事件记录表中LOCK_TIME和EEnclaveRO本田CR-VS列实行总括

admin@localhost : performance_schema 09 :34:49> select * from
accounts;

HOST: localhost

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

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

users表字段含义如下:

| events_stages_summary_by_user_by_event_name |

·当连接终止时,在socket_instances表中对应的连接音讯行被删去。

*
SUM_NUMBER_OF_BYTES_ALLOC和SUM_NUMBER_OF_BYTES_FREE列重置与COUNT_ALLOC和COUNT_FREE列重置类似

·SUM_xxx:其余的SUM_xxx发轫的列与语句总括表中的新闻1致,语句总结表后续章节会详细介绍。

COUNT_STAR: 7

3rows inset ( 0. 00sec)

1 row in set (0.00 sec)

AVG_TIMER_WAIT: 24366870

关于events_statements_summary_by_digest表

·CURRENT_CONNECTIONS:某用户的脚下连接数;

*
此外,遵照帐户,主机,用户或线程分类计算的内部存款和储蓄器总结表或memory_summary_global_by_event_name表,假诺在对其借助的accounts、hosts、users表执行truncate时,会隐式对那些内部存款和储蓄器计算表执行truncate语句

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

MAX _TIMER_WAIT: 0

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

*
内存instruments在setup_instruments表中享有memory/code_area/instrument_name格式的名号。但暗许意况下当先半数instruments都被剥夺了,暗许只开启了memory/performance_schema/*开头的instruments

…………

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

·EVENT_NAME:与公事相关联的instruments名称;

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

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

SUM _NO_GOOD _INDEX_USED: 0

mutex_instances.LOCKED_BY_THREAD_ID和rwlock_instances.WRITE_LOCKED_BY_THREAD_ID列对于排查质量瓶颈或死锁难点主要性。

……

2rows inset ( 0. 00sec)

SUM_ERRORS: 2

EVENT_NAME: wait/io/socket/sql/client_connection

# memory_summary_by_thread_by_event_name表

SUM_ERRORS: 0

MIN _TIMER_WAIT: 0

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

AVG _TIMER_WAIT: 0

MySQL允许应用程序引进新的连接属性,可是以下划线(_)开端的习性名称保留供内部使用,应用程序不要成立这种格式的接连属性。以有限支撑内部的连接属性不会与应用程序创造的一连属性相争持。

MAX _TIMER_WAIT: 0

table_handles表是只读的,不能够立异。暗许自动调整表数据行大小,假诺要显式钦点个,可以在server运维在此之前设置系统变量performance_schema_max_table_handles的值。

MAX _TIMER_WAIT: 0

accounts表字段含义如下:

PS:内部存款和储蓄器总结表不含有计时消息,因为内部存款和储蓄器事件不援助时间音信搜集。

file_instances表字段含义如下:

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

品质总结表

USER: NULL

·PRE_ACQUIRE_NOTIFY和POST_RELEASE_NOTIFY状态值停留事件都非常粗大略,当叁个锁处于那一个情形时,那么表示元数据锁子系统正在公告有关的囤积引擎该锁正在履行分配或释。那个情况值在5.柒.1一本子中新增。

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

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

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

SUM_TIMER_WAIT: 412754363625

* SUM_NUMBER_OF_BYTES_FREE:增加N

|wait/synch/rwlock/session/LOCK_srv_session_collection | 31856216
|NULL | 0 |

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

我们先来看望表中记录的计算消息是什么样样子的。

每一个表都有个别的一个或三个分组列,以鲜明什么聚合事件音信(全部表都有EVENT_NAME列,列值与setup_instruments表中NAME列值对应),如下:

| socket_summary_by_instance |

events_statements_summary_by_program:根据每一个存款和储蓄程序(存款和储蓄进度和函数,触发器和事件)的事件名称实行总括的Statement事件

users表包罗连接到MySQL
server的各种用户的总是信息,每个用户壹行。该表将针对用户名作为唯一标识实行总计当前连接数和总连接数,server运转时,表的轻重会自行调整。
要显式设置该表大小,能够在server运维以前设置系统变量performance_schema_users_size的值。该变量设置为0时意味着禁止使用users总括音信。

*
LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED将重置为CU福睿斯RENT_NUMBER_OF_BYTES_USED列值

MIN_TIMER_READ: 15213375

图片 2

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

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

小编们先来探视表中记录的总计音讯是什么体统的。

SUM_SELECT_SCAN: 45

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

注意:那个表只针对工作事件音信实行计算,即包涵且仅包括setup_instruments表中的transaction采集器,每一个事情事件在各样表中的总结记录行数供给看哪样分组(例如:依据用户分组计算的表中,有些许个活泼用户,表中就会有多少条相同采集器的笔录),此外,总括计数器是还是不是见效还索要看transaction采集器是还是不是启用。

1.多少库表级别对象等待事件总括

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

metadata_locks表字段含义如下:

AVG _TIMER_WAIT: 0

COUNT_READ: 1

当二个可被监督的内部存款和储蓄器块N被放走时,performance_schema会对计算表中的如下列举办翻新:

| NAME |OBJECT_INSTANCE_BEGIN | WRITE_LOCKED_BY_THREAD_ID
|READ_LOCKED_BY_COUNT |

THREAD_ID: 47

MIN _TIMER_WAIT: 56688392

从地点表中的以身作则记录新闻中,大家能够看到,同样与等待事件类似,依据用户、主机、用户+主机、线程等纬度实行分组与总括的列,分组和有些日子总括列与等待事件类似,这里不再赘言,但对此语句总括事件,有指向语句对象的附加的总括列,如下:

·当待处理的锁请求超时,会回来错误音信(EENCORE_LOCK_WAIT_TIMEOUT)给请求锁的对话,锁状态从PENDING更新为TIMEOUT;

EVENT_NAME: transaction

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

SUM_SORT_SCAN: 6

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

AVG _TIMER_WAIT: 0

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

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

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

LOW_COUNT_USED: 0

AVG _TIMER_READ: 56688392

1 row in set (0.00 sec)

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

HOST: localhost

·当线程成功锁定(持有)互斥体时:

| events_transactions_summary_global_by_event_name |

四.套接字事件计算

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

·当行消息中CU大切诺基RENT_CONNECTIONS
字段值大于0时,执行truncate语句不会删除这么些行,TOTAL_CONNECTIONS字段值被重置为CU昂CoraRENT_CONNECTIONS字段值;

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

两张表中著录的始末很类似:

* 如果DIGEST =
NULL行的COUNT_STAOdyssey列值占据整个表中全数总括新闻的COUNT_STAGL450列值的百分比大于0%,则意味着存在由于该表限制已满导致壹些语句总括音信不能够归类保存,假设你须求保留全部语句的总结信息,能够在server运维以前调整系统变量performance_schema_digests_size的值,默许大小为200

| Tables_in_performance_schema (%table%summary%) |

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

COUNT_STAR: 1

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

EVENT_NAME: wait/io/file/innodb/innodb_data_file

1 row in set (0.00 sec)

PS:什么是prepare语句?prepare语句其实正是一个预编写翻译语句,先把SQL语句举行编写翻译,且能够设定参数占位符(例如:?符号),然后调用时经过用户变量传入具体的参数值(叫做变量绑定),假设三个口舌须求反复实践而仅仅只是where条件分化,那么使用prepare语句能够大大裁减硬解析的支出,prepare语句有七个步骤,预编写翻译prepare语句,执行prepare语句,释放销毁prepare语句,prepare语句扶助三种协议,前边已经涉嫌过了,binary商谈一般是提要求应用程序的mysql
c api接口形式访问,而文本协议提供给通过客户端连接到mysql
server的方法访问,下边以文件协议的法子访问实行出现说法验证:

Query OK, 377 rows affected (0.00 sec)

*
performance_schema截断领先长度的属性数据,并增添Performance_schema_session_connect_attrs_lost状态变量值,截断2回扩充三次,即该变量表示连接属性被截断了略微次

root@localhost : performance _schema 01:27:32> select * from
events_transactions _summary_global _by_event _name where
SUM_TIMER_WAIT!=0G

·setup_instruments表列出了instruments名称,那些互斥体都带有wait/synch/mutex/前缀;

笔者们先来看看那一个表中著录的总结音信是什么样子的。

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

events_statements_summary_by_account_by_event_name:依据各种帐户和说话事件名称进行总括

hosts表字段含义如下:

EVENT_NAME: stage/sql/After create

session_account_connect_attrs表仅包涵当前线总指挥部是及其相关联的别的连接的连天属性。要查看全体会话的连日属性,请查看session_connect_attrs表。

1 row in set (0.01 sec)

·PHP定义的习性依赖于编写翻译的习性:

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

socket_instances表不允许使用TRUNCATE TABLE语句。

下1篇将为咱们分享
《数据库对象事件总括与品质总括 | performance_schema全方位介绍》
,多谢您的翻阅,大家不见不散!回去博客园,查看愈多

上1篇 《事件计算 |
performance_schema全方位介绍》详细介绍了performance_schema的事件总结表,但这么些总结数据粒度太粗,仅仅依照事件的中国共产党第五次全国代表大会项目+用户、线程等维度进行归类总计,但有时候大家必要从越来越细粒度的维度进行分拣总括,例如:有些表的IO费用多少、锁开支多少、以及用户连接的有的属性总结音信等。此时就须求查阅数据库对象事件总结表与性子总括表了。今日将引导大家一块儿踏上聚讼纷纷第四篇的道路(全系共三个篇章),本期将为我们无微不至授课performance_schema中指标事件总结表与性子总计表。下边,请随行大家1并起来performance_schema系统的读书之旅吧~

1 row in set (0.00 sec)

·execute步骤:语法EXECUTE stmt_name[USING @var_name [,
@var_name] …],示例:execute stmt;
重临执行结果为壹,此时在prepared_statements_instances表中的总计音讯会进展更新;

*
LOW_COUNT_USED:如果CURRENT_COUNT_USED减少一随后是贰个新的最低值,则该字段相应减弱

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

MIN _TIMER_WAIT: 0

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

MIN _TIMER_WAIT: 0

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

# events_transactions_summary_by_account_by_event_name表

柒.锁指标记录表

prepared_statements_instances:依据各样prepare语句实例聚合的总括音讯

| NAME |OBJECT_INSTANCE_BEGIN | LOCKED_BY_THREAD_ID |

HIGH_COUNT_USED: 1

·EXTERNAL_LOCK:在储存引擎级别使用的表锁。有效值为:READ
EXTEGL450NAL、W翼虎ITE EXTERAV4NAL。

Rows matched: 377 Changed: 377 Warnings: 0

OWNER_OBJECT_TYPE: NULL

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

LOCK_TYPE: SHARED_READ

# memory_summary_by_user_by_event_name表

责编:

*
事务事件的采集不思量隔开分离级别,访问格局或机关提交方式

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

全数表的总括列(数值型)都为如下几个:

| socket_summary_by_event_name |

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

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

| memory_summary_by_account_by_event_name |

instance表记录了哪些项指标指标被检查评定。那些表中记录了事件名称(提供收集功用的instruments名称)及其一些解释性的地方新闻(例如:file_instances表中的FILE_NAME文件名称和OPEN_COUNT文件打开次数),instance表首要有如下多少个:

*
CURRENT_NUMBER_OF_BYTES_USED:增加N

相关文章

发表评论

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

网站地图xml地图