新萄京娱乐网址2492777初相识|performance_schema全方位介绍(一)

|
memory_summary_by_user_by_event_name |

……

SUM _TIMER_WAIT: 0

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

     MySQL
Performance-Schema中一共包括55个表,主要分为几类:Setup表,Instance表,Wait
伊夫nt表,Stage 伊夫nt表Statement
伊芙nt表,Connection表和Summary表。上1篇小说已经首要讲了Setup表,那篇文章将会独家就每连串型的表做详细的讲述。

Instance表
   
 instance中要害包涵了伍张表:cond_instances,file_instances,mutex_instances,rwlock_instances和socket_instances。
(1)cond_instances:条件等待对象实例
表中著录了系统中使用的标准化变量的对象,OBJECT_INSTANCE_BEGIN为指标的内部存款和储蓄器地址。比如线程池的timer_cond实例的name为:wait/synch/cond/threadpool/timer_cond

(2)file_instances:文件实例
表中记录了系统中张开了文本的对象,包含ibdata文件,redo文件,binlog文件,用户的表文件等,比如redo日志文件:/u01/my3306/data/ib_logfile0。open_count展现当前文件张开的数据,假使重来未有展开过,不会油不过生在表中。

(3)mutex_instances:互斥同步对象实例
表中著录了系统中行使互斥量对象的装有记录,在那之中name为:wait/synch/mutex/*。比如打开文件的互斥量:wait/synch/mutex/mysys/TH揽胜极光_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-PORT消息,能够与运用接入起来。
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

Wait Event表
     
Wait表重要包蕴2个表,events_waits_current,events_waits_history和events_waits_history_long,通过thread_id+event_id能够唯一分明一条记下。current表记录了日前线程等待的风云,history表记录了各样线程近日守候的13个事件,而history_long表则记录了近年来全部线程发生的一千0个事件,那里的十和一千0都以能够安插的。那多少个表表结构同样,history和history_long表数据都源于current表。current表和history表中大概会有再次事件,并且history表中的事件都以到位了的,未有完毕的风浪不会进入到history表中。
THREAD_ID:线程ID
EVENT_ID:当前线程的风云ID,和THREAD_ID组成一个Primary Key。
END_EVENT_ID:当事件起头时,那一列棉被服装置为NULL。当事件停止时,再创新为当前的轩然大波ID。
SOU大切诺基CE:该事件爆发时的源码文件
TIMER_START, TIMER_END,
TIMER_WAIT:事件开端/结束和等候的时光,单位为飞秒(picoseconds)

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE视景况而定
对此联合对象(cond, mutex, rwlock),那些二个值均为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表首要涵盖2个表,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五爆发的三11个人字符串。借使为consumer表中平素不展开statement_digest选项,则为NULL。
DIGEST_TEXT:将讲话中值部分用问号取代,用于SQL语句归类。如果为consumer表中并未展开statement_digest选项,则为NULL。
CURRENT_SCHEMA:暗中同意的数量库名
OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE:保留字段,全体为NULL
ROWS_AFFECTED:影响的多少
ROWS_SENT:重临的记录数
ROWS_EXAMINED:读取的记录数据
CREATED_TMP_DISK_TABLES:成立物理目前表数目
CREATED_TMP_TABLES:创立权且表数目
SELECT_FULL_JOIN:join时,第叁个表为全表扫描的数量
SELECT_FULL_RANGE_JOIN:join时,引用表选择range格局扫描的数额
SELECT_RANGE:join时,第壹个表采纳range格局扫描的多寡
SELECT_SCAN:join时,第3个表位全表扫描的数目
SORT_ROWS:排序的记录数据
NESTING_EVENT_ID,NESTING_EVENT_TYPE,保留字段,为NULL。

Connection表
   
 Connection表记录了客户端的音讯,首要不外乎三张表:users,hosts和account表,accounts包蕴hosts和users的消息。
USER:用户名
HOST:用户的IP

Summary表
   
Summary表聚集了逐1维度的总括音信包涵表维度,索引维度,会话维度,语句维度和锁维度的计算音讯。
(1).wait-summary表
events_waits_summary_global_by_event_name
场所:按等待事件类型聚合,每一种事件一条记下。
events_waits_summary_by_新萄京娱乐网址2492777,instance
气象:按等待事件目的聚合,同一种等待事件,只怕有两个实例,每一种实例有例外的内部存款和储蓄器地址,由此
event_name+object_instance_begin唯壹分明一条记下。
events_waits_summary_by_thread_by_event_name
情形:按各样线程和事件来计算,thread_id+event_name唯一鲜明一条记下。
COUNT_STAOdyssey:事件计数
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
INSERT总括,相应的还有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中累计包涵5伍个表,主要分为几类:Setup表,Instance表,Wait
伊夫nt表,Stage Ev…

1row inset (0.00sec)

table_io_waits_summary_by_index_usage表:

# events_stages_summary_by_user_by_event_name表

|
events_stages_summary_by_thread_by_event_name |

·OBJECT_INSTANCE_BEGIN:mutex instruments实例的内部存款和储蓄器地址;

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

|
events_waits_summary_global_by_event_name |

*
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操作的数目字节数

COUNT_ALLOC: 103

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

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

EVENT_NAME: stage/sql/After create

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

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

从地方表中的以身作则记录消息中,我们能够观望,同样与等待事件类似,遵照用户、主机、用户+主机、线程等纬度进行分组与总计的列,那几个列的意思与等待事件类似,这里不再赘言。

2.2. 启用performance_schema

元数据锁instruments使用wait/lock/metadata/sql/mdl,默许未展开。

SUM _TIMER_WAIT: 0

| events_waits_history_long |

LOCK_TYPE: SHARED_READ

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

2.一. 检查当前数据库版本是或不是匡助

rwlock_instances表不容许选择TRUNCATE TABLE语句。

HOST: NULL

1 row in set (0.02 sec)

users表包括连接到MySQL
server的各样用户的连天音讯,每一个用户一行。该表将对准用户名作为唯1标志进行总计当前连接数和总连接数,server运行时,表的深浅会自动调节。
要显式设置该表大小,能够在server运营在此之前设置系统变量performance_schema_users_size的值。该变量设置为0时表示禁用users总计消息。

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

正文首先,差不离介绍了什么样是performance_schema?它能做哪些?

天性总计表

SUM _SELECT_FULL _RANGE_JOIN: 0

| Tables_in_performance_schema
(%file%) |

·当待处理的锁请求超时,会回去错误音讯(E奥德赛_LOCK_WAIT_TIMEOUT)给请求锁的对话,锁状态从PENDING更新为TIMEOUT;

events_statements_summary_by_digest表有和好额外的总计列:

从上文中大家早已领悟,performance_schema在五.柒.x会同以上版本中默许启用(五.六.x及其以下版本暗许关闭),要是要显式启用或关闭时,我们要求选用参数performance_schema=ON|OFF设置,并在my.cnf中实行配置:

table_io_waits_summary_by_table表:

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

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

AVG _TIMER_WAIT: 3496961251500

COUNT_STAR: 7

[mysqld]

·session_account_connect_attrs:记录当前对话及其相关联的别样会话的三番五次属性;

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

2、performance_schema使用便捷入门

三.文书I/O事件总括

1 row in set (0.00 sec)

二.1检查当前数据库版本是还是不是帮衬

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

AVG _TIMER_READ_WRITE: 1432022000

qogir_env@localhost : performance_schema 03:21:06> show tables from
performance_schema;

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

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

|
/home/mysql/program/share/english/errmsg.sys
|wait/io/file/sql/ERRMSG

*
file_summary_by_instance表:有额外的FILE_NAME、OBJECT_INSTANCE_BEGIN列,按照FILE_NAME、EVENT_NAME列进行分组,与file_summary_by_event_name
表相比,file_summary_by_instance表多了FILE_NAME和OBJECT_INSTANCE_BEGIN字段,用于记录具体的磁盘文件有关音信。

MAX _TIMER_READ_ONLY: 57571000

12rows inset (0.01sec)

总是计算信息表允许利用TRUNCATE
TABLE。它会同时删除总括表中从未连接的帐户,主机或用户对应的行,重新初始化有连日的帐户,主机或用户对应的行的并将其余行的CUEnclaveRENT_CONNECTIONS和TOTAL_CONNECTIONS列值。

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

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

* _platform:客户端机器平台(例如,x八陆_64)

*
其它,按照帐户,主机,用户或线程分类总计的内部存款和储蓄器计算表或memory_summary_global_by_event_name表,假若在对其借助的accounts、hosts、users表试行truncate时,会隐式对这个内部存款和储蓄器总括表试行truncate语句

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

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

*
将COUNT_ALLOC和COUNT_FREE列重新恢复设置,一视同仁复初步计数(等于内部存款和储蓄器总计音讯以重新初始化后的数值作为标准数据)

| events_statements_history |

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

| events_stages_summary_by_host_by_event_name |

summary表提供具备事件的汇聚新闻。该组中的表以分化的格局集中事件数量(如:按用户,按主机,按线程等等)。例如:要翻开哪些instruments占用最多的时刻,能够因而对events_waits_summary_global_by_event_name表的COUNT_STAR或SUM_TIMER_WAIT列实行询问(那两列是对事件的记录数实施COUNT(*)、事件记录的TIMER_WAIT列执行SUM(TIMER_WAIT)计算而来),如下:

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

COUNT_STAR: 7

本篇内容到这边就象是尾声了,相信广大人都感到,大家超越51%时候并不会一向利用performance_schema来询问质量数据,而是使用sys
schema下的视图替代,为啥不直接攻读sys schema呢?那你明白sys
schema中的数据是从哪儿吐出来的吧?performance_schema
中的数据实际上主要是从performance_schema、information_schema中取得,所以要想玩转sys
schema,周详了然performance_schema不能缺少。别的,对于sys
schema、informatiion_schema甚至是mysql
schema,大家承接也会推出区别的层层文章分享给大家。

mutex_instances.LOCKED_BY_THREAD_ID和rwlock_instances.WRITE_LOCKED_BY_THREAD_ID列对于排查品质瓶颈或死锁难题至关重要。

events_waits_summary_by_user_by_event_name表:按照列EVENT_NAME、USE哈弗进行分组事件新闻

| accounts |

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

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

qogir_env@localhost :
performance_schema 03:13:22>
SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES

OPEN_COUNT:文件当前已展开句柄的计数。假使文件张开然后倒闭,则张开叁遍,但OPEN_COUNT列将加壹然后减①,因为OPEN_COUNT列只总括当前已开荒的文书句柄数,已关门的文本句柄会从中减去。要列出server中当前开采的具备文件新闻,能够应用where
WHERE OPEN_COUNT> 0子句进行查看。

EVENT_NAME: statement/sql/select

| EVENT_NAME |COUNT_STAR |

SOURCE: sql_parse.cc:6031

*
LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED将重新初始化为CU奥迪Q5RENT_NUMBER_OF_BYTES_USED列值

|
events_transactions_summary_by_thread_by_event_name |

·EXTERNAL_LOCK:在蕴藏引擎等第使用的表锁。有效值为:READ
EXTE科雷傲NAL、W景逸SUVITE EXTE奥迪Q7NAL。

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

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

OWNER_THREAD_ID: 48

COUNT_STAR: 0

|
memory_summary_global_by_event_name |

1row inset ( 0. 00sec)

MIN _TIMER_WAIT: 0

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

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

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

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

OBJECT_NAME: test

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

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

·COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT:那些列总结全数socket读写操作的次数和岁月信息

| events_statements_summary_by_thread_by_event_name |

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

1 row in set (0.00 sec)

| events_statements_summary_by_program |

SPINS: NULL

下卷将为我们分享 《复制状态与变量记录表 |
performance_schema全方位介绍》 ,多谢您的开卷,大家不见不散!再次来到今日头条,查看更加多

……

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

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

EVENT_NAME: stage/sql/After create

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

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

MAX_TIMER_WAIT: 80968744000

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

……

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

|
events_waits_summary_by_account_by_event_name |

COUNT_STAR: 1

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

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

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

MIN _TIMER_READ_WRITE: 87193000

|
events_statements_summary_by_host_by_event_name |

rwlock_instances表字段含义如下:

| 温馨提示

THREAD_ID: 4

·COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_W奥迪Q5ITE:那几个列总结了装有发送操作(socket的SEND、SENDTO、SENDMSG类型操作,即以server为参考的socket写入数据的操作)相关的次数、时间、接收字节数等音信

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

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

小编们先来探视表中著录的总计音讯是什么样子的。

SUM _CREATED_TMP_TABLES: 10

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

COUNT_STAR: 213055844

SCHEMA_NAME: NULL

| cond_instances |

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

MAX _TIMER_WAIT: 0

OBJECT_TYPE: NULL

AVG _TIMER_READ: 56688392

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

小编:

|NULL | NULL |41| 45 |

| prepared_statements_instances |

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

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

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

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

在服务器端面,会对连接属性数据举行长度检查:

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

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

PS:socket总结表不会总计空闲事件生成的等候事件音讯,空闲事件的守候音信是记录在守候事件总计表中张开总计的。

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

|
events_stages_summary_global_by_event_name |

OWNER _THREAD_ID: 46

AVG_TIMER_WAIT: 4426693000

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

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

| 语句事件总括表

等候事件记录表,与话语事件类型的有关记录表类似:

performance_schema通过如下表来记录相关的锁新闻:

COUNT_FREE: 103

2.2. 启用performance_schema

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

Rows matched: 377 Changed: 377 Warnings: 0

……

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

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

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

AVG_TIMER_EXECUTE: 0

*
内存instruments在setup_instruments表中颇具memory/code_area/instrument_name格式的称谓。但默许意况下大许多instruments都被剥夺了,暗许只开启了memory/performance_schema/*开头的instruments

……

OBJECT _INSTANCE_BEGIN: 139968890586816

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

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

EVENT_NAME: wait/io/socket/sql/client_connection

AVG _TIMER_WAIT: 0

|Transactions | XA |Savepoints
|

·放飞元数据锁时,对应的锁消息行被删除;

COUNT_STAR: 0

NESTING_EVENT_TYPE: NULL

* _client_license:连接器许可证类型

SUM _TIMER_READ_ONLY: 57571000

| events_stages_history |

| qfsys |1| 1 |

performance_schema把内部存储器事件总结表也依据与等待事件总括表类似的规则进行归类总括。

#
该事件音信表示线程ID为四的线程正在等候innodb存款和储蓄引擎的log_sys_mutex锁,那是innodb存款和储蓄引擎的三个互斥锁,等待时间为65664阿秒(*_ID列表示事件源于哪个线程、事件编号是多少;EVENT_NAME表示检查实验到的有血有肉的始末;SOU安德拉CE表示这几个检查测试代码在哪些源文件中以及行号;计时器字段TIME福特Explorer_START、TIMER_END、TIMER_WAIT分别表示该事件的初始时间、截至时间、以及总的开销时间,假诺该事件正在周转而尚未终结,那么TIMEPAJERO_END和TIMER_WAIT的值展现为NULL。注:计时器总计的值是类似值,并不是一点壹滴规范)

……

1 row in set (0.00 sec)

mysqld运转之后,通过如下语句查看performance_schema是不是启用生效(值为ON表示performance_schema已起首化成功且能够行使了。如若值为OFF表示在启用performance_schema时发生壹些错误。能够查看错误日志举办排查):

从客户端发送到服务器的接二连三属性数据量存在限制:客户端在连接在此之前客户端有三个和谐的定位长度限制(不可配置)、在客户端连接server时服务端也有三个原则性长度限制、以及在客户端连接server时的接连属性值在存入performance_schema中时也有贰个可布署的尺寸限制。

USER: root

root@localhost : performance_schema
12:18:46> show tables like
‘%setup%’;

MAX_TIMER_EXECUTE: 0

1 row in set (0.00 sec)

……

新澳门萄京娱乐场官网 1

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

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

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

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

| variables_by_thread |

当客户端与server端建立连接时,performance_schema使用符合种种表的绝无仅有标记值来鲜明每一个连接表中什么开始展览记录。假设缺点和失误对应标记值的行,则新增增添1行。然后,performance_schema会大增该行中的CUCRUISERRENT_CONNECTIONS和TOTAL_CONNECTIONS列值。

PS:内部存储器总计表不分包计时消息,因为内部存款和储蓄器事件不辅助时间消息收罗。

| 0 |

MAX_TIMER_WAIT: 18446696808701862260

内部存款和储蓄器大小计算音讯有助于掌握当前server的内存消耗,以便及时开始展览内部存款和储蓄器调节。内部存款和储蓄器相关操作计数有助于精通当前server的内部存款和储蓄器分配器的总体压力,及时精晓server品质数据。例如:分配单个字节一百万次与单次分配一百万个字节的性质开销是见仁见智的,通过追踪内部存储器分配器分配的内部存款和储蓄器大小和分红次数就足以明白两岸的差距。

|
events_waits_summary_by_user_by_event_name |

| Tables_in_performance_schema (%table%summary%) |

*
COUNT_ALLOC,COUNT_FREE:对内部存款和储蓄器分配和自由内存函数的调用总次数

qogir_env@localhost :
performance_schema 03:13:10>
SHOW VARIABLES LIKE ‘performance_schema’;

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

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

| events_statements_current |

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

*
假使三个线程开启了搜聚成效,不过内部存储器相关的instruments未有启用,则该内存释放操作不会被监察和控制到,总结数据也不会发生更动

END_EVENT_ID: 60

·当互斥体被灭绝时,从mutex_instances表中剔除相应的排外体行。

罗小波·沃趣科技(science and technology)尖端数据库技巧专家

| wait/io/file/myisam/kfile |411193611|

·execute步骤:语法EXECUTE stmt_name[USING @var_name [,
@var_name] …],示例:execute stmt;
重回实行结果为一,此时在prepared_statements_instances表中的计算音信会开始展览翻新;

MAX _TIMER_WAIT: 0

11rows inset (0.00sec)

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

MIN_TIMER_WAIT:给定计时事件的微乎其微等待时间

| users |

·events_waits_current:查看线程正在等候什么rwlock;

| 导语

| 0 |

cond_instances表字段含义如下:

*
事务所占用的财富需求多少也只怕会因工作隔开品级有所出入(例如:锁能源)。不过:每种server或然是使用同一的割裂品级,所以不单独提供隔断等级相关的总结列

| wait/synch/mutex/mysys/LOCK_alarm
|145126935|

从地点表中的笔录消息我们能够见到(与公事I/O事件总计类似,两张表也分别根据socket事件类型总结与服从socket
instance实行总括)

1 row in set (0.00 sec)

performance_schema完结机制遵从以下设计指标:

对此代码中的每一个互斥体,performance_schema提供了以下音讯:

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

| events_waits_current |

·STATEMENT_NAME:对于二进制协议的讲话事件,此列值为NULL。对于文本协议的话语事件,此列值是用户分配的表面语句名称。例如:PREPARE
stmt FROM’SELECT 一’;,语句名叫stmt。

SUM_NO_INDEX_USED: 42

|wait/synch/mutex/mysys/THR_LOCK::mutex | 89 |

·已予以的锁(显示怎么会话具有当前元数据锁);

注意:那么些表只针对阶段事件新闻进行计算,即含有setup_instruments表中的stage/%上马的采撷器,每一个阶段事件在各样表中的总计记录行数供给看如何分组(例如:根据用户分组总括的表中,有稍许个活泼用户,表中就会有微微条同样搜聚器的笔录),此外,总括计数器是还是不是见效还需求看setup_instruments表中相应的级差事件收罗器是不是启用。

3rows inset (0.01sec)

主要编辑:

MIN _TIMER_WAIT: 57571000

|
memory_summary_by_account_by_event_name |

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

USER: root

|导
以前到现在,当自家还在品味着系统地球科学习performance_schema的时候,通过在网上各类搜索资料举办学习,但很遗憾,学习的职能并不是很精晓,许多标称类似
“深切浅出performance_schema”
的小说,基本上都以那种动不动就贴源码的品格,然后深刻了之后却出不来了。对系统学习performance_schema的功用有限。

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

MAX _TIMER_WAIT: 2427645000

5rows inset (0.01sec)

该表允许利用TRUNCATE
TABLE语句。只将总计列重新载入参数为零,而不是去除行。对该表实施truncate还会隐式truncate
table_io_waits_summary_by_index_usage表

MIN _TIMER_WAIT: 0

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

·file_instances:文件对象实例;

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

| wait/io/file/sql/binlog_index
|1385291934|

(3)mutex_instances表

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

21 rows inset (0.00 sec)

咱俩先来探望表中记录的总计信息是如何体统的。

COUNT_STAR: 59

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

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

……

……

注意:rwlock_instances表中的音讯只好查看到具备写锁的线程ID,然而无法查看到全体读锁的线程ID,因为写锁W奥迪Q三ITE_LOCKED_BY_THREAD_ID字段记录的是线程ID,读锁唯有二个READ_LOCKED_BY_COUNT字段来记录读锁被某个个线程持有。

# 假设须求总结内存事件音信,供给开启内部存款和储蓄器事件搜聚器

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

·socket_summary_by_event_name:针对种种socket I/O
instruments,这一个socket操作相关的操作次数、时间和殡葬接收字节音信由wait/io/socket/*
instruments发生(那里的socket是指的当前活跃的连接创设的socket实例)

# memory_summary_global_by_event_name表

| setup_objects |

| NAME |OBJECT_INSTANCE_BEGIN | LOCKED_BY_THREAD_ID |

USER: root

| Tables_in_performance_schema
(%statement%) |

| USER |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |

SUM _TIMER_WAIT: 0

| file_summary_by_event_name |

mutex_instances表字段含义如下:

MIN _TIMER_WAIT: 0

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

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

……

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

下边对那几个表分别张开认证。

AVG _TIMER_WAIT: 0

Database changed

performance_schema通过table_handles表记录表锁新闻,以对当前各样张开的表所持有的表锁进行追踪记录。table_handles输出表锁instruments收罗的剧情。那个新闻体现server中已展开了哪些表,锁定形式是什么样以及被哪些会话持有。

SUM _TIMER_WAIT: 0

罗小波·沃趣科技(science and technology)尖端数据库技巧专家

| NAME |OBJECT_INSTANCE_BEGIN |

# events_stages_summary_global_by_event_name表

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

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

各类内存计算表都有如下计算列:

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

·当呼吁元数据锁无法马上得到时,将插入状态为PENDING的锁音讯行;

LOW _NUMBER_OF _BYTES_USED: 0

| events_stages_current |

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

PS:等待事件总括表允许利用TRUNCATE
TABLE语句。

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

1row inset ( 0. 00sec)

COUNT_STAR: 0

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

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

1 row in set (0.00 sec)

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

MIN _TIMER_READ: 56688392

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

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

# table_io_waits_summary_by_table表

| Tables_in_performance_schema (%events_waits_summary%) |

|4|
341 |wait/synch/mutex/innodb/fil_system_mutex | 84816 |

·SUM_xxx:其余的SUM_xxx先导的列与语句总计表中的音讯一致,语句总结表后续章节会详细介绍。

*
COUNT_STATEMENTS,SUM_STATEMENTS_WAIT,MIN_STATEMENTS_WAIT,AVG_STATEMENTS_WAIT,MAX_STATEMENTS_WAIT:关于存款和储蓄程序试行时期调用的嵌套语句的总计消息

|
wait/synch/mutex/sql/THD::LOCK_thd_data |115|

AVG_TIMER_READ: 0

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

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

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

SUM _SORT_MERGE_PASSES: 0

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

MIN_TIMER_WAIT: 0

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

| setup_timers |

经过对以下三个表实践查询,能够兑现对应用程序的监督或DBA能够检验到关系互斥体的线程之间的瓶颈或死锁新闻(events_waits_current能够查阅到当前正在等候互斥体的线程音讯,mutex_instances能够查看到近日有个别互斥体被哪些线程持有)。

1 row in set (0.00 sec)

MySQL的performance schema 用于监察和控制MySQL
server在四个较低档其余运作进度中的能源消耗、财富等待等情况,它具有以下特征:

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

AVG _TIMER_WAIT: 0

|performance_schema | ON |

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

events_waits_summary_by_instance表:按照列EVENT_NAME、OBJECT_INSTANCE_BEGIN实行分组事件消息。假若贰个instruments(event_name)创立有八个实例,则种种实例都享有唯一的OBJECT_INSTANCE_BEGIN值,因而种种实例会进行单独分组

| THREAD_ID |EVENT_ID | EVENT_NAME |TIMER_WAIT |

OBJECT _INSTANCE_BEGIN: 2655350784

SUM _TIMER_WAIT: 0

……

performance_schema提供了针对性prepare语句的监察和控制记录,并依据如下方法对表中的内容开始展览管理。

OBJECT_NAME: ps_setup_enable_consumer

|
events_statements_summary_by_thread_by_event_name |

·当从前请求无法即时得到的锁在那事后被授予时,其锁新闻行状态更新为GRANTED;

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

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

OWNER_OBJECT_SCHEMA: NULL

events_statements_summary_by_user_by_event_name:依照每种用户名和事件名称进行总括的Statement事件

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

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

……

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

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

| events_stages_summary_by_thread_by_event_name |

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

AVG_TIMER_WAIT: 24366870

| events_waits_summary_global_by_event_name |

|
events_stages_summary_by_user_by_event_name |

FILE_NAME: /data/mysqldata1/innodb_ts/ibdata1

# events_transactions_summary_by_account_by_event_name表

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

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

AVG _TIMER_WAIT: 1235672000

|
memory_summary_by_thread_by_event_name |

| Tables_in_performance_schema (%socket%summary%) |

MAX _TIMER_READ_WRITE: 2427645000

***************************

EVENT_NAME: wait/io/file/innodb/innodb_data_file

*
SUM_NUMBER_OF_BYTES_ALLOC和SUM_NUMBER_OF_BYTES_FREE列重新初始化与COUNT_ALLOC和COUNT_FREE列重新初始化类似

| file_instances |

咱俩先来探望表中记录的计算音信是何等体统的。

| events_transactions_summary_by_host_by_event_name |

|wait/synch/mutex/mysys/THR_LOCK_malloc | 1530083250 |

MAX_TIMER_READ_NORMAL: 0

咱俩先来看看那么些表中记录的总括新闻是怎么样样子的。

| wait/synch/mutex/sql/LOCK_open
|88|

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

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

| FILE_NAME |EVENT_NAME | OPEN_COUNT |

| table_io_waits_summary_by_table |#
遵照各个表展开总结的表I/O等待事件

MIN _TIMER_READ_ONLY: 57571000

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

OWNER_OBJECT_TYPE: NULL

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

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

SUM _TIMER_READ: 56688392

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

EVENT_NAME:
wait/synch/mutex/innodb/log_sys_mutex

# file_summary_by_instance表

SUM_ERRORS: 2

| setup_instruments |

·PROCESSLIST_ID:会话的连日标记符,与show
processlist结果中的ID字段同样;

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

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

从表中的笔录内容能够看出,根据库xiaoboluo下的表test实行分组,总括了表相关的等候事件调用次数,计算、最小、平均、最大延迟时间音信,利用那些新闻,我们能够大约明白InnoDB中表的造访作用名次总计情状,一定程度上反应了对存款和储蓄引擎接口调用的成效。

从下边表中的言传身教记录消息中,大家得以看出,同样与等待事件类似,依据用户、主机、用户+主机、线程等纬度举行分组与总括的列,那些列的含义与等待事件类似,那里不再赘述,但对此事情总括事件,针对读写事务和只读事务还独立做了总计(xx_READ_WRITE和xx_READ_ONLY列,只读事务必要安装只读事务变量transaction_read_only=on才会议及展览开总结)。

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

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

* SUM_NUMBER_OF_BYTES_ALLOC:增加N

NESTING_EVENT_ID: NULL

从地点表中的笔录信息我们能够看出:

EVENT_NAME: transaction

产品:沃趣科学和技术

1 row in set (0.00 sec)

大家先来看望这个表中著录的总计音讯是何许样子的(由于单行记录较长,这里只列出events_statements_summary_by_account_by_event_name
表中的示例数据,别的表的言传身教数据省略掉一部分雷同字段)。

| events_waits_history |

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

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

| events_transactions_history_long
|

OBJECT_TYPE: TABLE

1 row in set (0.00 sec)

使用
INFORMATION_SCHEMA.ENGINES表来询问你的数据库实例是不是帮衬INFOLANDMATION_SCHEMA引擎

performance_schema怎样管理metadata_locks表中著录的始末(使用LOCK_STATUS列来代表每种锁的景观):

SUM_xxx:针对events_statements_*事件记录表中相应的xxx列进行总括。例如:语句总结表中的SUM_LOCK_TIME和SUM_ERRORS列对events_statements_current事件记录表中LOCK_TIME和E凯雷德ROLANDS列进行总结

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

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

LOW_COUNT_USED: 0

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

3rows inset ( 0. 00sec)

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

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

贰. 老是属性总括表

# events_statements_summary_by_account_by_event_name表

| Tables_in_performance_schema
(%stage%) |

socket_instances表不允许接纳TRUNCATE TABLE语句。

SUM_LOCK_TIME: 26026000000

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

* _platform:客户端机器平台(例如,x8陆_64)

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

然后,简介了什么样快速上手使用performance_schema的方法;

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

5rows inset ( 0. 00sec)

| events_statements_history_long
|

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

1 row in set (0.00 sec)

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

[Warning] Connection attributes oflength N were truncated

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

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;

COUNT_STAR: 24

注意:这么些表只针对等候事件音信实行总结,即含有setup_instruments表中的wait/%起来的征集器+
idle空闲采撷器,各种等待事件在种种表中的总结记录行数要求看怎么分组(例如:遵照用户分组总结的表中,有微微个活泼用户,表中就会有些许条同样采撷器的笔录),其它,总结计数器是或不是见效还亟需看setup_instruments表中相应的等候事件搜罗器是还是不是启用。

| NO |NO | NO |

可透过如下语句查看:

……

| file_summary_by_instance |

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

……

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

大家先来看望表中著录的总括新闻是如何样子的。

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

相关文章

网站地图xml地图