数据库对象事件与本性计算 | performance_schema全方位介绍(伍)

table_handles表字段含义如下:

| events_transactions_summary_by_thread_by_event_name |

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

     MySQL
Performance-Schema中累计蕴含5五个表,首要分为几类:Setup表,Instance表,Wait
伊芙nt表,Stage 伊夫nt表Statement
伊芙nt表,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/THRubicon_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宝马X伍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表记录了每种线程近来守候的11个事件,而history_long表则记录了不久前具备线程发生的一千0个事件,那里的十和10000都以足以安顿的。那七个表表结构同样,history和history_long表数据都出自current表。current表和history表中可能会有再一次事件,并且history表中的事件都以达成了的,未有终止的风云不会进入到history表中。
THREAD_ID:线程ID
EVENT_ID:当前线程的风云ID,和THREAD_ID组成2个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普拉多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,每条语句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表记录了客户端的音信,主要回顾3张表:users,hosts和account表,accounts包蕴hosts和users的音信。
USER:用户名
HOST:用户的IP

Summary表
   
Summary表聚集了逐1维度的计算消息包罗表维度,索引维度,会话维度,语句维度和锁维度的计算音讯。
(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_STATiguan:事件计数
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:最终七个言语执行的时辰
现象:用于总计某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
INSESportageT总结,相应的还有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中累计包蕴伍十三个表,首要分为几类:Setup表,Instance表,Wait
伊芙nt表,Stage Ev…

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

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

HOST: localhost

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

| 4 |_client_name | libmysql |1|

AVG_TIMER_WAIT: 4426693000

events_statements_summary_by_account_by_event_name
events_statements_summary_by_user_by_event_name
events_statements_summary_by_host_by_event_name

·LOCK_DURATION:来自元数据锁子系统中的锁定时间。有效值为:STATEMENT、TRANSACTION、EXPLICIT,STATEMENT和TRANSACTION值分别表示在讲话或业务甘休时会释放的锁。
EXPLICIT值表示能够在言语或工作截止时被会保留,供给显式释放的锁,例如:使用FLUSH
TABLES WITH READ LOCK获取的全局锁;

当贰个可被监控的内部存储器块N被分配时,performance_schema会对内存总计表中的如下列实行立异:

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

| NULL |41| 45 |

AVG _TIMER_WAIT: 0

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

# file_summary_by_instance表

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

(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

* file_summary_by_event_name表:按照EVENT_NAME列进行分组 ;

MIN _TIMER_WAIT: 0

     
 Stage表首要涵盖二个表,events_stages_current,events_stages_history和events_stages_history_long,通过thread_id+event_id能够唯壹鲜明一条记下。表中记录了脚下线程所处的推行阶段,由于能够知道种种阶段的执行时间,因而通过stage表可以拿走SQL在每种阶段消耗的岁月。

OBJECT_NAME: test

属性事件总结表中的某部instruments是还是不是执行总括,注重于在setup_instruments表中的配置项是否打开;

THREAD_ID:线程ID
EVENT_ID:事件ID
END_EVENT_ID:刚甘休的风浪ID
SOUTiggoCE:源码地方
TIMER_START, TIMER_END,
TIMER_WAIT:事件始于/甘休和等候的时间,单位为阿秒(picoseconds)
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT,
STAGE, WAIT)

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

1 row in set (0.00 sec)

(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总计。

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

SUM _TIMER_READ_WRITE: 8592136000

events_stages_summary_by_account_by_event_name
events_stages_summary_by_user_by_event_name
events_stages_summary_by_host_by_event_name

OBJECT _INSTANCE_BEGIN: 139968890586816

| events_waits_summary_by_host_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 rows in set (0.00 sec)

当某给定对象被实施时,其相应的总结消息将记录在events_statements_summary_by_program表中并开始展览计算。

Stage Event表 

·表面锁对应存款和储蓄引擎层中的锁。通过调用handler::external_lock()函数来完成。(官方手册上说有2个OPERATION列来区分锁类型,该列有效值为:read
external、write external。但在该表的定义上并不曾见到该字段)

工作聚合总结规则

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

·当3个线程正在等候某事产生时,condition
NAME列展现了线程正在守候什么condition(但该表中并未其他列来突显对应哪个线程等消息),但是当前还从未直接的秘籍来判断某些线程或少数线程会招致condition发生变更。

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

(9).socket-summaries表
socket_summary_by_instance
socket_summary_by_event_name

TIMER_PREPARE: 896167000

LOW _NUMBER_OF _BYTES_USED: 0

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)

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

MAX _TIMER_WAIT: 0

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

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

events_statements_summary_by_digest表有投机额外的计算列:

(5)socket_instances:活跃会话对象实例
表中记录了thread_id,socket_id,ip和port,其余表能够因而thread_id与socket_instance举行关联,获取IP-POEscortT音讯,可以与应用接入起来。
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

当客户端断开连接时,performance_schema将压缩对应连接的行中的CU凯雷德RENT_CONNECTIONS列,保留TOTAL_CONNECTIONS列值。

MAX _TIMER_WAIT: 0

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

EVENT_NAME: wait/io/socket/sql/client_connection

EVENT_NAME: stage/sql/After create

(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

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

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

Wait Event表
     
Wait表重要含有二个表,events_waits_current,events_waits_history和events_waits_history_long,通过thread_id+event_id能够唯1分明一条记下。current表记录了当前线程等待的事件,history表记录了各种线程近日守候的11个事件,而history_long表则记录了近日怀有线程暴发的一千0个事件,那里的拾和一千0都以足以安顿的。那多少个表表结构同样,history和history_long表数据都来源于current表。current表和history表中只怕会有双重事件,并且history表中的事件都以成就了的,未有截至的风云不会插手到history表中。
THREAD_ID:线程ID
EVENT_ID:当前线程的风云ID,和THREAD_ID组成2个Primary
Key。
END_EVENT_ID:当事件起始时,那1列棉被服装置为NULL。当事件甘休时,再立异为最近的轩然大波ID。
SOUTiguanCE:该事件时有发生时的源码文件
TIMER_START, TIMER_END,
TIMER_WAIT:事件初始/甘休和等待的年月,单位为阿秒(picoseconds)

图片 1

SUM _SORT_MERGE_PASSES: 0

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

[Warning] Connection attributes oflength N were truncated

events_statements_summary_by_thread_by_event_name:根据每种线程和事件名称进行总结的Statement事件

(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的通病是,只可以记录持有写锁的线程,对于读锁则不能。

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

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

Connection表
   
 Connection表记录了客户端的新闻,首要不外乎三张表:users,hosts和account表,accounts包含hosts和users的信息。
USER:用户名
HOST:用户的IP

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

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

其它表
performance_timers:
系统协理的计算时间单位
threads:
监视服务端的此时此刻运作的线程

users表字段含义如下:

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

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

(1)cond_instances表

MAX _TIMER_WAIT: 0

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做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时,第3个表位全表扫描的数额
SORT_ROWS:排序的记录数据
NESTING_EVENT_ID,NESTING_EVENT_TYPE,保留字段,为NULL。

· 对于经过Unix
domain套接字(client_connection)的客户端连接,端口为0,IP为空白;

在上壹篇《事件记录 |
performance_schema全方位介绍”》中,大家详细介绍了performance_schema的轩然大波记录表,恭喜大家在攻读performance_schema的途高度过了七个最困苦的时代。今后,相信我们早就相比清楚什么是事件了,但偶尔大家不供给了然每时每刻发生的每一条事件记录新闻,
例如:大家愿意领悟数据库运营以来一段时间的轩然大波总括数据,那个时候就须要查阅事件总结表了。明日将带领我们壹同踏上层层第伍篇的征途(全系共玖个篇章),在那一期里,大家将为大家无微不至授课performance_schema中事件总结表。总计事件表分为四个连串,分别为等候事件、阶段事件、语句事件、事务事件、内存事件。上面,请随行大家壹起初始performance_schema系统的上学之旅吧。

·server只接受的连接属性数据的计算大小限制为64KB。要是客户端尝试发送超过64KB(正好是1个表全数字段定义长度的总限制长度)的属性数据,则server将不容该连接;

HOST: NULL

SUM _TIMER_READ: 56688392

events_statements_summary_by_program表有协调额外的总括列:

(2)table_handles表

MIN _TIMER_WAIT: 57571000

对此利用C
API运转的连天,libmysqlclient库对客户端上的客户端面连接属性数据的总结大小的定点长度限制为64KB:超出限制时调用mysql_options()函数会报C奥迪Q7_INVALID_PARAMETER_NO错误。其余MySQL连接器恐怕会设置自个儿的客户端面包车型客车连日属性长度限制。

MIN _TIMER_WAIT: 0

·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和LOW_NUMBER_OF_BYTES_USED是较低的低水位猜想值。performance_schema输出的低水位值能够确认保障总括表中的内部存款和储蓄器分配次数和内存小于或等于当前server中真正的内部存款和储蓄器分配值

·对于TCP/IP
server套接字(server_tcpip_socket)的server端监听器,端口始终为主端口(例如330陆),IP始终为0.0.0.0;

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

从上面表中的记录消息我们得以看看(与公事I/O事件计算类似,两张表也各自依照socket事件类型总计与服从socket
instance进行总结)

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

·当已给予的锁或挂起的锁请求被杀掉时,其锁状态从GRANTED或PENDING更新为KILLED;

SUM_SELECT_RANGE: 0

·HOST:某总是的客户端主机名。借使是八个里边线程创造的接二连三,可能是无能为力印证的用户成立的连天,则该字段为NULL;

MAX _TIMER_WAIT: 0

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

……

COUNT_READ: 577

* 注意:借使在server运转之后再修改memory
instruments,可能会导致由于丢失从前的分红操作数据而招致在刑释之后内部存款和储蓄器总括音信出现负值,所以不提出在运行时壹再开关memory
instruments,要是有内存事件计算须要,建议在server运转此前就在my.cnf中配备好内需总计的事件采访

OBJECT_SCHEMA: xiaoboluo

MIN _TIMER_WAIT: 0

EVENT_NAME: wait/io/file/innodb/innodb_data_file

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

SUM_ROWS_AFFECTED: 0

SUM_WARNINGS: 0

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

THREAD_ID: 47

·1经是插入操作,则不能够运用到目录,此时的总结值是依据INDEX_NAME =
NULL计算的

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

performance_schema通过table_handles表记录表锁新闻,以对当下各样打开的表所持有的表锁进行追踪记录。table_handles输出表锁instruments采集的始末。那几个新闻显示server中已开辟了哪些表,锁定格局是怎么以及被哪些会话持有。

# events_transactions_summary_by_account_by_event_name表

AVG_TIMER_EXECUTE: 0

# events_stages_summary_by_host_by_event_name表

1. 接连新闻总结表

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

hosts表包涵客户端连接到MySQL
server的主机音信,一个主机名对应一行记录,该表针对主机作为唯一标识举行计算当前连接数和总连接数。server运转时,表的轻重缓急会活动调整。
要显式设置该表大小,能够在server运转以前设置系统变量performance_schema_hosts_size的值。假使该变量设置为0,则表示禁止使用hosts表总结音讯。

1 row in set (0.00 sec)

(3)hosts表

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

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

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

PS:socket总计表不会总括空闲事件生成的等候事件新闻,空闲事件的等待新闻是记录在伺机事件总结表中开始展览计算的。

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

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

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

performance_schema还总计后台线程和无法表达用户的总是,对于这个连接总括行音信,USEGL450和HOST列值为NULL。

performance_schema把等待事件总计表依照区别的分组列(不相同纬度)对等候事件有关的数据进行联谊(聚合总括数据列包蕴:事件爆发次数,总等待时间,最小、最大、平均等待时间),注意:等待事件的搜集成效有局地暗许是禁止使用的,要求的时候能够透过setup_instruments和setup_objects表动态开启,等待事件总计表包括如下几张表:

1row inset ( 0. 00sec)

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

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

EVENT_NAME: statement/sql/select

6 rows inset (0.00 sec)

EVENT_NAME: stage/sql/After create

14 rows inset (0.01 sec)

# events_statements_summary_by_account_by_event_name表

SUM_TIMER_WAIT: 412754363625

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

(2)users表

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

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

# events_statements_summary_by_user_by_event_name表

| table_lock_waits_summary_by_table |#
遵照种种表展开计算的表锁等待事件

| 温馨提醒

·COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT:那个列计算全部socket读写操作的次数和时间音讯

……

| admin |1| 1 |

| 事务事件总结表

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

COUNT_STAR: 58

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

咱俩先来看看那么些表中记录的总计音信是什么体统的(由于单行记录较长,那里只列出events_transactions_summary_by_account_by_event_name表中的示例数据,其他表的示范数据省略掉一部分同样字段)。

原标题:数据库对象事件与本性计算 | performance_schema全方位介绍(伍)

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

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

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

应用程序能够动用mysql_options()和mysql_options四()C
API函数在接连时提供一些要传送到server的键值对连日属性。

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

session_account_connect_attrs表仅包罗当前连日及其相关联的其余连接的总是属性。要翻开全部会话的接连属性,请查看session_connect_attrs表。

SUM _TIMER_WAIT: 0

笔者们先来探视表中记录的总计消息是什么体统的。

1 row in set (0.00 sec)

OBJECT _INSTANCE_BEGIN: 2658004160

EVENT_NAME: transaction

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

| events_transactions_summary_by_user_by_event_name |

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

root@localhost : performance _schema 11:02:15> select * from
events_statements _summary_by _host_by _event_name where
COUNT_STAR!=0 limit 1G

(1) session_account_connect_attrs表

SUM _NO_GOOD _INDEX_USED: 0

AVG_TIMER_READ: 530278875

SUM _TIMER_WAIT: 8649707000

·prepare语句解除财富分配:对已检验的prepare语句实例执行COM_STMT_CLOSE或SQLCOM_DEALLOCATE_PREPARE命令,同时将去除prepare_statements_instances表中对应的行音讯。为了防止财富泄漏,请务必在prepare语句不需求利用的时候实施此步骤释放财富。

| events_statements_summary_by_user_by_event_name |

SUM_LOCK_TIME: 0

# memory_summary_by_thread_by_event_name表

该表允许利用TRUNCATE
TABLE语句。只将总结列重置为零,而不是删除行。该表执行truncate时也会隐式触发table_io_waits_summary_by_table表的truncate操作。此外利用DDL语句更改索引结构时,会促成该表的兼具索引总括音讯被重置

……

mutex_instances表字段含义如下:

performance_schema把阶段事件总计表也如约与等待事件总结表类似的规则进行分类聚合,阶段事件也有一对是暗中认可禁止使用的,一部分是打开的,阶段事件总括表包蕴如下几张表:

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

# events_transactions_summary_by_user_by_event_name表

COUNT_STAR: 802

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

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

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

·
COUNT_REPREPARE:该行消息对应的prepare语句在里面被另行编写翻译的次数,重新编写翻译prepare语句之后,从前的相关总结新闻就不可用了,因为那个总结消息是当做言语执行的壹有的被集结到表中的,而不是独立维护的。

| Tables_in_performance_schema (%prepare%) |

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

EVENT_NAME: statement/sql/select

# table_io_waits_summary_by_table表

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张表做一些必需的认证:

MAX _TIMER_WAIT: 0

| 10.10.20.15 |1| 1 |

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

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

# 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本田CR-VITE:这个列总结了独具文件写操作,包罗FPUTS,FPUTC,FPHighlanderINTF,VFP福特ExplorerINTF,FW牧马人ITE和PW猎豹CS6ITE系统调用,还带有了那个I/O操作的数码字节数

* 如果DIGEST =
NULL行的COUNT_STAENCORE列值占据整个表中全体总计新闻的COUNT_STA君越列值的百分比大于0%,则代表存在由于该表限制已满导致有个别语句计算音讯不可能归类保存,假使您须要保留全体语句的总计音讯,能够在server运行此前调整系统变量performance_schema_digests_size的值,默许大小为200

|admin | localhost |1| 1 |

MAX _TIMER_WAIT: 2427645000

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

| events_stages_summary_by_user_by_event_name |

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

HOST: localhost

OBJECT_SCHEMA: xiaoboluo

| events_waits_summary_by_account_by_event_name |

metadata_locks表字段含义如下:

| 导语

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

prepared_statements_instances:依照每种prepare语句实例聚合的总计新闻

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

EVENT_NAME: memory/innodb/fil0fil

OWNER_THREAD_ID: 48

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

MIN _TIMER_READ: 56688392

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

COUNT_READ_NORMAL: 0

PS2:有关存款和储蓄程序监察和控制行为:对于在setup_objects表中启用了instruments的蕴藏程序类型,events_statements_summary_by_program将体贴存款和储蓄程序的总计消息,如下所示:

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

# events_waits_summary_by_host_by_event_name表

·SUM_xxx:其余的SUM_xxx起先的列与语句总计表中的音信相同,语句总计表后续章节会详细介绍。

*
通常,truncate操作会重置总计新闻的基准数据(即清空以前的多少),但不会修改当前server的内部存款和储蓄器分配等景况。也正是说,truncate内部存款和储蓄器总括表不会释放已分配内部存款和储蓄器

MIN_TIMER_READ: 0

*
LOW_COUNT_USED:如果CURRENT_COUNT_USED减少壹自此是二个新的最低值,则该字段相应核减

·USEBMWX伍:某总是的客户端用户名。假若是三个里边线程成立的接连,可能是力不从心印证的用户创造的连接,则该字段为NULL;

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

·OBJECT_SCHEMA:该锁来自于哪个库级其他指标;

DIGEST_TEXT: SELECT @@`version_comment` LIMIT ?

1 row in set (0.00 sec)

SUM_TIMER_WAIT:总结给定计时事件的总等待时间。此值仅针对有计时效应的事件instruments或打开了计时功能事件的instruments,假使某事件的instruments不帮忙计时依旧未有开启计时功用,则该字段为NULL。别的xxx_TIMER_WAIT字段值类似

* _program_name:客户端程序名称

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

3 rows in set (0.00 sec)

USER: root

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

主编:

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

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

·当在此之前请求不可能马上收获的锁在这之后被予以时,其锁新闻行状态更新为GRANTED;

AVG _TIMER_WAIT: 0

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

events_statements_summary_by_digest:依照种种库级别对象和言辞事件的原始语句文本总结值(md5hash字符串)实行总结,该总括值是基于事件的原始语句文本举行简要(原始语句转换为规范语句),每行数据中的相关数值字段是富有同样总结值的总结结果。

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

AVG _TIMER_WAIT: 1235672000

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

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

SUM _NUMBER_OF _BYTES_READ: 0

events_statements_summary_by_user_by_event_name:遵照各类用户名和事件名称实行总括的Statement事件

品质总结表

| events_statements_summary_by_digest |

·SOUHighlanderCE:源文件的称呼,在那之中蕴藏生成事件新闻的检验代码行号;

performance_schema会记录内存使用景况并汇集内部存款和储蓄器使用计算信息,如:使用的内部存款和储蓄器类型(种种缓存,内部缓冲区等)和线程、帐号、用户、主机的有关操作直接实行的内部存款和储蓄器操作。performance_schema从使用的内部存款和储蓄器大小、相关操作数量、高低水位(内部存款和储蓄器2次操作的最大和微小的连带计算值)。

……

AVG _TIMER_WAIT: 0

·rwlock_instances:查看当前rwlock行的有的锁消息(独占锁被哪些线程持有,共享锁被某些个线程持有等)。

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

·当监听套接字检查实验到接二连三时,srever将接连转移给2个由独立线程管理的新套接字。新连接线程的instruments具有client_connection的socket_type值,组成对应的instruments名称;

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

·CURRENT_CONNECTIONS:某主机的当下连接数;

USER: root

MAX_TIMER_READ: 0

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

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

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

file_instances表不容许采用TRUNCATE TABLE语句。

root@localhost : performance _schema 11:43:03> select * from
events_stages _summary_global _by_event_name limit 1G

我们先来看望表中著录的总结音信是什么样样子的。

| events_statements_summary_by_thread_by_event_name |

MAX_TIMER_READ: 9498247500

内部存款和储蓄器大小总计消息有助于掌握当前server的内部存储器消耗,以便及时开始展览内部存款和储蓄器调整。内部存款和储蓄器相关操作计数有助于通晓当前server的内部存款和储蓄器分配器的完整压力,及时掌握server质量数据。例如:分配单个字节一百万次与单次分配一百万个字节的性质费用是分裂的,通过跟踪内部存款和储蓄器分配器分配的内部存款和储蓄器大小和分红次数就能够清楚相互的出入。

COUNT_STAR: 24

| events_statements_summary_by_program |

OBJECT_SCHEMA: xiaoboluo

# events_transactions_summary_by_thread_by_event_name表

| 4 |_client_version | 5.7.18 |3|

EVENT_NAME: stage/sql/After create

友情提示:下文中的总括表中山高校部字段含义与上1篇
《事件计算 | performance_schema全方位介绍》
中关系的总结表字段含义相同,下文中不再赘言。此外,由于部分总结表中的笔录内容过长,限于篇幅会不难部分文件,如有须求请自行设置MySQL
五.七.1一上述版本跟随本文进行同步操作查看。

EVENT_NAME: memory/performance_schema/mutex_instances

admin@localhost : performance _schema 04:55:42> select * from
metadata_locksG;

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

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

* CURRENT_COUNT_USED:减少1

…………

EVENT_NAME: statement/sql/select

…………

SUM _TIMER_WAIT: 0

·file_summary_by_event_name:遵照每个事件名称举办总计的文本IO等待事件

5rows inset ( 0. 00sec)

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

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

| /data/mysqldata1/innodb_ts/ibdata1
|wait/io/file/innodb/innodb_data_file | 3 |

events_statements_summary_by_host_by_event_name:遵照每一种主机名和事件名称进行总计的Statement事件

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

MAX _TIMER_WAIT: 0

mutex_instances表列出了server执行mutex
instruments时performance_schema所见的有着互斥量。互斥是在代码中利用的壹种共同机制,以强制在给定时间内唯有一个线程能够访问一些公共财富。能够认为mutex珍贵着那些集体财富不被轻易抢占。

7rows inset ( 0. 00sec)

这几个连接表都允许使用TRUNCATE TABLE语句:

SUM_TIMER_WAIT: 234614735000

AVG_TIMER_READ: 0

HIGH _NUMBER_OF _BYTES_USED: 32

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

| memory_summary_by_user_by_event_name |

AVG_TIMER_WAIT: 514656000

DIGEST: 4fb483fe710f27d1d06f83573c5ce11c

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

SUM _TIMER_WAIT: 0

依据请求锁的线程数以及所请求的锁的性质,访问形式有:独占格局、共享独占情势、共享情势、大概所请求的锁不能够被整个予以,需求先等待别的线程完结并释放。

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

admin@localhost : performance_schema 02:50:02> select * from
cond_instances limit 1;

THREAD_ID: 46

·THREAD_ID:由server分配的其中线程标识符,各个套接字都由单个线程实行政管理理,由此每一种套接字都足以映射到3个server线程(假使可以映射的话);

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

EVENT_NAME: wait/io/socket/sql/client_connection

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

·COUNT_MISC,SUM_TIMER_MISC,MIN_TIMER_MISC,AVG_TIMER_MISC,MAX_TIMER_MISC:那么些列总计了装有其余套接字操作,如socket的CONNECT、LISTEN,ACCEPT、CLOSE、SHUTDOWN类型操作。注意:那个操作未有字节计数

*
CURRENT_NUMBER_OF_BYTES_USED:增加N

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

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

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

……

SUM_TIMER_READ: 0

1 row in set (0.00 sec)

相关文章

发表评论

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

*
*
Website