初相识|performance_schema全方位介绍(一)

[mysqld]

admin@localhost : performance _schema 01:55:49> select * from
table_io _waits_summary _by_index _usage where
SUM_TIMER_WAIT!=0G;

* CURRENT_NUMBER_OF_BYTES_USED:减少N

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

     MySQL
Performance-Schema中总共包括伍拾九个表,首要分为几类: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/TH牧马人_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奥迪Q5T音信,能够与运用接入起来。
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能够唯1鲜明一条记下。current表记录了当前线程等待的轩然大波,history表记录了各个线程最近守候的十一个事件,而history_long表则记录了多年来全数线程产生的10000个事件,那里的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。
SOUOdysseyCE:该事件发生时的源码文件
TIMER_START, TIMER_END,
TIMER_WAIT:事件开端/截止和等候的光阴,单位为微秒(picoseconds)

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE视情形而定
对于联合对象(cond, mutex, rwlock),那么些2个值均为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能够唯1分明一条记下。表中记录了方今线程所处的施行阶段,由于能够清楚各类阶段的实施时间,因而通过stage表能够获得SQL在每个阶段消耗的年月。

THREAD_ID:线程ID
EVENT_ID:事件ID
END_EVENT_ID:刚结束的事件ID
SOUTiguanCE:源码地方
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能够唯一明确一条记下。Statments表只记录最顶层的央浼,SQL语句或是COMMAND,每条语句一行,对于嵌套的子查询或然存款和储蓄进度不会独自列出。event_name形式为statement/sql/*,或statement/com/*
SQL_TEXT:记录SQL语句
DIGEST:对SQL_TEXT做MD伍发出的三15位字符串。倘使为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).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:平均等待时间

(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个言辞执行的年月
情景:用于计算某一段时间内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
INSEBMWX5T总计,相应的还有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…

qogir_env@localhost: performance_schema 04:23:40> UPDATE setup_consumers SET
ENABLED = ‘YES’where name like
‘%wait%’;

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

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

Rowsmatched: 323 Changed: 0 Warnings: 0

MIN_TIMER_READ_NORMAL: 0

COUNT_STAR: 55

当我们看来PEPAJEROFO奥迪Q5MANCE_SCHEMA
对应的Support
字段输出为YES时就象征大家最近的数据库版本是永葆performance_schema的。但敞亮大家的实例协助performance_schema引擎就足以采取了啊?NO,很遗憾,performance_schema在伍.陆会同此前的本子中,暗许未有启用,从五.七会同之后的版本才修改为暗许启用。以往,大家来看望哪些设置performance_schema私下认可启用吧!

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

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

qogir_env@localhost :
performance_schema 06:14:08>
SELECT THREAD_ID,EVENT_ID,EVENT_NAME,TIMER_WAIT FROM
events_waits_history ORDER BY THREAD_ID limit 21;

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

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

|
/data/mysqldata1/mydata/multi_master/test.ibd
|wait/io/file/innodb/innodb_data_file | 1 |

3.文书I/O事件总结

# events_stages_summary_by_host_by_event_name表

THREAD_ID: 4

AVG_TIMER_READ: 0

SUM _TIMER_WAIT: 0

qogir_env@localhost :
performance_schema 02:41:41>
SELECT * FROM INFORMATION_SCHEMA.ENGINES WHERE ENGINE =’PERFORMANCE_SCHEMA’;

# table_io_waits_summary_by_table表

COUNT_STAR: 7

qogir_env@localhost : performance_schema
04:23:52> SELECT * FROM events_waits_current limit 1G

·当行音讯中CU奇骏RENT_CONNECTIONS
字段值大于0时,执行truncate语句不会去除这么些行,TOTAL_CONNECTIONS字段值被重置为CUXC60RENT_CONNECTIONS字段值;

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

| wait/io/file/sql/FRM |452|

·socket_instances:活跃接连实例。

1 row in set (0.01 sec)

| setup_timers |

从地点表中的笔录音讯我们能够看看:

USER: root

IT从业多年,历任运行工程师、高级运行工程师、运维高管、数据库工程师,曾加入版本发布系统、轻量级监察和控制系统、运转管理平台、数据库管理平台的陈设性与编辑,熟练MySQL连串布局,Innodb存款和储蓄引擎,喜好专研开源技术,追求百步穿杨。

OBJECT_TYPE: TABLE

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

|wait/io/file/sql/casetest | 104324715
|

MAX_TIMER_READ: 9498247500

可因此如下语句查看语句事件总计表:

|performance_schema | ON |

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

HOST: localhost

|
events_transactions_summary_by_thread_by_event_name |

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

……

……

·若果值为NULL,则表示表I/O未有行使到目录

HOST: NULL

|
/home/mysql/program/share/charsets/Index.xml
|wait/io/file/mysys/charset

(5) socket_instances表

SUM _TIMER_WAIT: 8649707000

|EVENT_NAME | SUM_TIMER_WAIT |

该表包涵关于内部和表面锁的音信:

1 row in set (0.00 sec)

| 4 |348|
wait/io/file/innodb/innodb_log_file |693076224|

那么些连接表都允许行使TRUNCATE TABLE语句:

举办该语句时有如下行为:

主要编辑:

……

MAX _TIMER_WAIT: 0

| /data/mysqldata1/undo/undo003
|wait/io/file/innodb/innodb_data_file | 3 |

……

EVENT_NAME: wait/synch/mutex/mysys/THR_LOCK_heap

| events_statements_history |

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

*
读写作业平日比只读事务占用越来越多资源,因此事务总括表包蕴了用于读写和只读事务的独门总结列

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

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

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

|
events_transactions_summary_by_user_by_event_name |

从下面表中的记录消息大家得以见见(与公事I/O事件计算类似,两张表也各自遵照socket事件类型总括与听从socket
instance举行总括)

SUM _SORT_MERGE_PASSES: 0

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

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

COUNT_STAR: 53

……

(1) session_account_connect_attrs表

| memory_summary_by_host_by_event_name |

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

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

EVENT_NAME: stage/sql/After create

qogir_env@localhost :
performance_schema 03:20:43>
use performance_schema

4 rows in set (0.00 sec)

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

12rows inset (0.01sec)

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

大家先来看望这个表中著录的计算消息是如何样子的。

SPINS: NULL

文本I/O事件总括表只记录等待事件中的IO事件(不含有table和socket子连串),文件I/O事件instruments私下认可开启,在setup_consumers表中无实际的照应配置。它蕴涵如下两张表:

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

| events_transactions_history |

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

events_statements_summary_by_program表有本身额外的总计列:

qogir_env@localhost: performance_schema 03:34:40> UPDATE setup_instruments SET
ENABLED = ‘YES’, TIMED = ‘YES’where name like ‘wait%’;;

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

SUM _TIMER_WAIT: 0

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

MAX _TIMER_WAIT: 121025235946125

MAX _TIMER_WAIT: 0

| cond_instances |

·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列举办分组

SUM_ERRORS: 2

从上文中大家曾经知道,performance_schema在伍.柒.x会同以上版本中默许启用(5.陆.x及其以下版本暗许关闭),借使要显式启用或关闭时,大家供给利用参数performance_schema=ON|OFF设置,并在my.cnf中开始展览配备:

…………

MIN_TIMER_WAIT: 72775000

正文小结

OWNER_OBJECT_TYPE: NULL

SUM_SORT_SCAN: 6

| Tables_in_performance_schema
(%transaction%) |

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

# events_statements_summary_by_account_by_event_name表

动态对performance_schema实行布局的配置表:

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

EVENT_NAME: memory/performance_schema/mutex_instances

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

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

COUNT_STAR: 7

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

MAX_TIMER_READ_NORMAL: 0

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

2.3.
performance_schema表的分类

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

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

| Engine |Support | Comment

# table_lock_waits_summary_by_table表

performance_schema会记录内部存款和储蓄器使用景况并汇聚内部存款和储蓄器使用总计新闻,如:使用的内部存款和储蓄器类型(各类缓存,内部缓冲区等)和线程、帐号、用户、主机的相干操作直接进行的内部存款和储蓄器操作。performance_schema从利用的内部存款和储蓄器大小、相关操作数量、高低水位(内部存款和储蓄器三回操作的最大和微小的有关总结值)。

|PERFORMANCE_SCHEMA | YES
|Performance Schema | NO
|NO | NO |

COUNT_STAR: 1

SUM _CREATED_TMP _DISK_TABLES: 3

| events_statements_history_long
|

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

小编:

| ENGINE |SUPPORT | COMMENT |TRANSACTIONS | XA |SAVEPOINTS |

OBJECT_NAME: test

AVG _TIMER_WAIT: 1235672000

当今,大家曾经大概知道了performance_schema中的重要表的归类,但,怎么样利用他们来为大家提供应和必要要的性子事件数量吧?下边,大家介绍怎么着通过performance_schema下的布置表来配置与应用performance_schema。

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

我们先来探望这个表中著录的总结新闻是什么样子的。

|wait/synch/mutex/mysys/THR_LOCK_malloc | 6419 |

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

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

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

metadata_locks表不容许行使TRUNCATE TABLE语句。

COUNT_STAR: 7

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

·当叁个线程正在等候某事发生时,condition
NAME列展现了线程正在等待什么condition(但该表中并不曾其余列来展现对应哪个线程等新闻),可是当前还未曾平素的格局来判断某些线程或少数线程会促成condition发生转移。

由于performance_schema表内部存款和储蓄器限制,所以尊崇了DIGEST
= NULL的独特行。
当events_statements_summary_by_digest表限制体积已满的情事下,且新的讲话总计音信在须求插入到该表时又从不在该表中找到匹配的DIGEST列值时,就会把这个语句计算新闻都计算到
DIGEST =
NULL的行中。此行可扶助您推测events_statements_summary_by_digest表的限定是不是必要调动

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

table_handles表是只读的,无法创新。暗中认可自动调整表数据行大小,要是要显式钦命个,能够在server运转在此以前安装系统变量performance_schema_max_table_handles的值。

USER: root

Database changed

OBJECT_TYPE: TABLE

PS2:至于存款和储蓄程序监察和控制行为:对于在setup_objects表中启用了instruments的蕴藏程序类型,events_statements_summary_by_program将保障存款和储蓄程序的总结新闻,如下所示:

instance表记录了哪些类型的对象会被检验。那么些目的在被server使用时,在该表少将会发生一条事件记录,例如,file_instances表列出了文本I/O操作及其关系文件名:

# table_io_waits_summary_by_index_usage表

……

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

·hosts:依据host名称对各种客户端连接实行总结;

1 row in set (0.00 sec)

OBJECT_NAME: NULL

·HOST:某些连接的主机名,假使是一个里边线程创制的连日,或然是无能为力印证的用户创立的连年,则该字段为NULL;

EVENT_NAME: transaction

依照事件类型分组记录品质事件数量的表

·users:依照用户名对每种客户端连接实行总结。

SUM _TIMER_READ_ONLY: 57571000

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

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

COUNT_STAR: 11

INDEX_NAME: NULL

各类连接音讯表都有CU大切诺基RENT_CONNECTIONS和TOTAL_CONNECTIONS列,用于跟踪连接的脚下连接数和总连接数。对于accounts表,每一种连接在表中每行音讯的绝无仅有标识为USE奥德赛+HOST,可是对于users表,只有2个user字段实行标识,而hosts表唯有1个host字段用于标识。

1 row in set (0.00 sec)

FLAGS: NULL

·WRITE_LOCKED_BY_THREAD_ID:当七个线程当前在独占(写入)方式下持有四个rwlock时,W陆风X8ITE_LOCKED_BY_THREAD_ID列能够查阅到具有该锁的线程THREAD_ID,假使未有被其余线程持有则该列为NULL;

| events_statements_summary_by_host_by_event_name |

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

(2)table_handles表

1 row in set (0.00 sec)

| 4 |350|
wait/synch/mutex/innodb/log_sys_mutex |25536|

| table_lock_waits_summary_by_table |#
依照每种表展开总结的表锁等待事件

COUNT_STAR: 3

87rows inset (0.00sec)

SUM _TIMER_READ _WITH_SHARED_LOCKS: 0

USER: NULL

|目
1、什么是performance_schema

admin@localhost : performance _schema 01:57:20> select * from
table_lock _waits_summary _by_table where SUM _TIMER_WAIT!=0G;

EVENT_NAME: memory/innodb/fil0fil

| NO |NO | NO |

3rows inset ( 0. 00sec)

在上一篇《事件记录 |
performance_schema全方位介绍”》中,大家详细介绍了performance_schema的轩然大波记录表,恭喜大家在念书performance_schema的中途度过了五个最辛勤的时代。未来,相信我们早就相比较清楚什么是事件了,但奇迹咱们不须要驾驭每时每刻发生的每一条事件记录音信,
例如:大家愿意掌握数据库运营以来壹段时间的轩然大波总计数据,这一年就必要查阅事件总结表了。今日将指点我们1道踏上层层第6篇的征途(全系共八个篇章),在那壹期里,我们将为我们无微不至授课performance_schema中事件总结表。总计事件表分为多少个类型,分别为等候事件、阶段事件、语句事件、事务事件、内部存储器事件。上面,请随行大家一并起来performance_schema系统的上学之旅吧。

5rows inset (0.00sec)

·OBJECT_SCHEMA:该锁来自于哪个库级其余目的;

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

|13| 2260
|wait/synch/mutex/innodb/buf_pool_mutex | 111264 |

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

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

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

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

1 row in set (0.00 sec)

……

SUM_WARNINGS: 0

MIN _TIMER_WAIT: 0

|Transactions | XA |Savepoints
|

那几个表列出了等候事件中的sync子类事件相关的靶子、文件、连接。在那之中wait
sync相关的对象类型有二种:cond、mutex、rwlock。各个实例表都有贰个EVENT_NAME或NAME列,用于展现与每行记录相关联的instruments名称。instruments名称也许有所八个部分并摇身一变层次结构,详见”配置详解
| performance_schema全方位介绍”。

5rows inset ( 0. 00sec)

|
memory_summary_global_by_event_name |

·HOST:某总是的客户端主机名。倘诺是一个内部线程创设的总是,大概是心有余而力不足求证的用户创立的接连,则该字段为NULL;

| memory_summary_global_by_event_name |

8rows inset (0.00sec)

从表中的笔录内容可以看看,依据库xiaoboluo下的表test举行分组,总括了表相关的守候事件调用次数,计算、最小、平均、最大延迟时间音讯,利用那一个信息,大家能够大致了然InnoDB中表的造访效能排名计算情形,一定水准上反应了对存款和储蓄引擎接口调用的功效。

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

2.2. 启用performance_schema

·socket_summary_by_event_name表:按照EVENT_NAME列进行分组

有关内部存款和储蓄器事件的一言一行监督装置与注意事项

|
/data/mysqldata1/mydata/mysql/innodb_index_stats.ibd
|wait/io/file/innodb/innodb_data_file | 3 |

# file_summary_by_event_name表

events_waits_summary_global_by_event_name表:按照EVENT_NAME列进行分组事件消息

| events_statements_current |

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

MIN _TIMER_WAIT: 0

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

| NULL |41| 45 |

| 语句事件总计表

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

|4| _pid |3766| 2 |

内部存款和储蓄器大小总计消息有助于通晓当下server的内部存款和储蓄器消耗,以便及时开始展览内部存款和储蓄器调整。内部存款和储蓄器相关操作计数有助于驾驭当下server的内部存款和储蓄器分配器的欧洲经济共同体压力,及时间控制制server品质数据。例如:分配单个字节一百万次与单次分配一百万个字节的质量费用是例外的,通过跟踪内部存款和储蓄器分配器分配的内部存款和储蓄器大小和分红次数就足以知道两岸的距离。

|
events_stages_summary_by_user_by_event_name |

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

USER: NULL

蹲点文件系统层调用的表:

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

COUNT_STAR: 0

| Tables_in_performance_schema
|

COUNT_STAR: 56

| events_stages_summary_global_by_event_name |

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

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

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

2.2. 启用performance_schema

users表包括连接到MySQL
server的每种用户的总是音讯,每种用户1行。该表将针对用户名作为唯一标识举行总计当前连接数和总连接数,server运营时,表的分寸会自行调整。
要显式设置该表大小,能够在server运转在此之前安装系统变量performance_schema_users_size的值。该变量设置为0时意味着禁止使用users计算音讯。

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

|
memory_summary_by_user_by_event_name |

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

品质事件计算表中的某部instruments是还是不是举办总括,信赖于在setup_instruments表中的配置项是否打开;

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

AVG_TIMER_EXECUTE: 0

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

|4|
349 |wait/synch/mutex/innodb/fil_system_mutex | 65664 |

admin@localhost : performance_schema 09 :49:41> select * from
hosts;

SUM_LOCK_TIME: 26026000000

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

MAX _TIMER_READ: 56688392

SUM_TIMER_WAIT: 234614735000

#
这几个结果证明,TH昂科威_LOCK_malloc互斥事件是最热的。注:THCRUISER_LOCK_malloc互斥事件仅在DEBUG版本中存在,GA版本不设有

6.instance 统计表

THREAD_ID: 47

|
/data/mysqldata1/mydata/mysql/help_keyword.ibd
|wait/io/file/innodb/innodb_data_file | 3 |

– END –

  • SUM_NUMBER_OF_BYTES_FREE

|
events_waits_summary_by_user_by_event_name |

品质总括表

*
假诺threads表中该线程的收集作用和setup_instruments表中相应的memory
instruments都启用了,则该线程分配的内部存款和储蓄器块会被监察和控制

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

下篇将为大家分享 《复制状态与变量记录表 |
performance_schema全方位介绍》 ,多谢您的翻阅,咱们不见不散!重返搜狐,查看越来越多

EVENT_NAME: memory/innodb/fil0fil

| Tables_in_performance_schema
(%statement%) |

*
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT:那些列计算全部I/O操作数量和操作时间

COUNT_STAR: 7

| setup_objects |

当在server中并且施行的五个线程(例如,同时施行查询的四个用户会话)须求拜访同1的能源(例如:文件、缓冲区或少数数据)时,那七个线程相互竞争,由此首先个成功获取到互斥体的查询将会卡住其余会话的询问,直到成功收获到互斥体的对话执行到位并释放掉那一个互斥体,其余会话的询问才能够被实践。

Rows matched: 377 Changed: 377 Warnings: 0

qogir_env@localhost :
performance_schema 06:27:26>
SELECT * FROM file_instances limit 20;

·THREAD_ID:由server分配的中间线程标识符,每一个套接字都由单个线程举办政管理制,由此各样套接字都足以映射到贰个server线程(假使得以映射的话);

MAX _TIMER_WAIT: 0

| users |

·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

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

·TOTAL_CONNECTIONS:某帐号的总连接数(新扩张贰个连接累计一个,不会像当前连接数那样连接断开会收缩)。

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

|PERFORMANCE_SCHEMA | YES
|Performance Schema

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

*
事务所占用的能源须求多少也说不定会因业务隔开级别有所出入(例如:锁财富)。不过:每一种server可能是选择同样的隔离级别,所以不单独提供隔绝级别相关的总结列

| accounts |

5.prepare语句实例总括表

| events_stages_summary_by_host_by_event_name |

直接在performance_schema库下选用show
tables语句来查看有何样performance_schema引擎表:

admin@localhost : performance _schema 11:10:42> select * from
objects_summary _global_by _type where SUM_TIMER_WAIT!=0G;

PS:对那个表使用truncate语句,影响与等待事件类似。

qogir_env@localhost :
performance_schema 03:58:38>
show tables like ‘%memory%’;

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

属性事件总括表中的多少条目是无法去除的,只好把相应总括字段清零;

现行反革命,我们知晓了在 MySQL 5.7.17版本中,performance_schema
下1起有八七张表,那么,那87帐表都以存放什么数据的啊?大家什么样使用他们来查询我们想要查看的数目吧?先别着急,我们先来看望那么些表是哪些分类的。

·socket_summary_by_instance:针对各个socket实例的富有 socket
I/O操作,那些socket操作相关的操作次数、时间和发送接收字节音讯由wait/io/socket/*
instruments发生。但当连接中断时,在该表中对应socket连接的消息就要被删除(那里的socket是指的眼下活蹦乱跳的接连成立的socket实例)

EVENT_NAME: memory/innodb/fil0fil

performance_schema被视为存款和储蓄引擎。借使该汽油发动机可用,则应该在INFO奔驰G级MATION_SCHEMA.ENGINES表或SHOW
ENGINES语句的出口中都能够见到它的SUPPORAV肆T值为YES,如下:

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

AVG _TIMER_WAIT: 0

|
/data/mysqldata1/innodb_log/ib_logfile0
|wait/io/file/innodb/innodb_log_file | 2 |

·file_instances:文件对象实例;

5rows inset ( 0. 00sec)

事务事件记录表,记录事务相关的事件的表,与话语事件类型的连锁记录表类似:

咱俩先来看看表中著录的总计音信是怎么着样子的。

USER: NULL

本篇内容到此处就象是尾声了,相信广大人都认为,大家大多数时候并不会直接利用performance_schema来查询品质数据,而是利用sys
schema下的视图代替,为何不间接攻读sys schema呢?这你领会sys
schema中的数据是从哪个地方吐出来的啊?performance_schema
中的数据实际上首若是从performance_schema、information_schema中取得,所以要想玩转sys
schema,周详明白performance_schema不可或缺。其余,对于sys
schema、informatiion_schema甚至是mysql
schema,大家继承也会生产不一样的1类别文章分享给大家。

| file_summary_by_event_name |

| events_waits_summary_by_account_by_event_name |

|wait/synch/mutex/mysys/LOCK_alarm | 147
|

EVENT_NAME: wait/io/socket/sql/client_connection

1 row in set (0.00 sec)

| cond_instances |

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

MIN _TIMER_WAIT: 0

| 13 |2259|
wait/synch/mutex/innodb/fil_system_mutex |8708688|

·当呼吁立刻赢得元数据锁时,将插入状态为GRANTED的锁消息行;

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

蹲点内部存款和储蓄器使用的表:

·READ_LOCKED_BY_COUNT:当贰个线程在共享(读)方式下持有2个rwlock时,READ_LOCKED_BY_COUNT列值扩大一,所以该列只是叁个计数器,不可能一向用来查找是哪位线程持有该rwlock,但它能够用来查阅是还是不是留存二个有关rwlock的读争用以及查看当前有稍许个读情势线程处于活跃状态。

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

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

PS:什么是prepare语句?prepare语句实在正是二个预编写翻译语句,先把SQL语句进行编译,且能够设定参数占位符(例如:?符号),然后调用时通过用户变量传入具体的参数值(叫做变量绑定),要是2个言辞必要频仍履行而仅仅只是where条件不一致,那么使用prepare语句能够大大减弱硬解析的开发,prepare语句有多个步骤,预编写翻译prepare语句,执行prepare语句,释放销毁prepare语句,prepare语句协助二种协议,前边早已涉嫌过了,binary合计1般是提须要应用程序的mysql
c api接口方式访问,而文本协议提要求通过客户端连接到mysql
server的法子访问,上边以文件协议的办法访问举行出现说法验证:

USER: root

数据库刚刚开头化并运营时,并非全部instruments(事件采访项,在收集项的布置表中每1项都有贰个开关字段,或为YES,或为NO)和consumers(与征集项类似,也有二个对应的风浪类型保存表配置项,为YES就意味着对应的表保存品质数据,为NO就表示对应的表不保留品质数据)都启用了,所以暗中认可不会收集全部的轩然大波,大概你须求检查实验的事件并未有打开,供给举办安装,能够使用如下七个语句打开对应的instruments和consumers(行计数大概会因MySQL版本而异),例如,我们以安插监测等待事件数量为例进行认证:

session_account_connect_attrs表仅包涵当前三番五次及其相关联的别的连接的连天属性。要查看全数会话的连日属性,请查看session_connect_attrs表。

# events_waits_summary_by_user_by_event_name表

qogir_env@localhost : performance_schema 06:19:20> SELECT
EVENT_NAME,SUM_TIMER_WAIT FROM
events_waits_summary_global_by_event_澳门新萄京网址,name

大家先来看望表中著录的总计音信是怎么着样子的。

*
LOW_COUNT_USED:如果CURRENT_COUNT_USED收缩1今后是二个新的最低值,则该字段相应裁减

| /data/mysqldata1/undo/undo001
|wait/io/file/innodb/innodb_data_file | 3 |

| qfsys |10.10. 20.15| 1 |1|

# events_waits_summary_by_account_by_event_name表

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

·file_summary_by_event_name:根据每一种事件名称进行总括的文件IO等待事件

EVENT_NAME: stage/sql/After create

| 0 |

Performance Schema通过metadata_locks表记录元数据锁新闻:

CURRENT _NUMBER_OF _BYTES_USED: 0

| accounts |

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

从上边表中的以身作则记录音信中,我们得以看看:

|
/data/mysqldata1/innodb_log/ib_logfile1
|wait/io/file/innodb/innodb_log_file | 2 |

1.数目库表级别对象等待事件总结

| prepared_statements_instances |

|2、performance_schema使用便捷入门

EVENT_NAME: wait/io/socket/sql/server_unix_socket

| events_transactions_summary_by_host_by_event_name |

  1. 启用performance_schema不会导致server的作为发生变化。例如,它不会变动线程调度机制,不会促成查询执行陈设(如EXPLAIN)发生变化
  2. 启用performance_schema之后,server会持续不间断地监测,花费相当的小。不会促成server不可用
  3. 在该兑现机制中未有扩大新的根本字或言辞,解析器不会转移
  4. 即使performance_schema的监测机制在里边对某事件实施监测失败,也不会影响server符合规律运行
  5. 如若在起先征集事件数量时相遇有其他线程正在针对这个事件消息进行询问,那么查询会优先执行事件数量的募集,因为事件数量的采访是贰个连连不断的长河,而寻找(查询)这个事件数量仅仅只是在急需查阅的时候才开始展览搜寻。也说不定某个事件数量永远都不会去搜寻
  6. 内需很简单地添加新的instruments监测点
  7. 澳门新莆京,instruments(事件采访项)代码版本化:若是instruments的代码爆发了转移,旧的instruments代码还足以继续做事。
  8. 专注:MySQL sys
    schema是一组对象(包涵有关的视图、存款和储蓄进程和函数),能够便宜地拜会performance_schema收集的数据。同时搜寻的数据可读性也更高(例如:performance_schema中的时间单位是阿秒,经过sys
    schema查询时会转换为可读的us,ms,s,min,hour,day等单位),sys
    schem在伍.7.x本子暗许安装

AVG_TIMER_READ_NORMAL: 0

DIGEST: 4fb483fe710f27d1d06f83573c5ce11c

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

*
已成功的等候事件将增进到events_waits_history和events_waits_history_long表中

MIN _TIMER_READ_ONLY: 57571000

| setup_consumers |

metadata_locks表字段含义如下:

1 row in set (0.00 sec)

PS:本连串作品所采取的数据库版本为 MySQL
官方 5.7.一柒版本

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

| events_stages_summary_by_user_by_event_name |

TIMER_END: 1582395491787190144

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

# memory_summary_by_host_by_event_name表

| events_stages_history_long |

MIN _TIMER_WAIT: 2971125

SUM_xxx:针对events_statements_*事件记录表中相应的xxx列实行总计。例如:语句总括表中的SUM_LOCK_TIME和SUM_ERRORS列对events_statements_current事件记录表中LOCK_TIME和E福特ExplorerRO冠道S列实行计算

后天,是还是不是认为上边包车型大巴牵线内容太过平淡呢?要是你如此想,那就对了,小编当年学习的时候也是那般想的。但现行反革命,对于怎么是performance_schema这一个难点上,比起更早以前更分明了呢?即便您还未曾打算要舍弃读书本文的话,那么,请跟随大家初叶进入到”边走边唱”环节呢!

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

| events_waits_summary_by_thread_by_event_name |

|wait/synch/mutex/sql/LOCK_plugin | 337
|

*
COUNT_READ,SUM_TIMER_READ,MIN_TIMER_READ,AVG_TIMER_READ,MAX_TIMER_READ,SUM_NUMBER_OF_BYTES_READ:那个列计算了拥有文件读取操作,包蕴FGETS,FGETC,FREAD和READ系统调用,还含有了那几个I/O操作的数码字节数

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

|13| 2261
|wait/synch/mutex/innodb/flush_list_mutex | 122208 |

# socket_summary_by_instance表

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

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

·凭借于连接表中国国投息的summary表在对那个连接表执行truncate时会同时被隐式地实践truncate,performance_schema维护着根据accounts,hosts或users总括各个风波总计表。那么些表在称呼包含:_summary_by_account,_summary_by_host,*_summary_by_user

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

_current表中种种线程只保留一条记下,且一旦线程完毕工作,该表中不会再记录该线程的轩然大波消息,_history表中记录每种线程已经举办到位的风云信息,但每一个线程的只事件音信只记录拾条,再多就会被遮住掉,*_history_long表中记录所无线程的事件消息,但总记录数据是一千0行,抢先会被遮住掉,将来我们查看一下历史表events_waits_history
中著录了什么:

SUM _TIMER_READ: 56688392

6rows inset ( 0. 00sec)

END_EVENT_ID: 60

OBJECT _INSTANCE_BEGIN: 2655350784

SUM _TIMER_WAIT: 0

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

EVENT_NAME: wait/io/socket/sql/client_connection

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

|
/data/mysqldata1/mydata/mysql/help_topic.ibd
|wait/io/file/innodb/innodb_data_file | 3 |

·metadata_locks:元数据锁的保有和乞请记录;

……

| file_summary_by_instance |

PS:对于mutexes、conditions和rwlocks,在运维时尽管允许修改配置,且布局能够修改成功,不过有部分instruments不见效,须求在运营时配置才会生效,如若您品尝着使用部分施用场景来追踪锁音讯,你大概在这几个instance表中不可能查询到对应的新闻。

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

OBJECT_INSTANCE_BEGIN: 955681576

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

SUM_ROWS_EXAMINED: 39718

|
wait/synch/mutex/sql/LOCK_global_system_variables |89|

admin@localhost : performance _schema 01:56:16> select * from
table_io _waits_summary _by_table where SUM _TIMER_WAIT!=0G;

SUM _TIMER_WAIT: 0

| wait/synch/mutex/mysys/THR_LOCK_open
|187|

FILE_NAME: /data/mysqldata1/innodb_ts/ibdata1

root@localhost : performance _schema 11:08:36> select * from
events_waits _summary_by _user_by _event_新普京娱乐,name limit 1G

|
events_statements_summary_by_user_by_event_name |

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

*
将COUNT_ALLOC和COUNT_FREE列重置,不分畛域复发轫计数(等于内存总计新闻以重置后的数值作为基准数据)

通过从INFORMATION_SCHEMA.tables表查询有何样performance_schema引擎的表:

STATEMENT_ID: 1

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

前些天,你可以在performance_schema下使用show
tables语句或许经过询问
INFOPRADOMATION_SCHEMA.TABLES表中performance_schema引擎相关的元数据来领悟在performance_schema下存在着怎么着表:

socket_instances表字段含义如下:

| events_statements_summary_by_program |

| 15 |291|
wait/synch/mutex/innodb/buf_dblwr_mutex |37392|

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

EVENT_NAME: statement/sql/select

|
events_transactions_summary_global_by_event_name |

·OBJECT_INSTANCE_BEGIN:prepare语句事件的instruments
实例内存地址。

| 等待事件计算表

MySQL的performance schema 用于监察和控制MySQL
server在三个较低级其余周转进度中的能源消耗、资源等待等状态,它有着以下特点:

instance表记录了怎么着项指标靶子被检查实验。那个表中著录了事件名称(提供收集效率的instruments名称)及其一些解释性的情事音讯(例如:file_instances表中的FILE_NAME文件名称和OPEN_COUNT文件打开次数),instance表首要有如下几个:

COUNT_STAR: 58

Rowsmatched: 3 Changed: 3 Warnings: 0

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

HOST: localhost

……

……

1 row in set (0.00 sec)

| Tables_in_performance_schema
(%setup%) |

……

SUM _NUMBER_OF _BYTES_ALLOC: 3296

mysqld运维以往,通过如下语句查看performance_schema是或不是启用生效(值为ON代表performance_schema已初步化成功且能够接纳了。尽管值为OFF表示在启用performance_schema时发出壹些错误。能够查看错误日志进行排查):

*************************** 3. row
***************************

1 row in set (0.00 sec)

“翻过那座山,你就能够看看一片海”

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

其它,依据帐户、主机、用户、线程聚合的种种等待事件计算表或然events_waits_summary_global_by_event_name表,假诺借助的连接表(accounts、hosts、users表)执行truncate时,那么重视的那些表中的总结数据也会同时被隐式truncate

| TABLE_NAME |

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

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

EVENT_NAME:
wait/synch/mutex/innodb/log_sys_mutex

3rows inset ( 0. 00sec)

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

|
events_statements_summary_by_host_by_event_name |

|admin | localhost |1| 1 |

# events_statements_summary_by_host_by_event_name表

|
events_statements_summary_by_thread_by_event_name |

该表允许利用TRUNCATE TABLE语句。只将总计列重置为零,而不是去除行。

……

11rows inset (0.00sec)

(4)rwlock_instances表

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

qogir_env@localhost :
performance_schema 06:17:23>
SELECT EVENT_NAME,COUNT_STAR FROM
events_waits_summary_global_by_event_name

·OBJECT_TYPE:元数据锁子系统中应用的锁类型(类似setup_objects表中的OBJECT_TYPE列值):有效值为:GLOBAL、SCHEMA、TABLE、FUNCTION、PROCEDURE、TQashqaiIGGE兰德普拉多(当前未利用)、EVENT、COMMIT、USE奔驰G级LEVEL LOCK、TABLESPACE、LOCKING SE帕杰罗VICE,USE福睿斯 LEVEL
LOCK值表示该锁是选用GET_LOCK()函数获取的锁。LOCKING
SERubiconVICE值表示使用锁服务获得的锁;

COUNT_STAR: 0

相关文章

发表评论

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

*
*
Website