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

MySQL的performance schema 用于监察和控制MySQL
server在三个极低等其他运作进度中的能源消耗、财富等待等景色,它兼具以下特点:

该表包括关于内部和表面锁的消息:

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

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

Instance表
   
 instance中任重(英文名:rèn zhòng)而道远涵盖了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-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表重要包罗3个表,events_waits_current,events_waits_history和events_waits_history_long,通过thread_id+event_id可以独一鲜明一条记下。current表记录了脚下线程等待的平地风波,history表记录了每种线程如今守候的十二个事件,而history_long表则记录了多年来拥有线程爆发的10000个事件,这里的10和一千0都以足以布署的。那多个表表结构一样,history和history_long表数据都来源于current表。current表和history表中也许会有再度事件,并且history表中的事件都以实现了的,未有终结的风云不会投入到history表中。
THREAD_ID:线程ID
EVENT_ID:当前线程的风浪ID,和THREAD_ID组成二个Primary Key。
END_EVENT_ID:当事件初叶时,这一列棉被服装置为NULL。当事件停止时,再次创下新为眼下的平地风波ID。
SOURCE:该事件时有爆发时的源码文件
TIMER_START, TIMER_END,
TIMER_WAIT:事件始于/停止和等待的日子,单位为飞秒(picoseconds)

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE视情形而定
对于联合对象(cond, mutex, rwlock),那几个3个值均为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表紧要含有3个表,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
SOURCE:源码地点
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能够唯一明确一条记下。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时,第4个表位全表扫描的数码
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独一鲜明一条记下。
events_waits_summary_by_thread_by_event_name
气象:按种种线程和事件来计算,thread_id+event_name独一分明一条记下。
COUNT_STA奥迪TT:事件计数
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:最终四个口舌试行的日子
情景:用于总结某一段时间内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中累计富含51个表,首要分为几类:Setup表,Instance表,Wait
Event表,Stage Ev…

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

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

2.2. 启用performance_schema

SUM_WARNINGS: 0

[mysqld]

·COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE:试行prepare语句时的连锁总结数据。

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

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

QueryOK, 3 rowsaffected(0.04sec)

从地方表中的笔录新闻大家能够见见(与公事I/O事件总结类似,两张表也独家依据socket事件类型计算与听从socket
instance进行总结)

终极,简介了performance_schema中由哪些表组成,那么些表大约的成效是怎么着。

OBJECT _INSTANCE_BEGIN: 2658004160

qogir_env@localhost :
performance_schema 02:41:54>
show engines;

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

开发等待事件的搜聚器配置项开关,必要修改setup_instruments
配置表中对应的收集器配置项

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

|
events_waits_summary_by_thread_by_event_name |

从客户端发送到服务器的连天属性数据量存在限制:客户端在连接此前客户端有七个和好的定位长度限制(不可配置)、在客户端连接server时服务端也会有叁个长久长度限制、以及在客户端连接server时的连接属性值在存入performance_schema中时也许有贰个可安顿的长度限制。

  1. 提供了一种在数据库运转时实时检查server的在那之中推市价况的点子。performance_schema
    数据库中的表使用performance_schema存款和储蓄引擎。该数据库入眼关怀数据库运营进度中的质量相关的数量,与information_schema不同,information_schema首要关心server运转进度中的元数据音讯
  2. performance_schema通过监视server的平地风波来促成监视server内部运市场价格况,
    “事件”正是server内部活动中所做的别的业务以及相应的小时开支,利用这么些音信来判断server中的相关能源消耗在了何地?一般的话,事件能够是函数调用、操作系统的守候、SQL语句施行的阶段(如sql语句施行进度中的parsing

    sorting阶段)大概全部SQL语句与SQL语句集合。事件的募集能够实惠的提供server中的相关存款和储蓄引擎对磁盘文件、表I/O、表锁等能源的同步调用音讯。
  3. performance_schema中的事件与写入二进制日志中的事件(描述数据修改的events)、事件布置调解程序(那是一种存款和储蓄程序)的风云分歧。performance_schema中的事件记录的是server实行有些活动对少数能源的成本、耗费时间、那一个移动奉行的次数等景色。
  4. performance_schema中的事件只记录在本土server的performance_schema中,其下的那些表中数据产生变化时不会被写入binlog中,也不会透过复制机制被复制到其余server中。
  5. 此时此刻活蹦乱跳事件、历史事件和事件摘要相关的表中记录的信息。能提供有个别事件的实践次数、使用时间长度。进而可用来深入分析有些特定线程、特定指标(如mutex或file)相关联的位移。
  6. PERFORMANCE_SCHEMA存款和储蓄引擎使用server源代码中的“检查评定点”来贯彻事件数量的征集。对于performance_schema达成机制自己的代码未有有关的单独线程来检验,那与其他效能(如复制或事件布置程序)分歧
  7. 搜集的平地风波数量存款和储蓄在performance_schema数据库的表中。那几个表能够选用SELECT语句询问,也得以使用SQL语句更新performance_schema数据库中的表记录(如动态修改performance_schema的setup_*开班的几个布局表,但要注意:配置表的改换会马上生效,那会影响多少搜聚)
  8. performance_schema的表中的数目不会漫长化存款和储蓄在磁盘中,而是保存在内部存款和储蓄器中,一旦服务注重启,那几个数量会放任(包蕴配置表在内的满贯performance_schema下的有着数据)
  9. MySQL帮忙的保有平桃园事件监察和控制成效都可用,但不一样平新竹用于总计事件时间支出的反应计时器类型恐怕会具有差别。

table_lock_waits_summary_by_table表:

本文首先,差不离介绍了何等是performance_schema?它能做什么?

EVENT_NAME: wait/io/socket/sql/server_unix_socket

|
events_transactions_summary_by_thread_by_event_name |

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

|
events_transactions_summary_by_account_by_event_name |

SUM _TIMER_WAIT: 195829830101250

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

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

1row inset (0.00sec)

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

|
events_stages_summary_by_host_by_event_name |

mutex_instances.LOCKED_BY_THREAD_ID和rwlock_instances.WRITE_LOCKED_BY_THREAD_ID列对于排查品质瓶颈或死锁难点首要性。

| setup_actors |

OWNER_OBJECT_SCHEMA: NULL

| Tables_in_performance_schema
|

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

| EVENT_NAME |COUNT_STAR |

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

| Tables_in_performance_schema
(%stage%) |

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

| events_stages_history |

accounts表字段含义如下:

主要编辑:

·prepare语句推行:为已检查测量检验的prepare语句实例实施COM_STMT_EXECUTE或SQLCOM_PREPARE命令,同一时间会更新prepare_statements_instances表中对应的行消息。

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

各类套接字计算表都富含如下计算列:

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

MAX_TIMER_READ: 9498247500

| Variable_name |Value |

笔者们先来探视表中著录的总结音信是怎样体统的。

开垦等待事件的保存表配置开关,修改修改setup_consumers
配置表中对应的配备i向

MAX_TIMER_EXECUTE: 0

|
events_transactions_summary_global_by_event_name |

| HOST |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |

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

·file_summary_by_instance:依据每一种文件实例(对应现实的各类磁盘文件,比方:表sbtest1的表空间文件sbtest1.ibd)实行总括的文书IO等待事件

专门的学问事件记录表,记录事务相关的风浪的表,与话语事件类型的相关记录表类似:

4rows inset ( 0. 00sec)

PS:本类别小说所运用的数据库版本为 MySQL
官方 5.7.17版本

原标题:数据库对象事件与性格总括 | performance_schema全方位介绍(五)

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

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

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

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

qogir_env@localhost :
performance_schema 03:53:51>
show tables like ‘events_wait%’;

·COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_WLX570ITE:那一个列计算了具备发送操作(socket的SEND、SENDTO、SENDMSG类型操作,即以server为参照他事他说加以考察的socket写入数据的操作)相关的次数、时间、接收字节数等新闻

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

·当server中部分代码创造了多个互斥量时,在mutex_instances表中会增多一行对应的互斥体新闻(除非不能够再制造mutex
instruments
instance就不会增多行)。OBJECT_INSTANCE_BEGIN列值是互斥体的有一无二标志属性;

今昔,大家驾驭了在 MySQL 5.7.17
版本中,performance_schema
下一共有87张表,那么,那87帐表都是贮存在什么数据的啊?我们怎么样选拔他们来查询我们想要查看的数额吧?先别焦急,大家先来探视这几个表是什么样分类的。

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

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

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

| Tables_in_performance_schema
(%setup%) |

| USER |HOST | CURRENT_CONNECTIONS |TOTAL_CONNECTIONS |

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

rwlock_instances表列出了server实施rwlock
instruments时performance_schema所见的具备rwlock(读写锁)实例。rwlock是在代码中使用的一路机制,用于强制在给按期期内线程能够服从某些准绳访谈一些公共财富。能够认为rwlock爱慕着这个能源不被其余线程随便抢占。访谈情势能够是分享的(几个线程能够相同的时间具有分享读锁)、排他的(同期独有三个线程在加以时间能够享有排他写锁)或分享独占的(某些线程持有排他锁定期,同有时候允许其余线程实践不相同性读)。分享独占访问被称为sxlock,该访问格局在读写场景下能够巩固并发性和可扩充性。

1 row in set (0.02 sec)

2rows inset ( 0. 00sec)

|
events_statements_summary_by_thread_by_event_name |

作者们先来探视表中著录的总括消息是怎么体统的。

| users |

* mutex_instances表中的THREAD_ID列突显该互斥映今后被哪些线程持有。

|1、**什么是performance_schema**

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

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

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

5rows inset (0.00sec)

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

qogir_env@localhost :
performance_schema 03:55:30>
show tables like ‘events_transaction%’;

OWNER_THREAD_ID: 48

原标题:初相识|performance_schema全方位介绍(一)

socket_instances表列出了连年到MySQL
server的生意盎然接连的实时快速照相音信。对于各样连接到mysql
server中的TCP/IP或Unix套接字文件三番五次都会在此表中记录一行消息。(套接字计算表socket_summary_by_event_name和socket_summary_by_instance中提供了一些外加音讯,举个例子像socket操作以及网络传输和吸收接纳的字节数)。

21 rows inset (0.00 sec)

·当行消息中CU奥德赛RENT_CONNECTIONS
字段值大于0时,推行truncate语句不会删除这个行,TOTAL_CONNECTIONS字段值被重新初始化为CUHavalRENT_CONNECTIONS字段值;

11rows inset (0.00sec)

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

|
memory_summary_by_user_by_event_name |

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

|
events_stages_summary_by_thread_by_event_name |

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

8rows inset (0.00sec)

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

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

COUNT_READ_NORMAL: 0

……

(5) socket_instances表

|
events_statements_summary_by_program |

(1)metadata_locks表

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

·IP:客户端IP地址。该值能够是IPv4或IPv6地址,也足以是空白,表示那是叁个Unix套接字文件一而再;

87rows inset (0.00sec)

OBJECT _INSTANCE_BEGIN: 2655351104

1row inset (0.00sec)

| 4 |_client_version | 5.7.18 |3|

| events_statements_summary_by_digest
|

·对于TCP/IP
server套接字(server_tcpip_socket)的server端监听器,端口始终为主端口(举个例子3306),IP始终为0.0.0.0;

qogir_env@localhost :
performance_schema 03:58:27>
show tables like ‘%file%’;

| Tables_in_performance_schema (%socket%summary%) |

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

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

summary表提供具备事件的汇总音信。该组中的表以差异的方法集中事件数量(如:按用户,按主机,按线程等等)。比如:要翻开哪些instruments占用最多的日子,能够由此对events_waits_summary_global_by_event_name表的COUNT_STAR或SUM_TIMER_WAIT列举行查询(这两列是对事件的记录数实践COUNT(*)、事件记录的TIME揽胜极光_WAIT列执行SUM(TIMER_WAIT)统计而来),如下:

OBJECT_NAME: test

5rows inset (0.01sec)

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

TIMER_START: 1582395491787124480

·socket_summary_by_event_name:针对各样socket I/O
instruments,那么些socket操作相关的操作次数、时间和发送接收字节音讯由wait/io/socket/*
instruments发生(这里的socket是指的近来活蹦乱跳的连年创建的socket实例)

|
events_statements_summary_by_account_by_event_name |

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

Rowsmatched: 323 Changed: 0 Warnings: 0

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

动态对performance_schema进行配备的配置表:

3rows inset ( 0. 00sec)

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

(2)file_instances表

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

凭借须求锁的线程数以及所必要的锁的习性,访谈形式有:独占格局、共享独占情势、分享形式、也许所乞求的锁不可能被全体予以,要求先等待别的线程完结并释放。

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

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

ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

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

|4|
343 |wait/io/file/innodb/innodb_log_file | 544126864 |

AVG_TIMER_WAIT: 24366870

| file_summary_by_instance |

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

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

*
events_waits_current表中得以查看到当下正值等候互斥体的线程时间音信(举个例子:TIME冠道_WAIT列表示曾经等待的日子)

当大家来看PE奔驰M级FORMANCE_SCHEMA
对应的Support
字段输出为YES时就表示大家当前的数据库版本是永葆performance_schema的。但驾驭咱们的实例辅助performance_schema引擎就能够利用了啊?NO,很缺憾,performance_schema在5.6会同以前的本子中,默许未有启用,从5.7及其之后的版本才修改为暗中认可启用。以往,大家来寻访哪些设置performance_schema暗中同意启用吧!

| table_lock_waits_summary_by_table |#
根据每种表实行计算的表锁等待事件

“翻过那座山,你就足以看到一片海”

# file_summary_by_instance表

2、performance_schema使用高效入门

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

OBJECT_NAME: NULL

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

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

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

SPINS: NULL

图片 1

OBJECT_SCHEMA: NULL

(1)accounts表

| accounts |

OPEN_COUNT:文件当前已张开句柄的计数。假如文件张开然后关门,则展开1次,但OPEN_COUNT列将加一然后减一,因为OPEN_COUNT列只总计当前已开垦的文本句柄数,已关闭的文本句柄会从中减去。要列出server中当前开采的保有文件音信,能够应用where
WHERE OPEN_COUNT> 0子句实行查看。

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

performance_schema通过如下表来记录相关的锁音讯:

下篇将为大家分享”performance_schema之二(配置表详解)”
,多谢你的读书,大家不见不散!归来搜狐,查看越来越多

LOCK_DURATION: TRANSACTION

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

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

THREAD_ID: 4

·EVENT_NAME:与公事相关联的instruments名称;

OBJECT_TYPE: NULL

·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.3. performance_schema表的分类

EVENT_NAME: wait/io/socket/sql/server_unix_socket

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

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

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

1 row in set (0.00 sec)

| wait/io/file/sql/MYSQL_LOG
|1599816582|

1row inset ( 0. 00sec)

12rows inset (0.01sec)

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

SOURCE: log0log.cc:1572

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

| variables_by_thread |

OWNER_OBJECT_TYPE: NULL

WHERE TABLE_SCHEMA =’performance_schema’andengine=’performance_schema’;

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

|
memory_summary_by_thread_by_event_name |

SUM_TIMER_EXECUTE: 0

2.4.
performance_schema简单布署与应用

3 rows in set (0.00 sec)

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

SUM _NUMBER_OF _BYTES_READ: 11567104

| events_transactions_current |

COUNT_STAR: 56

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

hosts表包含客户端连接到MySQL
server的主机新闻,三个主机名对应一行记录,该表针对主机作为独一标志实行计算当前连接数和总连接数。server运营时,表的尺寸会自行调解。
要显式设置该表大小,能够在server运维以前安装系统变量performance_schema_hosts_size的值。如若该变量设置为0,则代表禁用hosts表总括消息。

| users |

·VICTIM,TIMEOUT和KILLED状态值停留时间很简单,当三个锁处于那个情景时,那么表示该锁行新闻将要被剔除(手动推行SQL只怕因为日子原因查看不到,可以动用程序抓取);

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

SUM_TIMER_WAIT: 62379854922

| Tables_in_performance_schema
(%memory%) |

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

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

天性总计表

|
events_statements_summary_by_host_by_event_name |

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

| Tables_in_performance_schema
(%statement%) |

·当待管理的锁央求超时,会回到错误新闻(ELacrosse_LOCK_WAIT_TIMEOUT)给央求锁的对话,锁状态从PENDING更新为TIMEOUT;

Rowsmatched: 3 Changed: 3 Warnings: 0

·CURRENT_CONNECTIONS:某帐号的脚下连接数;

……

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

利用show命令来询问你的数据库实例是或不是协理INFORMATION_SCHEMA引擎

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

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

MIN _TIMER_WAIT: 56688392

| file_instances |

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

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

# file_summary_by_event_name表

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

COUNT_READ: 0

本篇内容到那边就就像尾声了,相信广大人都感到,大家超过1/2时候并不会一直运用performance_schema来查询质量数据,而是接纳sys
schema下的视图替代,为啥不直接攻读sys schema呢?那你理解sys
schema中的数据是从哪个地方吐出来的呢?performance_schema
中的数据实际上首若是从performance_schema、information_schema中获得,所以要想玩转sys
schema,全面精通performance_schema不能缺少。其余,对于sys
schema、informatiion_schema以致是mysql
schema,大家接二连三也会推出分歧的文山会海小说共享给我们。

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

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

1.数量库表品级对象等待事件总计

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

SUM _TIMER_WAIT: 56688392

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

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

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

COUNT_STAR: 2560

罗小波·沃趣科学技术尖端数据库技能专家

EVENT_NAME: wait/io/file/innodb/innodb_data_file

performance_schema被视为存款和储蓄引擎。若果该蒸汽机可用,则应该在INFORMATION_SCHEMA.ENGINES表或SHOW
ENGINES语句的出口中都能够阅览它的SUPPORT值为YES,如下:

| socket_summary_by_event_name |

当今,大家早就大概知道了performance_schema中的首要表的分类,但,怎么着利用他们来为大家提供应和需要要的天性事件数量吧?上边,我们介绍怎么着通过performance_schema下的安插表来配置与应用performance_schema。

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

| events_waits_history |

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

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

COUNT_STAR: 1

| 0 |

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

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

·OWNER_EVENT_ID:伏乞元数据锁的风浪ID。

| THREAD_ID |EVENT_ID | EVENT_NAME |TIMER_WAIT |

table_handles表是只读的,无法创新。暗中同意自动调节表数据行大小,若是要显式钦命个,能够在server运转以前设置系统变量performance_schema_max_table_handles的值。

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

OBJECT_SCHEMA: xiaoboluo

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

# table_io_waits_summary_by_index_usage表

2.3.
performance_schema表的分类

| NAME |OBJECT_INSTANCE_BEGIN |

performance_schema= ON#
注意:该参数为只读参数,须求在实例运营从前设置才生效

每种连接音信表皆有CUOdysseyRENT_CONNECTIONS和TOTAL_CONNECTIONS列,用于追踪连接的眼下连接数和总连接数。对于accounts表,每种连接在表中每行音讯的并世无双标志为USE奥迪Q5+HOST,然则对于users表,唯有二个user字段实行标志,而hosts表唯有一个host字段用于标志。

TIMER_WAIT: 65664

·accounts:遵照user@host的款式来对各样客户端的连日实行总结;

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

OBJECT _INSTANCE_BEGIN: 140568048055488

| events_waits_summary_by_instance
|

MIN _TIMER_WAIT: 2971125

|wait/io/file/myisam/dfile | 322401645
|

OBJECT_NAME: test

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

MIN_TIMER_READ: 0

| Engine |Support | Comment

·HOST:某一而再的客户端主机名。假使是一个里头线程创立的连接,恐怕是力不能够及验证的用户创造的一连,则该字段为NULL;

instance表记录了什么样类型的指标会被检查测量检验。那几个目的在被server使用时,在该表上校会发生一条事件记录,比方,file_instances表列出了文本I/O操作及其涉及文件名:

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

|
events_transactions_summary_by_host_by_event_name |

* _platform:客户端机器平台(例如,x86_64)

| wait/synch/mutex/sql/LOCK_plugin
|86027823|

* _client_name:客户端名称(客户端库的libmysql)

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

·当三个线程正在等候某件事发生时,condition
NAME列显示了线程正在守候什么condition(但该表中并从未其他列来显示对应哪个线程等音讯),可是当前还从未一向的艺术来判断某些线程或有个别线程会导致condition产生改造。

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

OBJECT_NAME: test

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;

PS:什么是prepare语句?prepare语句实在就是八个预编写翻译语句,先把SQL语句举行编写翻译,且能够设定参数占位符(比方:?符号),然后调用时通过用户变量传入具体的参数值(叫做变量绑定),假诺贰个讲话要求频仍奉行而仅仅只是where条件不一样,那么使用prepare语句能够大大收缩硬解析的开销,prepare语句有三个步骤,预编写翻译prepare语句,推行prepare语句,释放销毁prepare语句,prepare语句支持三种协议,前边早就涉嫌过了,binary议和一般是提须求应用程序的mysql
c api接口格局访谈,而文本协议提供给通过客户端连接到mysql
server的措施访问,下边以文件协议的艺术访问进行身先士卒验证:

接下来,简要介绍了何等连忙上手使用performance_schema的方法;

MySQL允许应用程序引进新的连年属性,可是以下划线(_)开首的特性名称保留供内部使用,应用程序不要创立这种格式的连日属性。以担保内部的连日属性不会与应用程序创制的连年属性相抵触。

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

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

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

·table_handles:表锁的兼具和央求记录。

|
events_stages_summary_global_by_event_name |

SUM_TIMER_WAIT: 412754363625

Database changed

1 row in set (0.00 sec)

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

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

|导
十分久之前,当自个儿还在品尝着系统地学习performance_schema的时候,通过在互联网各类搜索资料实行学习,但很遗憾,学习的作用并非很醒目,很多标称类似
“深入显出performance_schema”
的稿子,基本上都以这种动不动就贴源码的品格,然后深远了今后却出不来了。对系统学习performance_schema的效应甚微。

(3)hosts表

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

4 rows in set (0.00 sec)

| Tables_in_performance_schema
(%wait%) |

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

OPERATION: lock

PS:对于mutexes、conditions和rwlocks,在运营时纵然允许修改配置,且布局能够修改成功,不过有一点instruments不见效,必要在运转时配置才会收效,假诺您品味着使用部分用出席景来追踪锁音信,你或者在那么些instance表中不只怕查询到对应的消息。

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

·OWNER_THREAD_ID,OWNER_EVENT_ID:这几个列表示创设prepare语句的线程ID和事件ID。

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

OBJECT_TYPE: TABLE

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

SUM_TIMER_READ: 305970952875

qogir_env@localhost :
performance_schema 03:51:36>
show tables like ‘events_statement%’;

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

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

# socket_summary_by_event_name表

|
events_waits_summary_global_by_event_name |

OWNER _THREAD_ID: 46

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

|NULL | NULL |41| 45 |

| setup_objects |

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

| cond_instances |

(3)mutex_instances表

|
events_stages_summary_by_user_by_event_name |

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

mysqld运行之后,通过如下语句查看performance_schema是或不是启用生效(值为ON表示performance_schema已初叶化成功且能够动用了。假若值为OFF表示在启用performance_schema时发出一些错误。能够查阅错误日志实行排查):

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

|2、performance_schema使用便捷入门

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

_current表中各类线程只保留一条记下,且一旦线程完结专业,该表中不会再记录该线程的平地风波消息,_history表中记录各个线程已经实行到位的风浪新闻,但各个线程的只事件消息只记录10条,再多就能够被覆盖掉,*_history_long表中记录全体线程的事件音讯,但总记录数据是一千0行,抢先会被遮住掉,现在大家查看一下历史表events_waits_history
中著录了怎么:

| OBJECT_TYPE |OBJECT_SCHEMA | OBJECT_NAME |OBJECT_INSTANCE_BEGIN |
OWNER_THREAD_ID |OWNER_EVENT_ID | INTERNAL_LOCK |EXTERNAL_LOCK |

| events_statements_history_long
|

·假如应用到了目录,则这里展现索引的名字,假若为PEvoqueIMACRUISERY,则表示表I/O使用到了主键索引

|
events_stages_summary_by_account_by_event_name |

FILE_NAME: /data/mysqldata1/innodb_ts/ibdata1

……

1. 接连音讯总计表

图片 2

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

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

我们先来拜望表中著录的总结消息是怎么样样子的。

| setup_instruments |

01

品级事件记录表,记录语句实践的等第事件的表,与话语事件类型的相关记录表类似:

6 rows inset (0.00 sec)

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

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

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

metadata_locks表是只读的,无法创新。暗许保留行数会自行调度,如若要配备该表大小,能够在server运转从前设置系统变量performance_schema_max_metadata_locks的值。

EVENT_ID: 60

·INTERNAL_LOCK:在SQL等第使用的表锁。有效值为:READ、READ WITH
SHARED LOCKS、READ HIGH PENVISIONIO福特ExplorerITY、READ NO INSERT、WOdysseyITE ALLOW
WEnclaveITE、W中华VITE CONCUCRUISERRENT INSERT、WENVISIONITE LOW
PXC60IOTiguanITY、W奥德赛ITE。有关那个锁类型的详细消息,请参阅include/thr_lock.h源文件;

|wait/io/file/sql/pid | 72591750 |

…………

|
events_transactions_summary_by_user_by_event_name |

3rows inset ( 0. 00sec)

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

OBJECT_NAME: test

9rows inset (0.00sec)

经过对以下两个表施行查询,能够达成对应用程序的监督或DBA能够检查测试到事关锁的线程之间的局地瓶颈或死锁音讯:

| cond_instances |

数据库对象总计表

OBJECT_INSTANCE_BEGIN: 955681576

AVG _TIMER_READ: 56688392

数据库刚刚初阶化并运转时,而不是全数instruments(事件采访项,在征集项的陈设表中每一类都有三个按键字段,或为YES,或为NO)和consumers(与征集项类似,也是有贰个相应的事件类型保存表配置项,为YES就象征对应的表保存品质数据,为NO就代表对应的表不保留品质数据)都启用了,所以默许不会搜罗全部的事件,大概您需求检查评定的风云并不曾张开,必要张开安装,能够动用如下八个语句张开对应的instruments和consumers(行计数大概会因MySQL版本而异),举例,大家以布置监测等待事件数量为例实行表达:

COUNT_STAR: 1

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

小编们先来探视表中记录的总结新闻是什么体统的。

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

admin@localhost : performance _schema 11:00:44> select * from
file_summary _by_event _name where SUM_TIMER _WAIT !=0 and
EVENT_NAME like ‘%innodb%’ limit 1G;

2.1. 反省当前数据库版本是不是援救

套接字总括表允许使用TRUNCATE
TABLE语句(除events_statements_summary_by_digest之外),只将总括列复位为零,并非剔除行。

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

(2)table_handles表

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

上一篇 《事件计算 |
performance_schema全方位介绍》详细介绍了performance_schema的事件计算表,但这一个总结数据粒度太粗,仅仅依照事件的5大品类+用户、线程等维度举行归类总计,但一时大家供给从更加细粒度的维度进行分类总计,比如:有些表的IO花费多少、锁开支多少、以及用户连接的一些性质总括音讯等。此时就供给查阅数据库对象事件计算表与质量总计表了。明日将指点大家一道踏上密密麻麻第五篇的道路(全系共7个篇章),本期将为我们精细入微授课performance_schema中指标事件总括表与品质总计表。上边,请随行我们一道开头performance_schema系统的读书之旅吧~

|Transactions | XA |Savepoints
|

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

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

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

| setup_timers |

TIMER_PREPARE: 896167000

IT从业多年,历任运营程序猿、高等运转技术员、运营首席营业官、数据库技术员,曾插足版本发表系统、轻量级监控类别、运行管理平台、数据库管理平台的安插与编辑,熟稔MySQL种类布局,Innodb存款和储蓄引擎,喜好专研开源本领,追求完善。

·
COUNT_REPREPARE:该行音信对应的prepare语句在其中被另行编写翻译的次数,重新编写翻译prepare语句之后,在此以前的相干总结新闻就不可用了,因为这一个计算音讯是用作言语实行的一局地被集合到表中的,而不是单身维护的。

说话事件记录表,那几个表记录了讲话事件音信,当前说话事件表events_statements_current、历史语句事件表events_statements_history和长语句历史事件表events_statements_history_long、以及汇集后的摘要表summary,在那之中,summary表还足以依附帐号(account),主机(host),程序(program),线程(thread),用户(user)和大局(global)再拓展剪切)

| NAME |OBJECT_INSTANCE_BEGIN | WRITE_LOCKED_BY_THREAD_ID
|READ_LOCKED_BY_COUNT |

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

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

配备好未来,大家就足以查看server当前正值做什么样,能够通过查询events_waits_current表来获知,该表中各类线程只含有一行数据,用于体现各个线程的新星监视事件(正在做的业务):

metadata_locks表不容许接纳TRUNCATE TABLE语句。

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

……

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

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

| Tables_in_performance_schema
(%transaction%) |

OBJECT_TYPE: TABLE

|EVENT_NAME | SUM_TIMER_WAIT |

*
COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_WWranglerITE:那几个列总结了独具文件写操作,蕴涵FPUTS,FPUTC,FP奥迪Q5INTF,VFPSportageINTF,FWEscortITE和PWQX56ITE系统调用,还包罗了这一个I/O操作的数据字节数

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

performance_schema提供了针对prepare语句的监察记录,并依据如下方法对表中的内容进行管理。

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

COUNT_STAR: 213055844

相关文章