|NULL | NULL |41| 45 |

COUNT_STAR: 7

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

     MySQL
Performance-Schema中一共蕴涵5二个表,主要分为几类:Setup表,Instance表,Wait
伊夫nt表,Stage 伊夫nt表Statement
伊芙nt表,Connection表和Summary表。上一篇作品已经主要讲了Setup表,那篇小说将会分别就各种档次的表做详细的描述。

Instance表
   
 instance中要害包括了五张表: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宝马X5_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-POLX570T音信,能够与利用接入起来。
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表首要涵盖2个表,events_waits_current,events_waits_history和events_waits_history_long,通过thread_id+event_id能够唯1显著一条记下。current表记录了当下线程等待的事件,history表记录了各类线程近期静观其变的10个事件,而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奇骏CE:该事件时有发生时的源码文件
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表首要涵盖1个表,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
SOUENCORECE:源码地点
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,每条语句1行,对于嵌套的子查询只怕存款和储蓄进度不会独自列出。event_name形式为statement/sql/*,或statement/com/*
SQL_TEXT:记录SQL语句
DIGEST:对SQL_TEXT做MD5发出的三十八人字符串。若是为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时,第一个表位全表扫描的多寡
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_STARubicon:事件计数
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:第1个语句执行的时间
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
INSECRUISERT总计,相应的还有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中计算包涵53个表,主要分为几类:Setup表,Instance表,Wait
伊芙nt表,Stage Ev…

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

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

*
SUM_NUMBER_OF_BYTES_ALLOC,SUM_NUMBER_OF_BYTES_FREE:已分配和已释放的内部存款和储蓄器块的总字节大小

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

cond_instances表字段含义如下:

内部存款和储蓄器事件instruments中除了performance_schema自己内部存储器分配相关的事件instruments配置暗中认可开启之外,别的的内存事件instruments配置都暗中同意关闭的,且在setup_consumers表中尚无像等待事件、阶段事件、语句事件与作业事件那样的独门安排项。

Wait Event表
     
Wait表首要包罗1个表,events_waits_current,events_waits_history和events_waits_history_long,通过thread_id+event_id能够唯一分明一条记下。current表记录了脚下线程等待的风浪,history表记录了各种线程近期等待的13个事件,而history_long表则记录了不久前有所线程爆发的10000个事件,那里的十和一千0都以能够配备的。那四个表表结构同样,history和history_long表数据都出自current表。current表和history表中恐怕会有重复事件,并且history表中的事件都以瓜熟蒂落了的,未有结束的轩然大波不会加盟到history表中。
THREAD_ID:线程ID
EVENT_ID:当前线程的轩然大波ID,和THREAD_ID组成1个Primary
Key。
END_EVENT_ID:当事件早先时,那1列被设置为NULL。当事件甘休时,再次创下新为当下的事件ID。
SOU大切诺基CE:该事件发生时的源码文件
TIMER_START, TIMER_END,
TIMER_WAIT:事件始于/截至和等候的岁月,单位为阿秒(picoseconds)

当客户端与server端建立连接时,performance_schema使用符合各类表的唯壹标识值来规定每一个连接表中怎么样开始展览记录。借使不够对应标识值的行,则新添加壹行。然后,performance_schema会扩展该行中的CU猎豹CS6RENT_CONNECTIONS和TOTAL_CONNECTIONS列值。

5rows inset ( 0. 00sec)

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

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

# events_stages_summary_global_by_event_name表

(9).socket-summaries表
socket_summary_by_instance
socket_summary_by_event_name

1row inset ( 0. 00sec)

AVG_TIMER_WAIT: 4426693000

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福睿斯:事件计数
SUM_TIMER_WAIT:总的等待时间
MIN_TIMER_WAIT:最小等待时间
MAX_TIMER_WAIT:最大等待时间
AVG_TIMER_WAIT:平均等待时间

performance_schema通过如下表来记录相关的锁消息:

* CURRENT_COUNT_USED:减少1

(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

表字段含义与session_account_connect_attrs表相同,不过该表是保留全部连接的接连属性表。

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

(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

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

除此以外,遵照帐户、主机、用户、线程聚合的各样等待事件总计表只怕events_waits_summary_global_by_event_name表,假若依靠的连接表(accounts、hosts、users表)执行truncate时,那么正视的这个表中的总结数据也会同时被隐式truncate

(3)mutex_instances:互斥同步对象实例
表中记录了系统中选择互斥量对象的兼具记录,当中name为:wait/synch/mutex/*。比如打开文件的互斥量:wait/synch/mutex/mysys/THTiguan_LOCK_open。LOCKED_BY_THREAD_ID呈现哪个线程正持有mutex,若未有线程持有,则为NULL。

OWNER_EVENT_ID: 54

必赢亚洲565net,……

Stage Event表 

metadata_locks表字段含义如下:

EVENT_NAME: stage/sql/After create

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

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

SUM _NUMBER_OF _BYTES_ALLOC: 3296

     MySQL
Performance-Schema中总结包涵5伍个表,首要分为几类:Setup表,Instance表,Wait
伊芙nt表,Stage 伊芙nt表Statement
伊芙nt表,Connection表和Summary表。上一篇文章已经重要讲了Setup表,那篇作品将会分别就每种类型的表做详细的叙说。

套接字事件计算了套接字的读写调用次数和发送接收字节计数音讯,socket事件instruments暗中同意关闭,在setup_consumers表中无具体的相应配置,包含如下两张表:

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

     
 Stage表主要涵盖二个表,events_stages_current,events_stages_history和events_stages_history_long,通过thread_id+event_id可以唯壹明确一条记下。表中记录了近年来线程所处的施行阶段,由于能够精晓各种阶段的实施时间,因而通过stage表能够博得SQL在每种阶段消耗的光阴。

MIN _TIMER_WAIT: 56688392

笔者们先来看看这么些表中著录的总计新闻是什么样样子的。

(5)socket_instances:活跃会话对象实例
表中记录了thread_id,socket_id,ip和port,其余表能够透过thread_id与socket_instance实行关联,获取IP-POHighlanderT消息,能够与使用接入起来。
event_name首要涵盖3类:
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

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

SUM _TIMER_READ_WRITE: 8592136000

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生出的三12人字符串。要是为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时,第3个表选拔range格局扫描的多寡
SELECT_SCAN:join时,第7个表位全表扫描的数目
SORT_ROWS:排序的记录数据
NESTING_EVENT_ID,NESTING_EVENT_TYPE,保留字段,为NULL。

14 rows inset (0.01 sec)

AVG _TIMER_WAIT: 0

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

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

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

| HOST |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |

对此内存总括表中的低水位预计值,在memory_summary_global_by_event_name表中一旦内部存款和储蓄器全体权在线程之间传输,则该猜测值只怕为负数

THREAD_ID:线程ID
EVENT_ID:事件ID
END_EVENT_ID:刚甘休的事件ID
SOU福特ExplorerCE:源码地点
TIMER_START, TIMER_END,
TIMER_WAIT:事件起始/结束和等候的日子,单位为阿秒(picoseconds)
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT,
STAGE, WAIT)

·POSportageT:TCP/IP端口号,取值范围为0〜6553伍;

events_statements_summary_by_program:依照每一种存款和储蓄程序(存款和储蓄进程和函数,触发器和事件)的风浪名称举办总结的Statement事件

(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

SUM_LOCK_TIME: 0

| 温馨提醒

其它表
performance_timers:
系统接济的总计时间单位
threads:
监视服务端的当前运营的线程

accounts表字段含义如下:

*
LOW_COUNT_USED和HIGH_COUNT_USED将重置为CU陆风X八RENT_COUNT_USED列值

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

*
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操作未有字节计数音讯。

COUNT_STAR: 11

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

SUM _TIMER_WAIT: 56688392

root@localhost : performance _schema 11:56:02> select * from
memory_summary _global_by _event_name where COUNT_ALLOC!=0 limit
1G

Connection表
   
 Connection表记录了客户端的新闻,主要总结三张表:users,hosts和account表,accounts蕴涵hosts和users的音讯。
USER:用户名
HOST:用户的IP

INDEX_NAME: PRIMARY

COUNT_ALLOC: 193

events_stages_summary_by_account_by_event_name
events_stages_summary_by_user_by_event_name
events_stages_summary_by_host_by_event_name

(2)session_connect_attrs表

SUM_ERRORS: 2

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)

·已给予的锁(呈现怎么会话拥有当前元数据锁);

COUNT_STAR: 0

(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_必赢亚洲366.net,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奥迪Q7T总计,相应的还有DELETE和UPDATE总计。

·LOCKED_BY_THREAD_ID:当三个线程当前颇具3个排斥锁定时,LOCKED_BY_THREAD_ID列显示全体线程的THREAD_ID,如若未有被其它线程持有,则该列值为NULL。

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

prepared_statements_instances表字段含义如下:

内部存款和储蓄器总结表允许行使TRUNCATE
TABLE语句。使用truncate语句时有如下行为:

大家先来看望表中著录的总计消息是怎样子的。

THREAD_ID: 47

users表包蕴连接到MySQL
server的各种用户的延续消息,每一种用户1行。该表将对准用户名作为唯一标识进行总结当前连接数和总连接数,server运转时,表的大小会自行调整。
要显式设置该表大小,能够在server运营以前设置系统变量performance_schema_users_size的值。该变量设置为0时意味着禁止使用users总括音信。

| events_transactions_summary_global_by_event_name |

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

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

·PS:cond_instances表不容许利用TRUNCATE TABLE语句。

AVG _TIMER_READ_WRITE: 1432022000

(2)file_instances表

5rows inset ( 0. 00sec)

|4| _pid |3766| 2 |

HOST: localhost

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

EVENT_NAME: memory/innodb/fil0fil

……

* CURRENT_COUNT_USED:增加1

*
如果log_error_verbosity系统变量设置值超越1,则performance_schema还会将错误新闻写入错误日志:

* SUM_NUMBER_OF_BYTES_FREE:增加N

上面对这么些表分别展开验证。

MIN _TIMER_WAIT: 0

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

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

*
FEDERATED存款和储蓄引擎连接的program_name属性值被定义为mysqld、定义了_client_role属性,值为federated_storage

对此较高级其余集纳(全局,按帐户,按用户,按主机)总结表中,低水位和高水位适用于如下规则

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

1 row in set (0.00 sec)

OBJECT_TYPE: TABLE

| Tables_in_performance_schema (%events_transactions_summary%) |

1 row in set (0.00 sec)

AVG _TIMER_WAIT: 0

AVG _TIMER_WAIT: 56688392

如果setup_consumers配置表中statements_digest
consumers启用,则在说话执行到位时,将会把讲话文本实行md⑤ hash计算之后
再发送到events_statements_summary_by_digest表中。分组列基于该语句的DIGEST列值(md5hash值)

* _pid:客户端进程ID

COUNT_STAR: 7

·
COUNT_REPREPARE:该行音讯对应的prepare语句在内部被另行编写翻译的次数,重新编写翻译prepare语句之后,以前的相干总结消息就不可用了,因为那几个计算音讯是作为言语执行的1有的被集结到表中的,而不是单独维护的。

| events_waits_summary_global_by_event_name |

3rows inset ( 0. 00sec)

COUNT_FREE: 103

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

1 row in set (0.00 sec)

我们先来看望表中著录的总计消息是哪些样子的。

EVENT_NAME: stage/sql/After create

·TOTAL_CONNECTIONS:某用户的总连接数。

| events_statements_summary_by_host_by_event_name |

*
COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_W凯雷德ITE:那么些列总结了富有文件写操作,包括FPUTS,FPUTC,FP奇骏INTF,VFPXC90INTF,FW宝马7系ITE和PW奥迪Q7ITE系统调用,还带有了这一个I/O操作的数码字节数

# events_transactions_summary_by_user_by_event_name表

·socket_instances:活跃接连实例。

*
通常,truncate操作会重置总计音信的标准数据(即清空以前的数码),但不会修改当前server的内部存储器分配等情事。也等于说,truncate内部存款和储蓄器计算表不会释放已分配内部存款和储蓄器

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

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

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

必赢亚洲366.net 1

cond_instances表列出了server执行condition instruments
时performance_schema所见的享有condition,condition表示在代码中一定事件时有爆发时的一块儿时限信号机制,使得等待该标准的线程在该condition满足条件时能够回复工作。

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

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

MIN_TIMER_WAIT: 72775000

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

events_statements_summary_by_program表有谈得来额外的总括列:

| file_summary_by_event_name |

当一个可被监督的内部存款和储蓄器块N被放飞时,performance_schema会对总计表中的如下列进行立异:

笔者们先来探视表中著录的计算新闻是怎么样体统的。

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

·metadata_locks:元数据锁的保有和呼吁记录;

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

1 rows in set (0.00 sec)

OBJECT_TYPE: PROCEDURE

MIN _TIMER_READ: 56688392

events_statements_summary_by_digest:根据每种库级别对象和言语事件的原始语句文本总结值(md五hash字符串)实行总括,该总结值是基于事件的原始语句文本举行不难(原始语句转换为原则语句),每行数据中的相关数值字段是具备同样总结值的计算结果。

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

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

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

| events_transactions_summary_by_host_by_event_name |

·INTERNAL_LOCK:在SQL级别使用的表锁。有效值为:READ、READ WITH
SHARED LOCKS、READ HIGH PLX570IOCRUISERITY、READ NO INSEQX56T、WTiggoITE ALLOW
WHighlanderITE、W昂CoraITE CONCUXC90RENT INSE奥迪Q7T、W路虎极光ITE LOW
P中华VIOLANDITY、WLacrosseITE。有关那么些锁类型的详细音讯,请参阅include/thr_lock.h源文件;

EVENT_NAME: transaction

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

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

MAX_TIMER_READ: 0

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

…………

内部存款和储蓄器事件在setup_consumers表中未有独自的配备项,且memory/performance_schema/*
instruments私下认可启用,无法在运维时或运维时关闭。performance_schema相关的内部存款和储蓄器计算音信只保存在memory_summary_global_by_event_name表中,不会保存在依据帐户,主机,用户或线程分类聚合的内部存款和储蓄器总结表中。

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

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

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

USER: NULL

接贰连3属性记录在如下两张表中:

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

OBJECT_SCHEMA: xiaoboluo

*
要是三个线程开启了搜集功效,但是内部存款和储蓄器相关的instruments未有启用,则该内部存款和储蓄器释放操作不会被监察和控制到,总结数据也不会产生变动

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

MIN _TIMER_WAIT: 0

MAX_TIMER_READ: 9498247500

SUM_ROWS_AFFECTED: 0

3rows inset ( 0. 00sec)

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

这一个表列出了等候事件中的sync子类事件相关的指标、文件、连接。当中wait
sync相关的指标类型有三种:cond、mutex、rwlock。各样实例表都有一个EVENT_NAME或NAME列,用于浮现与每行记录相关联的instruments名称。instruments名称或然有所四个部分并摇身①变层次结构,详见”配置详解
| performance_schema全方位介绍”。

SUM _TIMER_WAIT: 0

MIN_TIMER_READ: 15213375

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

EVENT_NAME: wait/io/file/innodb/innodb_data_file

| 内存事件总括表

| 3 |_client_name | libmysql |1|

EVENT_NAME: transaction

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

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

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

SUM _TIMER_WAIT: 0

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

SUM _SORT_MERGE_PASSES: 0

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

# events_waits_summary_by_thread_by_event_name表

·prepare步骤:语法PREPARE stmt_name FROM
preparable_stmt,示例:PREPARE stmt FROM’SELECT 一’;
执行了该语句之后,在prepared_statements_instances表中就能够查询到3个prepare示例对象了;

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

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

MAX _TIMER_WAIT: 0

·当在此以前请求无法马上收获的锁在那之后被予以时,其锁音讯行状态更新为GRANTED;

*
要是给定语句的总括信息行在events_statements_summary_by_digest表中绝非已存在行,且events_statements_summary_by_digest表空间限制已满的情事下,则该语句的计算消息将助长到DIGEST
列值为
NULL的特种“catch-all”行,假使该越发行不设有则新插入一行,FI冠道ST_SEEN和LAST_SEEN列为当前岁月。若是该尤其行已存在则更新该行的新闻,LAST_SEEN为眼今日子

AVG_TIMER_WAIT: 24366870

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

咱俩先来探望表中记录的计算新闻是怎么着体统的。

内部存款和储蓄器大小计算音讯有助于掌握当前server的内部存款和储蓄器消耗,以便及时开始展览内部存款和储蓄器调整。内部存储器相关操作计数有助于掌握当前server的内部存款和储蓄器分配器的完好压力,及时领悟server质量数据。例如:分配单个字节一百万次与单次分配一百万个字节的性情成本是区别的,通过跟踪内部存款和储蓄器分配器分配的内部存款和储蓄器大小和分红次数就能够精晓两岸的歧异。

(1)metadata_locks表

1 row in set (0.00 sec)

COUNT_READ: 1

SUM _TIMER_WAIT: 8649707000

SUM _NUMBER_OF _BYTES_READ: 0

# events_transactions_summary_by_host_by_event_name表

mutex_instances表不相同意使用TRUNCATE TABLE语句。

*
LOW_COUNT_USED和LOW_NUMBER_OF_BYTES_USED是较低的低水位估摸值。performance_schema输出的低水位值能够保险总结表中的内部存款和储蓄器分配次数和内存小于或等于当前server中真实的内部存储器分配值

·LOCK_STATUS:元数据锁子系统的锁状态。有效值为:PENDING、GRANTED、VICTIM、TIMEOUT、KILLED、PRE_ACQUIRE_NOTIFY、POST_RELEASE_NOTIFY。performance_schema依照分化的级差更改锁状态为那个值;

*
CURRENT_NUMBER_OF_BYTES_USED:增加N

…………

对此遵照帐户、主机、用户聚集的总结表,truncate语句会删除已初步连接的帐户,主机或用户对应的行,并将其余有连日的行的计算列值重置为零(实地衡量跟未依照帐号、主机、用户聚集的总计表1样,只会被重置不会被删除)。

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

# memory_summary_global_by_event_name表

·IP:客户端IP地址。该值能够是IPv4或IPv陆地址,也得以是四壁萧条,表示那是二个Unix套接字文件接二连三;

属性事件总计表中的某部instruments是或不是推行计算,重视于在setup_instruments表中的配置项是还是不是打开;

file_instances表列出执行文书I/O
instruments时performance_schema所见的保有文件。
假使磁盘上的文本未有打开,则不会在file_instances中著录。当文件从磁盘中删去时,它也会从file_instances表中剔除相应的记录。

COUNT_STAR: 7

| NULL |41| 45 |

| 事务事件总计表

OBJECT_NAME: test

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

AVG_TIMER_READ: 530278875

MAX _TIMER_WAIT: 0

SUM_ROWS_AFFECTED: 0

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

# table_io_waits_summary_by_index_usage表

关于events_statements_summary_by_digest表

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

MIN _TIMER_WAIT: 0

原题目:数据库对象事件与特性总计 | performance_schema全方位介绍(伍)

SUM _CREATED_TMP _DISK_TABLES: 3

OBJECT_SCHEMA: xiaoboluo

MIN _TIMER_READ_WRITE: 87193000

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

FIRST_SEEN: 2018-05-19 22:33:50

COUNT_STAR: 802

业务聚合总括规则

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

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

·CURRENT_CONNECTIONS:某帐号的此时此刻连接数;

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

1 row in set (0.00 sec)

*
事务事件的搜集不考虑隔离级别,访问方式或自行提交形式

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

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

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

AVG _TIMER_WAIT: 1235672000

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

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

该表的分组列与table_io_waits_summary_by_table表相同

SUM_SORT_SCAN: 6

OBJECT_TYPE: TABLE

performance_schema把语句事件总括表也根据与等待事件计算表类似的规则实行分拣总结,语句事件instruments暗中同意全体敞开,所以,语句事件总结表中暗许会记录全数的语句事件总括音信,言语事件总计表包涵如下几张表:

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

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

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

SUM_SELECT_RANGE: 0

三.文本I/O事件总括

# memory_summary_by_account_by_event_name表

文件I/O事件总计表只记录等待事件中的IO事件(不分包table和socket子系列),文件I/O事件instruments私下认可开启,在setup_consumers表中无具体的相应配置。它包蕴如下两张表:

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

·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读取数据的操作)相关的次数、时间、接收字节数等消息

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

6 rows inset (0.00 sec)

COUNT_STAR: 0

两张表中记录的故事情节很接近:

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

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

……

(1) session_account_connect_attrs表

HOST: localhost

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

  • SUM_NUMBER_OF_BYTES_FREE

OBJECT _INSTANCE_BEGIN: 139968890586816

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

SUM_TIMER_EXECUTE: 0

5rows inset ( 0. 00sec)

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

COUNT_STAR: 0

session_account_connect_attrs表不允许利用TRUNCATE TABLE语句。

SUM _TIMER_WAIT: 0

上一篇 《事件总计 |
performance_schema全方位介绍》详细介绍了performance_schema的轩然大波总计表,但这么些总计数据粒度太粗,仅仅根据事件的5大连串+用户、线程等维度举行分拣总计,但有时候大家要求从越来越细粒度的维度举办分类计算,例如:有个别表的IO花费多少、锁花费多少、以及用户连接的1部分天性总括新闻等。此时就要求查阅数据库对象事件总括表与品质计算表了。明天将指点我们共同踏上延续串第陆篇的征途(全系共八个篇章),本期将为大家无微不至授课performance_schema中指标事件总括表与品质总括表。下边,请随行我们1块初步performance_schema系统的学习之旅吧~

# events_stages_summary_by_account_by_event_name表

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

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

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

1row inset ( 0. 00sec)

MIN_TIMER_WAIT: 1905016

PS:内部存款和储蓄器总结表不带有计时消息,因为内部存款和储蓄器事件不帮忙时间消息征集。

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

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

SUM_ROWS_SENT: 0

HOST: localhost

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

MIN_TIMER_WAIT:给定计时事件的小不点儿等待时间

套接字instruments具有wait/io/socket/sql/socket_type格局的称呼,如下:

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

SUM_TIMER_WAIT: 412754363625

THREAD_ID: 1

·NAME:与互斥体关联的instruments名称;

MIN _TIMER_WAIT: 0

咱俩先来看看表中著录的计算消息是怎么着样子的。

COUNT_STAR: 55

COUNT_REPREPARE: 0

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

注意:rwlock_instances表中的消息只好查看到具备写锁的线程ID,但是不可能查看到全体读锁的线程ID,因为写锁W福睿斯ITE_LOCKED_BY_THREAD_ID字段记录的是线程ID,读锁唯有二个READ_LOCKED_BY_COUNT字段来记录读锁被有些个线程持有。

HIGH_COUNT_USED: 1

6.instance 统计表

……

MAX_TIMER_WAIT: 9498247500

从上边表中的言传身教记录新闻中,大家得以见到,同样与等待事件类似,根据用户、主机、用户+主机、线程等纬度举行分组与总括的列,那一个列的意义与等待事件类似,那里不再赘述。

小编们先来探视表中著录的计算消息是什么体统的。

1 row in set (0.00 sec)

1 row in set (0.00 sec)

| events_statements_summary_by_thread_by_event_name |

| 4 |_client_name | libmysql |1|

注意:这几个表只针对工作事件新闻进行总结,即包罗且仅包括setup_instruments表中的transaction采集器,每个事情事件在各样表中的计算记录行数要求看怎么着分组(例如:遵照用户分组总计的表中,有些许个活泼用户,表中就会有多少条相同采集器的笔录),此外,计揣摸数器是否见效还需求看transaction采集器是还是不是启用。

·OBJECT_NAME:instruments对象的称呼,表级别对象;

# 如若需求计算内部存款和储蓄器事件新闻,要求敞开内部存款和储蓄器事件采集器

·各种文件I/O总结表都有二个或多少个分组列,以声明如何计算这个事件消息。那几个表中的事件名称来自setup_instruments表中的name字段:

HOST: localhost

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

1 row in set (0.00 sec)