数据库对象事件与天性总括 | performance_schema全方位介绍(五)

作者:龙八国际官方网站    发布时间:2019-12-19 21:35    浏览:196 次

[返回]

| socket_summary_by_instance |

OBJECT _INSTANCE_BEGIN: 32492032

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

     MySQL Performance-Schema中总共包罗51个表,首要分为几类:Setup表,Instance表,Wait Event表,Stage Event表Statement Event表,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-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和10000都是足以布置的。那多少个表表布局相仿,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时,第二个表位全表扫描的数量
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_STAXC90:事件计数
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_龙8国际long88,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中风度翩翩共包罗54个表,首要分为几类:Setup表,Instance表,Wait Event表,Stage Ev...

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

COUNT_ALLOC: 216

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

+--------------------------------------------------------------+

* _client_version:客商端库版本

MIN _TIMER_WAIT: 0

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

+--------------------------------------------------------+

套接字事件总计了套接字的读写调用次数和出殡和安葬接纳字节计数音信,socket事件instruments默许关闭,在setup_consumers表中无具体的呼应配置,包含如下两张表:

* 假使三个线程开启了征集效率,但是内部存款和储蓄器相关的instruments没有启用,则该内部存款和储蓄器释放操作不会被监督到,计算数据也不会爆发改换

AVG _TIMER_WAIT: 3496961251500

USER: NULL

SQL_TEXT: SELECT 1

SUM _TIMER_WAIT: 8649707000

从地点表中的记录新闻大家能够看出:

AVG _TIMER_WAIT: 0

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

# memory_summary_by_thread_by_event_name表

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

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

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

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

OWNER_OBJECT_TYPE: NULL

MAX _TIMER_WAIT: 0

咱俩先来寻访表中记录的计算信息是怎么体统的。

SUM_SORT_ROWS: 170

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

| events_statements_summary_by_digest |

·table_handles:表锁的兼具和伸手记录。

SUM _TIMER_WAIT: 0

1 rows in set (0.00 sec)

作者们先来探视那几个表中著录的总计新闻是何等样子的(由于单行记录较长,这里只列出events_statements_summary_by_account_by_event_name 表中的示例数据,别的表的示范数据省略掉生龙活虎部分相符字段)。

·当互斥体被销毁时,从mutex_instances表中除去相应的排挤体行。

+------------------------------------------------------------+

14 rows inset (0.01 sec)

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

本性计算表

......

* _platform:客商端机器平台(比方,x86_64)

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

SUM _TIMER_WAIT: 56688392

关于events_statements_summary_by_digest表

rwlock_instances表列出了server施行rwlock instruments时performance_schema所见的具备rwlock(读写锁)实例。rwlock是在代码中运用的一块儿机制,用于免强在给依时期内线程能够信守有个别法规访问些公共财富。能够以为rwlock敬性格很顽强在荆棘满途或巨大压力面前不屈着那些能源不被别的线程随意抢占。访谈方式能够是分享的(七个线程能够何况兼有分享读锁)、排他的(同不日常候唯有二个线程在加以时间能够有所排他写锁)或分享独自占领的(有些线程持有排他锁依期,同一时间同意任何线程实践不风华正茂致性读)。分享独自占领访谈被称为sxlock,该访问情势在读写场景下能够进步并发性和可扩充性。

# events_waits_summary_by_host_by_event_name表

SUM _TIMER_READ: 56688392

| events_statements_summary_global_by_event_name |

表字段含义与session_account_connect_attrs表相近,但是该表是保留全部连接的连年属性表。

| 导语

COUNT_STAR: 1

COUNT_STAR: 0

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

performance_schema把语句事件总结表也遵守与等待事件总结表肖似的准则实行归类总计,语句事件instruments暗中认可全体拉开,所以,语句事件计算表中暗中认可会记录全部的言语事件总计新闻,讲话事件总结表蕴含如下几张表:

mutex_instances表不容许利用TRUNCATE TABLE语句。

* COUNT_ALLOC,COUNT_FREE:对内部存款和储蓄器分配和刑释解教内部存款和储蓄器函数的调用总次数

|wait/synch/cond/sql/COND_manager | 31903008 |

| events_waits_summary_global_by_event_name |

·LOCKED_BY_THREAD_ID:当二个线程当前具有一个排挤锁按期,LOCKED_BY_THREAD_ID列呈现所有线程的THREAD_ID,若无被别的线程持有,则该列值为NULL。

EVENT_NAME: stage/sql/After create

AVG_TIMER_WAIT: 24366870

performance_schema把等待事件总结表遵照不一样的分组列(不相同纬度)对等候事件有关的数额开展联谊(聚合总括数据列富含:事件时有发生次数,总等待时间,最小、最大、平均等待时间),注意:等待事件的募集效率有风华正茂对暗中同意是禁止使用的,要求的时候可以通过setup_instruments和setup_objects表动态开启,等待事件计算表富含如下几张表:

users表字段含义如下:

SUM _TIMER_WAIT: 0

+-------------+---------------+-------------+-----------------------+-----------------+----------------+---------------+---------------+

+-------------------------------------------------+

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

* LOW_COUNT_USED:如果CURRENT_COUNT_USED裁减1事后是多少个新的最低值,则该字段相应裁减

1 row in set (0.00 sec)

对此未根据帐户、主机、客户集中的总结表,truncate语句会将总括列值重新设置为零,实际不是去除行。

3rows inset ( 0. 00sec)

FIRST_SEEN: 2018-05-19 22:33:50

| file_summary_by_instance |

HOST: localhost

rwlock_instances表字段含义如下:

* 将COUNT_ALLOC和COUNT_FREE列重新复苏设置,并再度初阶计数(等于内部存储器总结消息以重新载入参数后的数值作为标准数据)

OWNER_OBJECT_NAME: NULL

* 读写作业平常比只读事务占用更加多财富,因而事务总括表包罗了用来读写和只读事务的独门总括列

| table_io_waits_summary_by_index_usage |# 依照每一个索引进行总括的表I/O等待事件

| events_transactions_summary_by_host_by_event_name |

MAX_TIMER_EXECUTE: 0

1 row in set (0.01 sec)

·当待管理的锁须求超时,会回来错误音信(ETucson_LOCK_WAIT_TIMEOUT)给诉求锁的对话,锁状态从PENDING更新为TIMEOUT;

5rows inset ( 0. 00sec)

·rwlock_instances:查看当前rwlock行的片段锁新闻(独自占领锁被哪些线程持有,分享锁被有个别个线程持有等)。

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

+-------------------------------------------------+

MAX _TIMER_WAIT: 0

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

MIN _TIMER_WAIT: 0

+--------------------------------------+-----------------------+---------------------+

+------------------------------------------+

·此中锁对应SQL层中的锁。是由此调用thr_lock(卡塔尔(英语:State of Qatar)函数来贯彻的。(官方手册上说有二个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。但在该表的定义上并未见到该字段卡塔尔国

performance_schema把内部存款和储蓄器事件计算表也遵守与等待事件总括表相像的法则进行归类计算。

咱俩先来看看表中著录的总括音讯是何等样子的。

events_statements_summary_by_program:依据每种存款和储蓄程序(存储进程和函数,触发器和事件)的平地风波名称实行计算的Statement事件

MAX _TIMER_WAIT: 121025235946125

AVG_TIMER_WAIT: 4426693000

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

MAX _TIMER_READ_WRITE: 2427645000

SUM _NUMBER_OF _BYTES_READ: 0

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

SUM_WARNINGS: 0

# events_waits_summary_by_instance表

·OBJECT_INSTANCE_BEGIN:此列是套接字实例对象的有一无二标志。该值是内部存款和储蓄器中对象之处;

* 平常,truncate操作会重新苏醒设置总括消息的原则数据(即清空以前的数据),但不会改过当前server的内部存款和储蓄器分配等气象。也正是说,truncate内部存款和储蓄器总结表不会自由已分配内部存款和储蓄器

COUNT_EXECUTE: 0

OBJECT_SCHEMA: sys

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

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

+----------------------------------+-----------------------+

SUM _TIMER_WAIT: 0

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

LOW_COUNT_USED: 0

performance_schema提供了针对性prepare语句的督察记录,并依照如下方法对表中的原委举行田间管理。

performance_schema把阶段事件总结表也遵从与等待事件总计表相仿的法则举行归类聚合,阶段事件也有点是私下认可禁止使用的,大器晚成都部队分是敞开的,阶段事件总计表包蕴如下几张表:

要求具备互斥体的办事负荷可以被以为是居于二个关键岗位的干活,多个查询大概供给以类别化的法子(叁次二个串行)实践这么些尤为重要部分,但那只怕是八个机密的性质瓶颈。

| events_statements_summary_by_account_by_event_name |

MAX_TIMER_READ: 9498247500

......

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

+--------------------------------------------------------------+

·假若是插入操作,则不可能运用到目录,当时的计算值是依照INDEX_NAME = NULL计算的

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

AVG_TIMER_READ: 0

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

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

1 row in set (0.00 sec)

·OBJECT_TYPE:彰显handles锁的种类,表示该表是被哪些table handles打开的;

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

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

我们先来造访那几个表中著录的总计音讯是怎样样子的(由于单行记录较长,这里只列出events_transactions_summary_by_account_by_event_name表中的示例数据,别的表的言传身教数据省略掉黄金年代部分肖似字段)。

session_account_connect_attrs表不容许利用TRUNCATE TABLE语句。

| prepared_statements_instances |

| localhost |1| 1 |

# events_waits_summary_by_thread_by_event_name表

+--------------------------------------+-----------------------+---------------------+

EVENT_NAME: transaction

EVENT_NAME: wait/io/file/innodb/innodb_data_file

SUM_TIMER_WAIT: 234614735000

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

# events_statements_summary_by_user_by_event_name表

COUNT_STAR: 24

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

* 使用libmysqlclient编写翻译:php连接的个性集合使用标准libmysqlclient属性,参见上文

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

·session_account_connect_attrs:记录当前对话及其相关联的其它会话的三回九转属性;

# events_stages_summary_by_host_by_event_name表

·CURRENT_CONNECTIONS:某客商的日前连接数;

从上边表中的亲自去做记录音信中,大家得以看见,相仿与等待事件相仿,遵照客户、主机、顾客+主机、线程等纬度进行分组与计算的列,那个列的意思与等待事件形似,这里不再赘述,但对那一件事情总计事件,针对读写事务和只读事务还独自做了总括(xx_READ_WRITE和xx_READ_ONLY列,只读事务要求安装只读事务变量transaction_read_only=on才会开展计算卡塔尔(英语:State of Qatar)。

各类套接字总计表都包罗如下总括列:

USER: NULL

SUM _TIMER_READ _WITH_SHARED_LOCKS: 0

events_statements_summary_by_host_by_event_name:依照各类主机名和事件名称实行计算的Statement事件

·只要值为NULL,则象征表I/O未有选择到目录

# events_transactions_summary_by_account_by_event_name表

OBJECT_NAME: test

COUNT_STAR: 0

2rows inset ( 0. 00sec)

当某给定对象被执行时,其对应的计算音信将记录在events_statements_summary_by_program表中并张开总括。

01

EVENT_NAME: memory/innodb/fil0fil

table_io_waits_summary_by_index_usage表:

职业聚合总结准则

1 row in set (0.00 sec)

# memory_summary_by_user_by_event_name表

(1) session_account_connect_attrs表

SUM_xxx:针对events_statements_*事件记录表中相应的xxx列举办计算。比如:语句总结表中的SUM_LOCK_TIME和SUM_ERRORS列对events_statements_current事件记录表中LOCK_TIME和ETucsonRO奥迪Q7S列举行总括

+-------------+---------------------+-------------------+

HIGH_COUNT_USED: 1

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

# events_stages_summary_by_account_by_event_name表

AVG_TIMER_READ_NORMAL: 0

# events_statements_summary_global_by_event_name表

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

MAX _TIMER_WAIT: 0

7.锁对象记录表

# events_waits_summary_by_account_by_event_name表

(2)table_handles表

* FIRST_SEEN,LAST_SEEN:展现某给定语句第三次插入 events_statements_summary_by_digest表和结尾一遍立异该表的小时戳

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

OBJECT_TYPE: PROCEDURE

·不菲MySQL顾客端程序设置的属性值与顾客端名称相等的多少个program_name属性。例如:mysqladmin和mysqldump分别将program_name连接属性设置为mysqladmin和mysqldump,别的一些MySQL顾客端程序还定义了增大属性:

| events_statements_summary_by_program |

1. 总是新闻总括表

# events_stages_summary_by_thread_by_event_name表

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

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

LOCK_TYPE: SHARED_READ

SCHEMA_NAME: NULL

+----------------------------------------+-----------------------+-----------+-----------+--------------------+-------+--------+

admin@localhost : performance_schema 06:23:02> show tables like '%events_stages_summary%';

那么些音信让你能够精晓会话之间的元数据锁依赖关系。不只可以够见到会话正在等候哪个锁,还足以看来日前具有该锁的会话ID。

SUM_WARNINGS: 0

·CURRENT_CONNECTIONS:某帐号的当前连接数;

MAX _TIMER_WAIT: 0

| qfsys |10.10. 20.15| 1 |1|

HOST: NULL

| 4 |_client_name | libmysql |1|

SUM_SELECT_SCAN: 45

prepared_statements_instances表字段含义如下:

| events_stages_summary_by_thread_by_event_name |

咱俩先来看看表中著录的总括音信是什么样子的。

1 row in set (0.00 sec)

·metadata_locks:元数据锁的装有和伸手记录;

SUM _NUMBER_OF _BYTES_ALLOC: 3296

·setup_instruments表列出了instruments名称,那个互斥体都包蕴wait/synch/mutex/前缀;

对此较高等别的会集(全局,按帐户,按客户,按主机)总括表中,低水位和高水位适用于如下准绳:

| Tables_in_performance_schema (%file_summary%) |

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

|4| _pid |3766| 2 |

AVG _TIMER_WAIT: 0

SUM _NUMBER_OF _BYTES_READ: 11567104

AVG _TIMER_WAIT: 0

| 10.10.20.15 |1| 1 |

* HIGH_NUMBER_OF_BYTES_USED:如果CURRENT_NUMBER_OF_BYTES_USED扩充N之后是四个新的最高值,则该字段值相应扩大

+------------------------------------+--------------------------------------+------------+

USER: root

* events_waits_current表中能够查阅到当前正在等候互斥体的线程时间信息(例如:TIME途观_WAIT列表示早已等候的时日) ;

从上边表中的示范记录消息中,我们得以见到:

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

| memory_summary_global_by_event_name |

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

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

* 如果log_error_verbosity系统变量设置值超过1,则performance_schema还可能会将错误消息写入错误日志:

......

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

MAX _TIMER_WAIT: 0

·accounts:遵照user@host的样式来对各类客商端的连天举行总结;

注意:这么些表只针对阶段事件音信举办总括,即蕴含setup_instruments表中的stage/%最先的搜聚器,种种阶段事件在种种表中的总计记录行数须要看怎么分组(比方:根据客商分组总括的表中,有稍许个活泼顾客,表中就能有稍微条雷同收罗器的记录),其余,计算流速計是或不是见到效果还索要看setup_instruments表中相应的级差事件采撷器是还是不是启用。

file_instances表列出实施文书I/O instruments时performance_schema所见的享有文件。 如若磁盘上的文件并未有张开,则不会在file_instances中记录。当文件从磁盘中去除时,它也会从file_instances表中删除相应的笔录。

EVENT_NAME: stage/sql/After create

·COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE:试行prepare语句时的连带计算数据。

+------------------------------------------+

*************************** 4. row ***************************

Rows matched: 377 Changed: 377 Warnings: 0

* _client_version:客户端libmysql库版本

MIN _TIMER_WAIT: 0

我们先来会见表中著录的总括消息是什么体统的。

COUNT_STAR: 0

·OWNER_THREAD_ID:必要元数据锁的线程ID;

EVENT_NAME: memory/innodb/fil0fil

* 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操作的多少字节数 ;

MAX _TIMER_READ_ONLY: 57571000

从地点表中的笔录消息我们能够看出(与公事I/O事件计算相符,两张表也独家根据socket事件类型总括与固守socket instance举办计算)

1 row in set (0.00 sec)

table_io_waits_summary_by_table表:

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

......

SUM _CREATED_TMP_TABLES: 10

+----------------+-----------------+----------------+------------------+

| events_statements_summary_by_thread_by_event_name |

注意:rwlock_instances表中的信息只可以查见到具备写锁的线程ID,不过不能查看见有着读锁的线程ID,因为写锁W安德拉ITE_LOCKED_BY_THREAD_ID字段记录的是线程ID,读锁独有贰个READ_LOCKED_BY_COUNT字段来记录读锁被有个别个线程持有。

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

* _platform:客商端机器平台(比如,x86_64)

root@localhost : performance _schema 01:19:07> select * from events_transactions _summary_by _account_by _event_name where COUNT_STAR!=0 limit 1G

·已给与的锁(呈现怎会话具有当前元数据锁);

此外,依照帐户、主机、客商、线程聚合的各类等待事件总括表或然events_waits_summary_global_by_event_name表,如若依赖的连接表(accounts、hosts、users表卡塔尔(英语:State of Qatar)推行truncate时,那么注重的这一个表中的总计数据也会同一时候被隐式truncate 。

......

CURRENT _NUMBER_OF _BYTES_USED: 0

MIN _TIMER_WAIT: 2971125

1 row in set (0.00 sec)

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

COUNT_STAR: 7

当客户端与server端建构连接时,performance_schema使用切合种种表的独占鳌头标志值来明确各类连接表中哪些举办记录。如若缺乏对应标记值的行,则新增加加大器晚成行。然后,performance_schema会追加该行中的CU奥迪Q3RENT_CONNECTIONS和TOTAL_CONNECTIONS列值。

* 注意:如果在server运维之后再校正memory instruments,恐怕会产生由于遗失从前的分红操作数据而招致在刑释之后内部存储器总计音讯现身负值,所以不建议在运维时每每开关memory instruments,就算有内部存储器事件总括必要,提出在server运行从前就在my.cnf中布置好内需总括的事件访问

·已被死锁检查实验器检查评定到并被杀死的锁,也许锁央浼超时正在等候锁央求会话被裁撤。

events_waits_summary_global_by_event_name表:按照EVENT_NAME列进行分组事件音讯

# table_io_waits_summary_by_index_usage表

+-------------------------------------------------+

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

1 row in set (0.00 sec)

AVG _TIMER_READ: 56688392

1 row in set (0.00 sec)

咱俩先来寻访表中记录的总计新闻是怎么着体统的。

# events_statements_summary_by_program表(供给调用了储存进程或函数之后才会有数量卡塔尔国

3 rows in set (0.00 sec)

| events_transactions_summary_global_by_event_name |

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

THREAD_ID: 37

* COUNT_MISC,SUM_TIMER_MISC,MIN_TIMER_MISC,AVG_TIMER_MISC,MAX_TIMER_MISC:那么些列总括了有着别的文件I/O操作,包蕴CREATE,DELETE,OPEN,CLOSE,STREAM_OPEN,STREAM_CLOSE,SEEK,TELL,FLUSH,STAT,FSTAT,CHSIZE,RENAME和SYNC系统调用。注意:那几个文件I/O操作未有字节计数新闻。

COUNT_STAR: 1

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

1 row in set (0.00 sec)

我们先来拜访表中著录的总结音讯是何等样子的。

......

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

| events_transactions_summary_by_account_by_event_name |

PS:对于mutexes、conditions和rwlocks,在运作时就算允许更改配置,且布局能够改良成功,但是有部分instruments不奏效,须求在运转时配置才会卓有成效,倘诺你尝试着使用部分选拔场景来追踪锁新闻,你或者在此些instance表中不能查询到相应的音信。

* COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE:实行prepare语句对象的总括新闻

+-------------------------------------------------+

MAX _TIMER_WAIT: 0

连续几日消息表accounts中的user和host字段含义与mysql系统数据库中的MySQL grant表(user表)中的字段含义相像。

MAX_TIMER_WAIT: 80968744000

·OWNER_EVENT_ID:诉求元数据锁的事件ID。

| Tables_in_performance_schema (%events_statements_summary%) |

OBJECT _INSTANCE_BEGIN: 2658003840

EVENT_NAME: memory/innodb/fil0fil

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

MIN _TIMER_WAIT: 0

EVENT_NAME: wait/io/socket/sql/client_connection

  • SUM_NUMBER_OF_BYTES_FREE

OBJECT_TYPE: TABLE

MAX _TIMER_WAIT: 0

·SOCKET_ID:分配给套接字的内部文件句柄;

| memory_summary_by_user_by_event_name |

2rows inset ( 0. 00sec)

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

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

MIN_TIMER_WAIT: 72775000

| table_lock_waits_summary_by_table |# 遵照每一种表进行总结的表锁等待事件

* HIGH_COUNT_USED和HIGH_NUMBER_OF_BYTES_USED是较高的高水位推测值。performance_schema输出的低水位值能够保险计算表中的内部存储器分配次数和内部存款和储蓄器大于或等于当前server中实际的内部存款和储蓄器分配值

# socket_summary_by_instance表

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

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

* CURRENT_COUNT_USED:减少1

............

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

AVG _TIMER_WAIT: 56688392

COUNT _READ_ONLY: 1

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

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

1 row in set (0.00 sec)

MIN _TIMER_WAIT: 0

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

| events_transactions_summary_by_user_by_event_name |

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

| Tables_in_performance_schema (%memory%summary%) |

·TOTAL_CONNECTIONS:某客户的总连接数。

......

(2)file_instances表

COUNT_STAR: 7

文件I/O事件总计表允许行使TRUNCATE TABLE语句。但只将计算列重新苏醒设置为零,实际不是剔除行。

MIN _TIMER_WAIT: 0

| 3 |_client_name | libmysql |1|

我们先来探视那一个表中著录的总结消息是如何体统的。

mutex_instances.LOCKED_BY_THREAD_ID和rwlock_instances.WRITE_LOCKED_BY_THREAD_ID列对于每个核查品质瓶颈或死锁难点根本。

5rows inset ( 0. 00sec)

SUM_TIMER_READ_NORMAL: 0

COUNT_STAR: 0

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

* 假如给定语句的总括新闻行在events_statements_summary_by_digest表中没有已存在行,且events_statements_summary_by_digest表空间范围已满的景色下,则该语句的总括新闻将丰裕到DIGEST 列值为 NULL的新陈代谢“catch-all”行,如若该非常行官样文章则新插入生机勃勃行,FIEscortST_SEEN和LAST_SEEN列为当前时间。如若该非常行已存在则更新该行的音信,LAST_SEEN为日前时光

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

| 等待事件计算表

下直面这一个表分别展开介绍。

HOST: NULL

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

注意:这么些表只针对工作事件新闻进行总括,即富含且仅包蕴setup_instruments表中的transaction搜罗器,每一种业务事件在各类表中的总结记录行数供给看哪样分组(比方:根据客户分组总结的表中,有稍许个活泼客商,表中就能有稍稍条相像搜罗器的记录),其它,总括计数器是或不是见到成效还供给看transaction搜罗器是或不是启用。

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

THREAD_ID: 1

accounts表包罗连接到MySQL server的种种account的笔录。对于每一种帐户,没个user+host唯后生可畏标志风度翩翩行,每行单独总结该帐号的一时连接数和总连接数。server运营时,表的大大小小会自动调节。要显式设置表大小,能够在server运营在此以前设置系统变量performance_schema_accounts_size的值。该连串变量设置为0时,表示禁止使用accounts表的计算消息功效。

COUNT_STAR: 59

|4| _platform |x86_64 | 4 |

* CURRENT_NUMBER_OF_BYTES_USED:当前已分配的内部存款和储蓄器块但未释放的总结大小。那是叁个便捷列,等于SUM_NUMBER_OF_BYTES_ALLOC

......

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

* 复制slave连接的program_name属性值被定义为mysqld、定义了_client_role属性,值为binary_log_listener、_client_replication_channel_name属性,值为坦途名称字符串

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

MAX _TIMER_READ: 56688392

* 假设给定语句的总计音信行在events_statements_summary_by_digest表中早已存在,则将该语句的计算消息实行更新,并更新LAST_SEEN列值为当下光阴

·OBJECT_SCHEMA:该锁来自于哪个库品级的对象;

1 row in set (0.01 sec)

·STATE:套接字状态,有效值为:IDLE或ACTIVE。追踪活跃socket连接的等候时间使用相应的socket instruments。跟着空闲socket连接的守候时间利用三个名称为idle的socket instruments。假使二个socket正在等候来自顾客端的伸手,则该套接字那时高居空闲状态。当套接字处于空闲时,在socket_instances表中对应socket线程的音信中的STATE列值从ACTIVE状态切换成IDLE。EVENT_NAME值保持不改变,但是instruments的时间搜集效用被中止。相同的时间在events_waits_current表中记录EVENT_NAME列值为idle的一站式事件音信。当以此socket接受到下四个伸手时,idle事件被停止,socket instance从闲暇状态切换成活动状态,并还原套接字连接的时辰采撷效能。

# events_transactions_summary_by_thread_by_event_name表

COUNT_STAR: 802

LOW _NUMBER_OF _BYTES_USED: 0

·对此已接纳的接连几天,performance_schema根据performance_schema_session_connect_attrs_size系统变量的值检查总括连接属性大小。假如属性大小抢先此值,则会履行以下操作:

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

经过对以下五个表试行查询,能够完结对应用程序的监察和控制或DBA能够检查实验到事关锁的线程之间的部分瓶颈或死锁新闻:

SUM_SORT_SCAN: 6

咱俩先来看看表中著录的总结新闻是如何子的。

SUM _TIMER_READ_ONLY: 57571000

·ATTR_VALUE:连接属性值;

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

* _pid:顾客端进度ID

* 别的,依照帐户,主机,客商或线程分类总结的内部存款和储蓄器总结表或memory_summary_global_by_event_name表,如果在对其依赖的accounts、hosts、users表履行truncate时,会隐式对那一个内部存款和储蓄器总计表推行truncate语句

+----------------+-----------------+----------------+------------------+

AVG _TIMER_WAIT: 1235672000

IP:PORT列组合值可用来标记三个老是。该组合值在events_waits_xxx表的“OBJECT_NAME”列中使用,以标记那一个事件音信是来自哪个套接字连接的:

1row inset ( 0. 00sec)

......

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

八个连接可以知道的三回九转属性会集决定于与mysql server建设结构连接的客商端平台项目和MySQL连接的顾客端类型。

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

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

+------------------------------------------+

performance_schema还总结后台线程和不能求证客商的接连,对于那一个连接计算行音信,USECR-V和HOST列值为NULL。

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

表字段含义与session_account_connect_attrs表字段含义相仿。

HOST: NULL

4 rows in set (0.00 sec)

COUNT_ALLOC: 158

·cond_instances:wait sync相关的condition对象实例;

每一种表皆有个别的贰个或三个分组列,以鲜明如何聚合事件消息(全部表都有EVENT_NAME列,列值与setup_instruments表中NAME列值对应),如下:

大家先来走访表中著录的总计音讯是什么样体统的。

大家先来寻访这个表中著录的总括信息是何许样子的(由于单行记录较长,这里只列出memory_summary_by_account_by_event_name 表中的示例数据,别的表的现身说法数据省略掉风流洒脱部分相似字段)。

OBJECT_NAME: test

MIN _TIMER_READ_ONLY: 57571000

STATEMENT_ID: 1

prepared_statements_instances:依据每种prepare语句实例聚合的计算音信

搜索