| file_summary_by_instance |

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

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

     MySQL
Performance-Schema香港中华总商会共包括55个表,首要分为几类:Setup表,Instance表,Wait
伊芙nt表,Stage Event表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/THGL450_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-POMuranoT新闻,能够与应用接入起来。
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表重要涵盖1个表,events_waits_current,events_waits_history和events_waits_history_long,通过thread_id+event_id能够唯壹鲜明一条记下。current表记录了当前线程等待的事件,history表记录了种种线程如今拭目以俟的11个事件,而history_long表则记录了近来拥有线程发生的10000个事件,那里的十和一千0都是足以布署的。那四个表表结构同样,history和history_long表数据都源于current表。current表和history表中或然会有再一次事件,并且history表中的事件都以成就了的,未有终结的风波不会投入到history表中。
THREAD_ID:线程ID
EVENT_ID:当前线程的风云ID,和THREAD_ID组成多个Primary Key。
END_EVENT_ID:当事件早先时,那壹列被安装为NULL。当事件甘休时,再立异为当前的轩然大波ID。
SOURAV4CE:该事件发生时的源码文件
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表首要涵盖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
SOURubiconCE:源码位置
TIMER_START, TIMER_END,
TIMER_WAIT:事件初阶/截至和等候的时刻,单位为微秒(picoseconds)
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT, STAGE, WAIT)

Statement Event表
     
Statement表重要涵盖3个表,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五发生的三十一个人字符串。若是为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_STA景逸SUV:事件计数
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:最终2个言语执行的时光
情形:用于总计某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…

     MySQL
Performance-Schema中总括包括伍拾2个表,主要分为几类:Setup表,Instance表,Wait
伊芙nt表,Stage 伊芙nt表Statement
伊芙nt表,Connection表和Summary表。上1篇小说已经首要讲了Setup表,那篇小说将会分别就各种档次的表做详细的叙说。

admin@localhost : performance_schema 11:05:51> select * from
session_connect_attrs;

MAX _TIMER_WAIT: 0

Stage Event表 

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

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

其它表
performance_timers:
系统援助的总括时间单位
threads:
监视服务端的近来运转的线程

(2)users表

从上面表中的言传身教记录音信中,我们得以看到,同样与等待事件类似,依照用户、主机、用户+主机、线程等纬度进行分组与总计的列,分组和1些岁月总括列与等待事件类似,那里不再赘述,但对于语句计算事件,有针对语句对象的附加的计算列,如下:

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

·COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_W卡宴ITE:这几个列总计了具有发送操作(socket的SEND、SENDTO、SENDMSG类型操作,即以server为参照的socket写入数据的操作)相关的次数、时间、接收字节数等消息

# events_waits_summary_by_host_by_event_name表

(3)mutex_instances:互斥同步对象实例
表中记录了系统中选拔互斥量对象的持有记录,个中name为:wait/synch/mutex/*。比如打开文件的互斥量:wait/synch/mutex/mysys/THCR-V_LOCK_open。LOCKED_BY_THREAD_ID显示哪个线程正持有mutex,若未有线程持有,则为NULL。

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

COUNT_STAR: 7

Instance表
   
 instance中第3涵盖了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

当客户端断开连接时,performance_schema将精减对应连接的行中的CUPRADORENT_CONNECTIONS列,保留TOTAL_CONNECTIONS列值。

*
以前缀memory/performance_schema命名的instruments能够收集performance_schema本人消耗的中间缓存区大小等新闻。memory/performance_schema/*
instruments私下认可启用,无法在运行时或运营时关闭。performance_schema自己有关的内部存储器总计信息只保存在memory_summary_global_by_event_name表中,不会保存在依据帐户,主机,用户或线程分类聚合的内部存款和储蓄器总括表中

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

OBJECT _INSTANCE_BEGIN: 2655350784

SUM _TIMER_WAIT: 0

THREAD_ID:线程ID
EVENT_ID:事件ID
END_EVENT_ID:刚截至的风浪ID
SOUOdysseyCE:源码地点
TIMER_START, TIMER_END,
TIMER_WAIT:事件始于/停止和等候的年华,单位为阿秒(picoseconds)
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT,
STAGE, WAIT)

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

大家先来看望这几个表中著录的总结新闻是何许样子的。

     
 Stage表首要含有一个表,events_stages_current,events_stages_history和events_stages_history_long,通过thread_id+event_id能够唯1鲜明一条记下。表中记录了当下线程所处的施行阶段,由于能够领会各样阶段的实施时间,由此通过stage表可以博得SQL在每种阶段消耗的年月。

OBJECT_SCHEMA: xiaoboluo

从上边表中的言传身教记录消息中,大家得以观望,同样与等待事件类似,依据用户、主机、用户+主机、线程等纬度举办分组与总结的列,分组列与等待事件类似,那里不再赘言,但对此内部存款和储蓄器计算事件,总计列与其他二种事件总结列不相同(因为内部存款和储蓄器事件不总结时间支出,所以与任何二种事件类型相比较无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)

该表包涵关于内部和外部锁的音讯:

SUM _TIMER_WAIT: 0

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

# socket_summary_by_event_name表

CURRENT_COUNT_USED: 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_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宝马7系T总括,相应的还有DELETE和UPDATE总计。

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

MAX _TIMER_READ_ONLY: 57571000

Summary表
   
Summary表聚集了逐条维度的计算消息包含表维度,索引维度,会话维度,语句维度和锁维度的总结消息。
(1).wait-summary表
events_waits_summary_global_by_event_name
现象:按等待事件类型聚合,各个事件一条记下。
events_waits_summary_by_instance
地方:按等待事件目的聚合,同1种等待事件,只怕有七个实例,各类实例有差别的内部存款和储蓄器地址,因而
event_name+object_instance_begin唯一明确一条记下。
events_waits_summary_by_thread_by_event_name
场所:按各类线程和事件来总结,thread_id+event_name唯1鲜明一条记下。
COUNT_STA帕Jero:事件计数
SUM_TIMER_WAIT:总的等待时间
MIN_TIMER_WAIT:最小等待时间
MAX_TIMER_WAIT:最大等待时间
AVG_TIMER_WAIT:平均等待时间

(5) socket_instances表

DIGEST_TEXT: SELECT @@`version_comment` LIMIT ?

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

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

| Tables_in_performance_schema (%memory%summary%) |

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

IP:PO悍马H2T列组合值可用于标识多少个老是。该组合值在events_waits_xxx表的“OBJECT_NAME”列中使用,以标识那么些事件音信是来自哪个套接字连接的:

| Tables_in_performance_schema (%events_stages_summary%) |

events_statements_summary_by_account_by_event_name
events_statements_summary_by_user_by_event_name
events_statements_summary_by_host_by_event_name

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

关于events_statements_summary_by_digest表

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

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

events_statements_summary_by_digest:根据每种库级别对象和说话事件的原始语句文本总计值(md5hash字符串)举行计算,该总结值是依照事件的原始语句文本举行简易(原始语句转换为尺度语句),每行数据中的相关数值字段是独具相同总计值的总计结果。

(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

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

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

events_stages_summary_by_account_by_event_name
events_stages_summary_by_user_by_event_name
events_stages_summary_by_host_by_event_name

COUNT_STAR: 1

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

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发生的三十几位字符串。假若为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。

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

AVG _TIMER_WAIT: 0

(5)socket_instances:活跃会话对象实例
表中记录了thread_id,socket_id,ip和port,其余表能够透过thread_id与socket_instance实行关联,获取IP-PO奥迪Q三T音信,能够与应用接入起来。
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

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

对于内存块的释放,依照如下规则进行检查实验与聚集:

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组成1个Primary
Key。
END_EVENT_ID:当事件初始时,那一列被设置为NULL。当事件停止时,再立异为当下的事件ID。
SOU奥迪Q5CE:该事件时有产生时的源码文件
TIMER_START, TIMER_END,
TIMER_WAIT:事件始于/截止和等候的光阴,单位为纳秒(picoseconds)

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

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

(9).socket-summaries表
socket_summary_by_instance
socket_summary_by_event_name

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

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

(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

MAX _TIMER_READ: 56688392

COUNT_STAR: 0

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

·SQL_TEXT:prepare的讲话文本,带“?”的意味是占位符标记,后续execute语句能够对该标记举办传参。

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

(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

COUNT_READ: 0

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

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

实践该语句时有如下行为:

SUM _TIMER_WAIT: 56688392

COUNT_ALLOC: 193

EVENT_NAME: wait/io/socket/sql/client_connection

5rows inset ( 0. 00sec)

AVG_TIMER_EXECUTE: 0

  • SUM_NUMBER_OF_BYTES_FREE

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

对此每个线程的总结新闻,适用以下规则。

MAX_TIMER_WAIT: 9498247500

events_statements_summary_by_program:遵照每一种存款和储蓄程序(存储进程和函数,触发器和事件)的事件名称进行计算的Statement事件

|4| _pid |3766| 2 |

SUM _TIMER_WAIT: 0

mutex_instances表列出了server执行mutex
instruments时performance_schema所见的持有互斥量。互斥是在代码中采纳的1种共同机制,以强制在加以时间内唯有二个线程能够访问1些公共能源。能够认为mutex爱护着那几个公共财富不被随机抢占。

| Tables_in_performance_schema (%prepare%) |

·当四个pending状态的锁被死锁检查实验器检查评定并选定为用于打破死锁时,那一个锁会被打消,并赶回错误音讯(ECRUISER_LOCK_DEADLOCK)给请求锁的对话,锁状态从PENDING更新为VICTIM;

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

·LOCKED_BY_THREAD_ID:当五个线程当前颇具二个排斥锁定时,LOCKED_BY_THREAD_ID列显示全体线程的THREAD_ID,若是未有被此外线程持有,则该列值为NULL。

SUM _TIMER_WAIT: 0

| HOST |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |

COUNT _READ_WRITE: 6

·rwlock_instances:wait sync相关的lock对象实例;

SUM _TIMER_READ_WRITE: 8592136000

1 rows in set (0.00 sec)

SUM _CREATED_TMP_TABLES: 10

该表允许使用TRUNCATE
TABLE语句。只将总计列重置为零,而不是删除行。对该表执行truncate还会隐式truncate
table_io_waits_summary_by_index_usage表

EVENT_NAME: stage/sql/After create

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

events_statements_summary_by_thread_by_event_name:依照每种线程和事件名称进行总括的Statement事件

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

EVENT_NAME: memory/innodb/fil0fil

LOCK_STATUS: GRANTED

*
即使该线程在threads表中绝非打开采集效能或许说在setup_instruments中对应的instruments未有打开,则该线程分配的内部存储器块不会被监察和控制

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

COUNT_STAR: 7

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

1 row in set (0.00 sec)

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

COUNT_ALLOC: 103

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

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

澳门新葡亰 1

COUNT_STAR: 7

* _runtime_vendor:Java运维条件(JRE)供应商名称

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

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

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

1. 连接音讯计算表

1 row in set (0.00 sec)

透过对以下多个表执行查询,可以兑现对应用程序的监督检查或DBA能够检查评定到事关锁的线程之间的部分瓶颈或死锁音信:

MAX _TIMER_WAIT: 0

| wait/io/socket/sql/server_unix_socket |110667520| 1 |34| |0| ACTIVE
|

……

这么些连接表都允许选择TRUNCATE TABLE语句:

SUM _TIMER_WAIT: 0

SOURCE: sql_parse.cc:6031

*
FIRST_SEEN,LAST_SEEN:呈现某给定语句第一次插入
events_statements_summary_by_digest表和末段二次创新该表的年华戳

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

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

SUM _TIMER_READ: 56688392

OBJECT_TYPE: PROCEDURE

(2)session_connect_attrs表

MIN _TIMER_WAIT: 0

OBJECT _INSTANCE_BEGIN: 2655351104

……

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

HIGH _NUMBER_OF _BYTES_USED: 32

注意:rwlock_instances表中的新闻只可以查看到拥有写锁的线程ID,但是不能够查看到有着读锁的线程ID,因为写锁W奥迪Q伍ITE_LOCKED_BY_THREAD_ID字段记录的是线程ID,读锁唯有2个READ_LOCKED_BY_COUNT字段来记录读锁被有个别个线程持有。

* SUM_NUMBER_OF_BYTES_FREE:增加N

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

CURRENT _NUMBER_OF _BYTES_USED: 0

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

*
假若三个线程开启了采访作用,可是内部存款和储蓄器相关的instruments没有启用,则该内部存储器释放操作不会被监察和控制到,总计数据也不会发生变更

| table_io_waits_summary_by_index_usage |#
根据各样索引举行总计的表I/O等待事件

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

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

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

| wait/io/socket/sql/server_tcpip_socket |110667200| 1 |32| :: |3306|
ACTIVE |

COUNT_STAR: 0

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

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

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

SUM_WARNINGS: 0

MySQL允许应用程序引进新的连接属性,可是以下划线(_)伊始的习性名称保留供内部使用,应用程序不要成立那种格式的接连属性。以确定保证内部的接连属性不会与应用程序创制的连接属性相争执。

# events_statements_summary_by_account_by_event_name表

OPEN_COUNT:文件当前已开辟句柄的计数。要是文件打开然后关门,则打开壹遍,但OPEN_COUNT列将加壹然后减一,因为OPEN_COUNT列只总结当前已开拓的公文句柄数,已关门的文件句柄会从中减去。要列出server中当前打开的有着文件新闻,能够行使where
WHERE OPEN_COUNT> 0子句实行查看。

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

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

SUM_SELECT_RANGE: 0

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

| events_stages_summary_by_user_by_event_name |

mutex_instances表字段含义如下:

从地点表中的演示记录消息中,我们能够看来:

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

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

* _client_version:客户端libmysql库版本

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

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

*
将COUNT_ALLOC和COUNT_FREE列重置,不分轩轾复开端计数(等于内存总括信息以重置后的数值作为标准数据)

·table_handles:表锁的持有和伸手记录。

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

连天总计消息表允许接纳TRUNCATE
TABLE。它会同时删除总结表中尚无连接的帐户,主机或用户对应的行,重置有接二连三的帐户,主机或用户对应的行的并将别的行的CU科雷傲RENT_CONNECTIONS和TOTAL_CONNECTIONS列值。

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

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

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

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

1 row in set (0.00 sec)

·澳门新葡亰,当监听套接字检查评定到连年时,srever将一连转移给1个由独立线程管理的新套接字。新连接线程的instruments具有client_connection的socket_type值,组成对应的instruments名称;

COUNT_STAR: 7

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

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

套接字事件计算了套接字的读写调用次数和出殡和埋葬接收字节计数新闻,socket事件instruments暗中认可关闭,在setup_consumers表中无实际的呼应配置,包涵如下两张表:

events_waits_summary_by_host_by_event_name表:按照列EVENT_NAME、HOST进行分组事件音信

AVG_TIMER_READ: 530278875

EVENT_NAME: statement/sql/select

当在server中并且履行的三个线程(例如,同时执行查询的几个用户会话)须求拜访同1的财富(例如:文件、缓冲区或有个别数据)时,那四个线程相互竞争,由此首先个成功收获到互斥体的询问将会堵塞别的会话的询问,直到成功博得到互斥体的对话执行到位并释放掉那一个互斥体,其他会话的询问才能够被实施。

USER: root

| 4 |_client_version | 5.7.18 |3|

EVENT_NAME: transaction

COUNT_EXECUTE: 0

THREAD_ID: 1

从客户端发送到服务器的连年属性数据量存在限制:客户端在连年此前客户端有3个谈得来的原则性长度限制(不可配置)、在客户端连接server时服务端也有2个定点长度限制、以及在客户端连接server时的一而再属性值在存入performance_schema中时也有叁个可配置的长短限制。

| events_statements_summary_by_account_by_event_name |

table_handles表不容许选拔TRUNCATE TABLE语句。

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

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

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

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

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

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

COUNT_STABMWX叁:事件被实施的数量。此值包涵全数事件的推行次数,须求启用等待事件的instruments

INDEX_NAME: PRIMARY

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

| 4 |_client_name | libmysql |1|

IT从业多年,历任运行工程师、高级运转为工人身份程师、运营首席营业官、数据库工程师,曾插足版本发布系统、轻量级监察和控制种类、运维管理平台、数据库管理平台的规划与编辑,熟知MySQL体系布局,Innodb存款和储蓄引擎,喜好专研开源技术,追求面面俱圆。

admin@localhost : performance_schema 06:48:12> show tables like
‘%file_summary%’;

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

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

events_statements_summary_by_account_by_event_name:依据各样帐户和讲话事件名称实行总结

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

MIN _TIMER_WAIT: 0

*
performance_schema截断超越长度的属性数据,并扩充Performance_schema_session_connect_attrs_lost状态变量值,截断叁回扩充三次,即该变量表示连接属性被截断了多少次

SUM_ROWS_SENT: 1635

·OBJECT_SCHEMA:该锁来自于哪个库级别的指标;

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

– END –

EVENT_NAME: statement/sql/select

·OWNER_EVENT_ID:请求元数据锁的轩然大波ID。

| events_stages_summary_by_host_by_event_name |

咱们先来探视表中记录的总计音讯是怎么着体统的。

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

|4| _platform |x86_64 | 4 |

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

OBJECT_TYPE: TABLE

| 语句事件总计表

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

Rows matched: 377 Changed: 377 Warnings: 0

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

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

| NULL |41| 45 |

| events_transactions_summary_global_by_event_name |

admin@localhost : performance_schema 02:53:40> select * from
file_instances where OPEN_COUNT> 0limit 1;

1 row in set (0.01 sec)

·file_summary_by_event_name:遵照每种事件名称进行计算的文本IO等待事件

AVG _TIMER_READ_ONLY: 57571000

# table_io_waits_summary_by_index_usage表

检验内部存储器工作负荷峰值、内部存款和储蓄器总体的行事负荷稳定性、可能的内部存款和储蓄器泄漏等是任重先生而道远的。

|admin | localhost |1| 1 |

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

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

# events_transactions_summary_by_account_by_event_name表

|NULL | NULL |41| 45 |

COUNT_FREE: 103

| USER |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |

1 row in set (0.00 sec)

·socket_summary_by_instance:针对各种socket实例的有着 socket
I/O操作,那些socket操作相关的操作次数、时间和出殡和埋葬接收字节新闻由wait/io/socket/*
instruments发生。但当连接中断时,在该表中对应socket连接的消息就要被删除(那里的socket是指的脚下活蹦乱跳的连接创制的socket实例)

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

大家先来探望表中记录的总括音讯是怎么着体统的。

| events_waits_summary_by_instance |

·VICTIM,TIMEOUT和KILLED状态值停留时间很简短,当二个锁处于这一个景况时,那么表示该锁行新闻就要被删去(手动执行SQL大概因为日子原因查看不到,可以使用程序抓取);

COUNT_ALLOC: 1

[Warning] Connection attributes oflength N were truncated

MAX _TIMER_WAIT: 0

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

SUM_TIMER_WAIT: 234614735000

OBJECT_TYPE: TABLE

# events_waits_summary_by_user_by_event_name表

……

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

·THREAD_ID:由server分配的里边线程标识符,各类套接字都由单个线程举办田管,由此各个套接字都能够映射到五个server线程(若是能够映射的话);

1 row in set (0.00 sec)

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

1 row in set (0.00 sec)

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

天性事件计算表中的多寡条目是不能去除的,只能把相应总结字段清零;

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

其它,依照帐户、主机、用户、线程聚合的每一个等待事件总括表只怕events_waits_summary_global_by_event_name表,借使借助的连接表(accounts、hosts、users表)执行truncate时,那么依赖的这个表中的计算数据也会同时被隐式truncate

内需有所互斥体的干活负荷可以被认为是居于一个主要职位的工作,多少个查询可能供给以类别化的不二诀窍(贰回三个串行)执行那么些至关心注重要部分,但那恐怕是叁个神秘的质量瓶颈。

# memory_summary_by_account_by_event_name表

那几个表列出了等待事件中的sync子类事件相关的靶子、文件、连接。在这之中wait
sync相关的对象类型有二种:cond、mutex、rwlock。每一个实例表都有二个EVENT_NAME或NAME列,用于显示与每行记录相关联的instruments名称。instruments名称只怕具备多个部分并形成层次结构,详见”配置详解
| performance_schema全方位介绍”。

……

OBJECT _INSTANCE_BEGIN: 139968890586816

1 row in set (0.00 sec)

* _client_license:连接器许可证类型

EVENT_NAME: transaction

TIMER_PREPARE: 896167000

出品:沃趣科学和技术

AVG_TIMER_WAIT: 24366870

SUM _TIMER_READ_ONLY: 57571000

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

MIN _TIMER_WAIT: 0

SUM_TIMER_WAIT: 62379854922

SCHEMA_NAME: NULL

·STATEMENT_ID:由server分配的语句内部ID。文本和2进制协议都应用该语句ID。

| Tables_in_performance_schema (%events_transactions_summary%) |

MIN _TIMER_WAIT: 56688392

1 row in set (0.00 sec)

(2)file_instances表

EVENT_NAME: memory/innodb/fil0fil

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

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

OWNER_OBJECT_SCHEMA: NULL

# events_statements_summary_global_by_event_name表

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

AVG _TIMER_WAIT: 0

MAX_TIMER_READ_NORMAL: 0

1row inset ( 0. 00sec)

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

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

admin@localhost : performance _schema 11:01:23> select * from
file_summary _by_instance where SUM _TIMER_WAIT!=0 and EVENT_NAME
like ‘%innodb%’ limit 1G;

1 row in set (0.00 sec)

PS:MySQL
server使用两种缓存技术通过缓存从文件中读取的音信来制止文件I/O操作。当然,假若内存不够时要么内部存款和储蓄器竞争相比大时恐怕导致查询成效低下,那个时候你大概须要通过刷新缓存大概重启server来让其数据经过文件I/O重回而不是经过缓存重回。

OBJECT_SCHEMA: sys

……

AVG _TIMER_WAIT: 0

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

SUM _NO_GOOD _INDEX_USED: 0

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

| 温馨提醒

·DEALLOCATE PREPARE步骤:语法 {DEALLOCATE | DROP} PREPARE
stmt_name,示例:drop prepare stmt;
,此时在prepared_statements_instances表中对应的prepare示例记录自动删除。

* COUNT_ALLOC:增加1

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

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

4rows inset ( 0. 00sec)

*
CURRENT_NUMBER_OF_BYTES_USED:增加N

相关文章