数据库对象事件与特性总结 | performance_schema全方位介绍(伍)

| events_stages_history_long |

……

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

| users |

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

SCHEMA_NAME: NULL

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

AVG_TIMER_EXECUTE: 0

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

| events_transactions_current |

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

| events_statements_summary_by_user_by_event_name |

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

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

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

3rows inset (0.01sec)

AVG _TIMER_READ: 56688392

prepared_statements_instances:依据每一个prepare语句实例聚合的总括音信

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

socket_instances表不允许选取TRUNCATE TABLE语句。

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

THREAD_ID: 4

02

| events_stages_summary_by_user_by_event_name |

监视内部存款和储蓄器使用的表:

……

*
将COUNT_ALLOC和COUNT_FREE列重置,并再次起首计数(等于内部存款和储蓄器总计音讯以重置后的数值作为条件数据)

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

AVG _TIMER_WAIT: 3496961251500

MAX _TIMER_READ_WRITE: 2427645000

|
memory_summary_by_user_by_event_name |

·刑释元数据锁时,对应的锁消息行被去除;

1 row in set (0.01 sec)

20rows inset (0.00sec)

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

* SUM_NUMBER_OF_BYTES_FREE:增加N

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

对于代码中的种种互斥体,performance_schema提供了以下新闻:

| events_transactions_summary_global_by_event_name |

| file_instances |

那些连接表都允许选拔TRUNCATE TABLE语句:

EVENT_NAME: memory/innodb/fil0fil

|
events_stages_summary_by_account_by_event_name |

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

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

前几日,大家清楚了在 MySQL 5.七.17版本中,performance_schema
下一起有87张表,那么,那八7帐表都以存放什么数据的呢?大家怎么运用他们来查询大家想要查看的数目吧?先别着急,大家先来看看那个表是哪些分类的。

·成都百货上千MySQL客户端程序设置的属性值与客户端名称相等的三个program_name属性。例如:mysqladmin和mysqldump分别将program_name连接属性设置为mysqladmin和mysqldump,别的壹些MySQL客户端程序还定义了附加属性:

# 若是急需总计内部存款和储蓄器事件音信,须求敞开内存事件采集器

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

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

events_statements_summary_by_user_by_event_name:根据每一个用户名和事件名称进行总括的Statement事件

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

·对于TCP/IP
server套接字(server_tcpip_socket)的server端监听器,端口始终为主端口(例如330陆),IP始终为0.0.0.0;

1 row in set (0.00 sec)

| setup_consumers |

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

SUM _SORT_MERGE_PASSES: 0

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

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

当某给定对象被剔除时,该指标在events_statements_summary_by_program表中的总括音信就要被删除;

OBJECT_SCHEMA: NULL

七.锁目的记录表

各种表都有分其余一个或八个分组列,以鲜明如何聚合事件新闻(全体表都有EVENT_NAME列,列值与setup_instruments表中NAME列值对应),如下:

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

| 4 |_client_name | libmysql |1|

5rows inset ( 0. 00sec)

|2、performance_schema使用高效入门

三.文本I/O事件计算

*
事务所占用的财富需求多少也大概会因作业隔绝级别有所出入(例如:锁财富)。可是:每个server大概是选择相同的割裂级别,所以不单独提供隔开级别相关的总结列

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

* _runtime_version:Java运行环境(JRE)版本

SUM _TIMER_WAIT: 0

2.3.
performance_schema表的分类

*
FEDERATED存款和储蓄引擎连接的program_name属性值被定义为mysqld、定义了_client_role属性,值为federated_storage

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

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

OBJECT _INSTANCE_BEGIN: 140568048055488

SUM _TIMER_WAIT: 0

|
events_statements_summary_by_thread_by_event_name |

OBJECT_SCHEMA: xiaoboluo

HOST: localhost

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

1 rows in set (0.00 sec)

COUNT_STAR: 58

| Tables_in_performance_schema
|

AVG_TIMER_WAIT: 24366870

*
以前缀memory/performance_schema命名的instruments能够搜集performance_schema本人消耗的里边缓存区大小等新闻。memory/performance_schema/*
instruments暗许启用,不或者在运行时或运营时关闭。performance_schema本身有关的内部存款和储蓄器总括音讯只保存在memory_summary_global_by_event_name表中,不会保存在依据帐户,主机,用户或线程分类聚合的内存总结表中

SOURCE: log0log.cc:1572

(1)metadata_locks表

| memory_summary_by_user_by_event_name |

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

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

AVG _TIMER_WAIT: 0

当今,很欢悦的报告大家,大家按照 MySQL
官方文书档案加上大家的申明,整理了1份能够系统学习 performance_schema
的资料分享给我们,为了便于大家阅读,我们整理为了三个种类,1共七篇文章。上边,请跟随大家共同起首performance_schema系统的就学之旅吧。

·socket_summary_by_event_name:针对种种socket I/O
instruments,那几个socket操作相关的操作次数、时间和出殡和埋葬接收字节新闻由wait/io/socket/*
instruments发生(这里的socket是指的近期活跃的接连创立的socket实例)

……

Database changed

| HOST |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |

*
LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED将重置为CUXC90RENT_NUMBER_OF_BYTES_USED列值

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

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

* CURRENT_COUNT_USED:增加1

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

从地点表中的笔录新闻大家能够见见,table_io_waits_summary_by_index_usage表和table_io_waits_summary_by_table有着左近的总括列,但table_io_waits_summary_by_table表是富含整体表的增加和删除改查等待事件分类总结,table_io_waits_summary_by_index_usage区分了各类表的目录的增加和删除改查等待事件分类总结,而table_lock_waits_summary_by_table表总计纬度类似,但它是用以总计增加和删除改核查应的锁等待时间,而不是IO等待时间,这一个表的分组和总括列含义请我们自行举一反叁,那里不再赘言,上面针对那叁张表做一些必需的辨证:

COUNT_ALLOC: 1

MySQL的performance schema 用于监察和控制MySQL
server在1个较低级别的运行进度中的财富消耗、财富等待等情景,它装有以下特点:

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

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

|PERFORMANCE_SCHEMA | YES
|Performance Schema

咱们先来看望表中记录的总结音讯是什么样体统的。

COUNT_STAR: 0

动态对performance_schema进行陈设的配置表:

……

5rows inset ( 0. 00sec)

12rows inset (0.01sec)

| 4 |program_name | mysql |5|

HIGH_COUNT_USED: 1

9rows inset (0.00sec)

·EVENT_NAME:生成事件新闻的instruments
名称。与setup_instruments表中的NAME值对应;

AVG _TIMER_READ_ONLY: 57571000

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

(1)cond_instances表

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

5rows inset (0.01sec)

| NULL |41| 45 |

SUM _CREATED_TMP_TABLES: 10

summary表提供具有事件的汇集新闻。该组中的表以分歧的法子集中事件数量(如:按用户,按主机,按线程等等)。例如:要查阅哪些instruments占用最多的光阴,能够经过对events_waits_summary_global_by_event_name表的COUNT_STAR或SUM_TIMER_WAIT列实行询问(那两列是对事件的记录数执行COUNT(*)、事件记录的TIME奥德赛_WAIT列执行SUM(TIMER_WAIT)总计而来),如下:

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

AVG _TIMER_WAIT: 0

产品:沃趣科学技术

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

SUM_ROWS_EXAMINED: 39718

|
events_statements_summary_by_user_by_event_name |

·INTERNAL_LOCK:在SQL级别使用的表锁。有效值为:READ、READ WITH
SHARED LOCKS、READ HIGH P翼虎IOPAJEROITY、READ NO INSE君越T、W翼虎ITE ALLOW
W奥迪Q5ITE、W福睿斯ITE CONCU奥迪Q五RENT INSEQX56T、WMuranoITE LOW
P酷威IOLacrosseITY、WCRUISERITE。有关那些锁类型的详细消息,请参阅include/thr_lock.h源文件;

SUM_WARNINGS: 0

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

AVG_TIMER_READ: 0

COUNT_STAR: 0

行使show命令来询问你的数据库实例是还是不是帮助INFO猎豹CS陆MATION_SCHEMA引擎

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

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

Rowsmatched: 323 Changed: 0 Warnings: 0

·ATTR_NAME:连接属性名称;

| Tables_in_performance_schema (%events_statements_summary%) |

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

当客户端断开连接时,performance_schema将滑坡对应连接的行中的CU路虎极光RENT_CONNECTIONS列,保留TOTAL_CONNECTIONS列值。

| events_waits_summary_by_account_by_event_name |

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

| qfsys |10.10. 20.15| 1 |1|

MIN _TIMER_WAIT: 0

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

metadata_locks表是只读的,不只怕立异。暗中同意保留行数会活动调整,假若要配备该表大小,可以在server运营以前设置系统变量performance_schema_max_metadata_locks的值。

COUNT_STAR: 0

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

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

| events_statements_summary_by_program |

NUMBER_OF_BYTES: NULL

4 rows in set (0.00 sec)

| events_statements_summary_by_host_by_event_name |

| events_waits_current |

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

由于performance_schema表内部存款和储蓄器限制,所以保养了DIGEST
= NULL的与众差别行。
当events_statements_summary_by_digest表限制体量已满的景况下,且新的语句总括消息在要求插入到该表时又从未在该表中找到匹配的DIGEST列值时,就会把这一个语句总括消息都总结到
DIGEST =
NULL的行中。此行可帮助您揣摸events_statements_summary_by_digest表的界定是不是必要调整

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

……

MAX _TIMER_WAIT: 0

|EVENT_NAME | SUM_TIMER_WAIT |

SUM _NUMBER_OF _BYTES_READ: 11567104

CURRENT _NUMBER_OF _BYTES_USED: 0

| NO |NO | NO |

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

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

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

·OBJECT_INSTANCE_BEGIN:mutex instruments实例的内存地址;

# events_statements_summary_by_host_by_event_name表

| setup_objects |

LOCK_TYPE: SHARED_READ

EVENT_NAME: stage/sql/After create

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

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

*
HIGH_NUMBER_OF_BYTES_USED:如果CURRENT_NUMBER_OF_BYTES_USED增加N之后是二个新的最高值,则该字段值相应增多

11rows inset (0.00sec)

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

events_statements_summary_by_program:根据各类存储程序(存款和储蓄进程和函数,触发器和事件)的风浪名称举行总结的Statement事件

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

·已给予的锁(展现怎么会话拥有当前元数据锁);

# events_transactions_summary_by_host_by_event_name表

|wait/io/file/sql/FRM | 1292823243
|

·已被死锁检验器检查测试到并被杀死的锁,只怕锁请求超时正值班守护候锁请求会话被放任。

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

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

· OBJECT_INSTANCE_BEGIN:instruments condition的内存地址;

SUM_SORT_ROWS: 170

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

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

| events_statements_summary_by_thread_by_event_name |

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

·HOST:某老是的客户端主机名。假若是1个里面线程创立的连日,也许是无能为力表明的用户创设的连年,则该字段为NULL;

1 row in set (0.00 sec)

然后,简单介绍了什么飞快上手使用performance_schema的方法;

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

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;

·SOU大切诺基CE:源文件的称号,在那之中包罗生成事件音信的检测代码行号;

# events_transactions_summary_by_user_by_event_name表

| variables_by_thread |

(2)table_handles表

SUM _TIMER_READ_ONLY: 57571000

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

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

关于events_statements_summary_by_digest表

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

* _client_license:连接器许可证类型

events_statements_summary_by_digest:依据每一个库级别对象和言辞事件的原始语句文本计算值(md5hash字符串)举办总结,该计算值是依据事件的原始语句文本实行简易(原始语句转换为规范语句),每行数据中的相关数值字段是有着相同计算值的计算结果。

OPERATION: lock

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

| Tables_in_performance_schema (%events_waits_summary%) |

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

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

USER: NULL

1row inset (0.00sec)

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

SUM_NO_INDEX_USED: 42

本文首先,大概介绍了什么是performance_schema?它能做哪些?

COUNT_STAR: 2560

SUM_TIMER_WAIT:总结给定计时事件的总等待时间。此值仅针对有计时坚守的事件instruments或打开了计时成效事件的instruments,若是某事件的instruments不辅助计时要么尚未打开计时功效,则该字段为NULL。其余xxx_TIMER_WAIT字段值类似

SPINS: NULL

| table_io_waits_summary_by_index_usage |#
依据每一个索引举行计算的表I/O等待事件

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

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

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

events_waits_summary_by_user_by_event_name表:按照列EVENT_NAME、USEXC90举行分组事件消息

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

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

可由此如下语句查看语句事件总括表:

instance表记录了如何项指标对象会被检查实验。这么些指标在被server使用时,在该表少校会时有爆发一条事件记录,例如,file_instances表列出了文件I/O操作及其关系文件名:

1row inset ( 0. 00sec)

1 row in set (0.00 sec)

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

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

HOST: localhost

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

| USER |HOST | CURRENT_CONNECTIONS |TOTAL_CONNECTIONS |

COUNT_ALLOC: 158

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

OBJECT_NAME: test

# events_transactions_summary_by_account_by_event_name表

OBJECT_TYPE: NULL

| file_summary_by_instance |

1 row in set (0.00 sec)

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

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

*
假使1个线程没有打开采集效用,不过内部存款和储蓄器相关的instruments启用了,则该内部存款和储蓄器释放的操作会被监控到,总计数据会产生改变,这也是前边提到的干什么反复在运转时修改memory
instruments或然造成总括数据为负数的来由

| file_summary_by_event_name |

performance_schema怎样管理metadata_locks表中记录的始末(使用LOCK_STATUS列来表示每一个锁的场馆):

EVENT_NAME: statement/sql/select

qogir_env@localhost :
performance_schema 03:55:07>
show tables like ‘events_stage%’;

prepared_statements_instances表字段含义如下:

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

| Tables_in_performance_schema
(%statement%) |

OBJECT_SCHEMA: xiaoboluo

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

| cond_instances |

socket_instances表字段含义如下:

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

今昔,我们早已差不离知道了performance_schema中的首要表的分类,但,怎样行使他们来为大家提供应和供给要的品质事件数量吧?上面,咱们介绍如何通过performance_schema下的布置表来配置与使用performance_schema。

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

USER: NULL

| Tables_in_performance_schema
(%setup%) |

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

MIN _TIMER_WAIT: 0

| Tables_in_performance_schema
(%stage%) |

| Tables_in_performance_schema (%socket%summary%) |

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

END_EVENT_ID: 60

小编们先来看看表中著录的总计音信是怎么着样子的。

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

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

·socket_summary_by_instance:针对各种socket实例的享有 socket
I/O操作,这几个socket操作相关的操作次数、时间和发送接收字节音讯由wait/io/socket/*
instruments发生。但当连接中断时,在该表中对应socket连接的音信就要被删去(那里的socket是指的如今活跃的连日创设的socket实例)

DIGEST: 4fb483fe710f27d1d06f83573c5ce11c

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

| FILE_NAME |EVENT_NAME | OPEN_COUNT |

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

87rows inset (0.00sec)

table_handles表是只读的,不能立异。暗许自动调整表数据行大小,若是要显式钦点个,可以在server运行以前设置系统变量performance_schema_max_table_handles的值。

OBJECT_TYPE: PROCEDURE

| events_statements_summary_by_digest
|

(4)rwlock_instances表

MAX _TIMER_WAIT: 0

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

(1)accounts表

EVENT_NAME: transaction

|performance_schema | ON |

COUNT _READ_WITH _SHARED_LOCKS: 0

1 row in set (0.00 sec)

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

EVENT_NAME: wait/io/socket/sql/client_connection

从上面表中的言传身教记录新闻中,我们得以见到:

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

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

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

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

·COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT:这么些列总括全部socket读写操作的次数和岁月新闻

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

performance_schema库下的表能够根据监视分歧的纬度进行了分组,例如:或依照不一样数据库对象开始展览分组,或根据不一致的风浪类型举行分组,或在遵照事件类型分组之后,再进一步依据帐号、主机、程序、线程、用户等,如下:

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

root@localhost : performance _schema 11:08:05> select * from
events_waits _summary_by_instance limit 1G

| accounts |

·当在此之前请求不可能即刻获得的锁在那之后被赋予时,其锁消息行状态更新为GRANTED;

| events_stages_summary_by_account_by_event_name |

87rows inset (0.00sec)

·file_summary_by_instance:依照各种文件实例(对应现实的各种磁盘文件,例如:表sbtest1的表空间文件sbtest一.ibd)举办总括的公文IO等待事件

events_statements_summary_by_program表有友好额外的总计列:

| variables_by_thread |

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

内部存款和储蓄器行为监察装置:

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

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

| memory_summary_by_host_by_event_name |

数据库刚刚开首化并运维时,并非全部instruments(事件采访项,在收集项的配备表中每一项都有一个开关字段,或为YES,或为NO)和consumers(与征集项类似,也有二个对应的风云类型保存表配置项,为YES就意味着对应的表保存质量数据,为NO就象征对应的表不保留质量数据)都启用了,所以默许不会征集全数的轩然大波,大概你需求检查实验的事件并不曾打开,供给开始展览安装,能够动用如下多少个语句打开对应的instruments和consumers(行计数恐怕会因MySQL版本而异),例如,大家以布置监测等待事件数量为例实行求证:

1row inset ( 0. 00sec)

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

| events_statements_current |

·PO君越T:TCP/IP端口号,取值范围为0〜6553五;

# events_transactions_summary_by_thread_by_event_name表

|
events_transactions_summary_global_by_event_name |

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

| 温馨提醒

INDEX_NAME: NULL

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

1row inset ( 0. 00sec)

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

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

AVG _TIMER_WAIT: 0

|
events_waits_summary_by_host_by_event_name |

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

下壹篇将为我们分享
《数据库对象事件总计与品质总计 | performance_schema全方位介绍》
,多谢你的读书,我们不见不散!归来新浪,查看越来越多

| Tables_in_performance_schema
(%memory%) |

我们先来探视表中记录的总计音信是如何体统的。

对此内部存款和储蓄器计算表中的低水位推测值,在memory_summary_global_by_event_name表中假若内部存款和储蓄器全体权在线程之间传输,则该估摸值可能为负数

2、performance_schema使用便捷入门

…………

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

布局好之后,大家就能够查阅server当前正在做什么样,能够由此查询events_waits_current表来获知,该表中每一个线程只含有一行数据,用于体现各样线程的风行监视事件(正在做的工作):

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

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

|1、**什么是performance_schema**

MAX_TIMER_WAIT: 9498247500

MAX _TIMER_WAIT: 0

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

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

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

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

MAX_TIMER_READ: 0

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

Rowsmatched: 3 Changed: 3 Warnings: 0

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

1 row in set (0.00 sec)

| events_statements_history |

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

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

| EVENT_NAME |COUNT_STAR |

上一篇 《事件总计 |
performance_schema全方位介绍》详细介绍了performance_schema的风浪总计表,但那个计算数据粒度太粗,仅仅根据事件的中国共产党第五次全国代表大会门类+用户、线程等维度举办分拣总计,但偶尔大家须要从更细粒度的维度实行归类总括,例如:有个别表的IO开销多少、锁费用多少、以及用户连接的局地品质计算音信等。此时就须要查阅数据库对象事件总计表与品质计算表了。今日将指导我们齐声踏上铺天盖地第陆篇的征程(全系共多少个篇章),本期将为大家无微不至授课performance_schema中指标事件总计表与天性总括表。下边,请随行我们一块起来performance_schema系统的求学之旅吧~

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

|
events_statements_summary_by_account_by_event_name |

# table_lock_waits_summary_by_table表

IT从业多年,历任运营工程师、高级运营工程师、运营组长、数据库工程师,曾子与版本发布类别、轻量级监察和控制系统、运行管理平台、数据库管理平台的筹划与编辑,熟知MySQL种类布局,Innodb存储引擎,喜好专研开源技术,追求完美。

| events_waits_history |

·IP:客户端IP地址。该值能够是IPv四或IPv6地址,也得以是空荡荡,表示那是二个Unix套接字文件延续;

# events_stages_summary_by_thread_by_event_name表

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

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

MAX _TIMER_WAIT: 0

  1. 提供了一种在数据库运转时实时检查server的内部实市价况的章程。performance_schema
    数据库中的表使用performance_schema存款和储蓄引擎。该数据库重点关怀数据库运维进度中的质量相关的数额,与information_schema不同,information_schema首要关切server运营进程中的元数据信息
  2. performance_schema通过监视server的轩然大波来兑现监视server内部运汇兑况,
    “事件”正是server内部活动中所做的此外业务以及对应的光阴消耗,利用那个音信来判断server中的相关能源消耗在了哪儿?1般的话,事件能够是函数调用、操作系统的等候、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的表中的数目不会持久化存款和储蓄在磁盘中,而是保存在内部存款和储蓄器中,1旦服务重视启,这个多少会丢掉(包涵配置表在内的凡事performance_schema下的保有数据)
  9. MySQL辅助的享有平长沙事件监察和控制功用都可用,但不一样平纽伦堡用于总括事件时间支付的计时器类型也许会具备差别。

*
已形成的等候事件将助长到events_waits_history和events_waits_history_long表中

*
LOW_COUNT_USED和HIGH_COUNT_USED将重置为CURAV4RENT_COUNT_USED列值

| events_waits_summary_by_instance
|

socket_instances表列出了连接到MySQL
server的活泼接连的实时快速照相新闻。对于每种连接到mysql
server中的TCP/IP或Unix套接字文件接二连三都会在此表中记录一行信息。(套接字计算表socket_summary_by_event_name和socket_summary_by_instance中提供了1部分叠加新闻,例如像socket操作以及互连网传输和接受的字节数)。

MAX _TIMER_WAIT: 0

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

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

* CURRENT_NUMBER_OF_BYTES_USED:减少N

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

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

COUNT_STAR: 53

ORDER BY COUNT_STAR DESC LIMIT 10;

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

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

OBJECT_NAME: NULL

·THREAD_ID:由server分配的内部线程标识符,各样套接字都由单个线程实行保管,由此种种套接字都能够映射到1个server线程(借使得以映射的话);

……

1row inset (0.00sec)

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

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

|
events_statements_summary_by_host_by_event_name |

·当一个线程正在等候某事发生时,condition
NAME列展现了线程正在等待什么condition(但该表中并不曾其余列来显示对应哪个线程等信息),不过当前还未曾一向的法子来判定有些线程或1些线程会促成condition发生转移。

……

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

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

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

TIMER_WAIT: 65664

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

品质事件总括表中的某部instruments是还是不是推行总括,信赖于在setup_instruments表中的配置项是还是不是开启;

IT从业多年,历任运营工程师、高级运营工程师、运营高管、数据库工程师,曾插足版本揭橥系统、轻量级监察和控制类别、运转管理平台、数据库管理平台的陈设与编辑,熟识MySQL类别布局,Innodb存储引擎,喜好专研开源技术,追求弹无虚发。

COUNT_STAR: 213055844

MAX _TIMER_WAIT: 2427645000

2.3. performance_schema表的分类

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

EVENT_NAME: wait/synch/mutex/mysys/THR_LOCK_heap

|
memory_summary_by_thread_by_event_name |

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

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

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

套接字事件总括了套接字的读写调用次数和殡葬接收字节计数音讯,socket事件instruments私下认可关闭,在setup_consumers表中无实际的呼应配置,包罗如下两张表:

SUM_SELECT_RANGE: 0

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

·SOCKET_ID:分配给套接字的里边文件句柄;

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

本文小结

hosts表字段含义如下:

我们先来看望那么些表中著录的总结音讯是如何样子的(由于单行记录较长,那里只列出events_transactions_summary_by_account_by_event_name表中的示例数据,别的表的演示数据省略掉一部分雷同字段)。

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

AVG_TIMER_WAIT: 514656000

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

  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本子暗中同意安装

| NAME |OBJECT_INSTANCE_BEGIN | WRITE_LOCKED_BY_THREAD_ID
|READ_LOCKED_BY_COUNT |

COUNT_STAR: 7

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

MIN_TIMER_READ_NORMAL: 0

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

5rows inset (0.00sec)

AVG_TIMER_READ_NORMAL: 0

EVENT_NAME: transaction

| 0 |

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

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

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

| USER |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |

当server中的某线程执行了内部存款和储蓄器分配操作时,根据如下规则进行检验与聚集:

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

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

SUM _TIMER_WAIT: 0

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

3rows inset ( 0. 00sec)

PS1:

二.1检查当前数据库版本是或不是帮忙

两张表中著录的剧情很接近:

MIN _TIMER_WAIT: 57571000

……

1 row in set (0.00 sec)

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

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

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

MIN _TIMER_WAIT: 0

| 4 |342|
wait/synch/mutex/innodb/fil_system_mutex |32832|

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

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

| setup_instruments |

可透过如下语句查看:

对此较高级其他集合(全局,按帐户,按用户,按主机)总计表中,低水位和高水位适用于如下规则

| THREAD_ID |EVENT_ID | EVENT_NAME |TIMER_WAIT |

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

performance_schema把等待事件总结表遵照区别的分组列(分化纬度)对等候事件相关的数目进行联谊(聚合总括数据列包罗:事件发生次数,总等待时间,最小、最大、平均等待时间),注意:等待事件的收集功用有一部分暗中认可是剥夺的,供给的时候能够经过setup_instruments和setup_objects表动态开启,等待事件总计表包涵如下几张表:

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

·一旦值为NULL,则象征表I/O未有动用到目录

*
倘诺给定语句的总计音信行在events_statements_summary_by_digest表中从未已存在行,并且events_statements_summary_by_digest表空间限制未满的情况下,会在events_statements_summary_by_digest表中新插入壹行总计消息,FI奥迪Q5ST_SEEN和LAST_SEEN列都选拔当前时光

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

下篇将为我们分享 《复制状态与变量记录表 |
performance_schema全方位介绍》 ,谢谢您的读书,大家不见不散!归来微博,查看愈来愈多

AVG _TIMER_WAIT: 0

|
events_transactions_summary_by_user_by_event_name |

| table_io_waits_summary_by_table |#
根据各个表展开计算的表I/O等待事件

MIN _TIMER_WAIT: 0

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

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

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

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

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

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

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

COUNT_READ: 0

……

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

·OWNER_EVENT_ID:触发table
handles被打开的事件ID,即持有该handles锁的事件ID;

events_statements_summary_by_thread_by_event_name:根据每种线程和事件名称进行总结的Statement事件

ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

·USE路虎极光:某老是的客户端用户名。固然是贰个之中线程创造的连年,大概是力不从心证实的用户创制的接连,则该字段为NULL;

USER: root

|
events_waits_summary_by_user_by_event_name |

1row inset ( 0. 00sec)

MIN _TIMER_WAIT: 0

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

·READ_LOCKED_BY_COUNT:当1个线程在共享(读)方式下持有1个rwlock时,READ_LOCKED_BY_COUNT列值扩张一,所以该列只是多少个计数器,无法一向用于查找是哪些线程持有该rwlock,但它能够用来查看是或不是留存二个关于rwlock的读争用以及查看当前有多少个读格局线程处于活跃状态。

root@localhost : performance _schema 11:42:37> select * from
events_stages _summary_by _user_by _event_name where user is not
null limit 1G

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

注意:rwlock_instances表中的消息只好查看到持有写锁的线程ID,然则不可能查看到有着读锁的线程ID,因为写锁WSportageITE_LOCKED_BY_THREAD_ID字段记录的是线程ID,读锁惟有1个READ_LOCKED_BY_COUNT字段来记录读锁被有些个线程持有。

* CURRENT_COUNT_USED:减少1

qogir_env@localhost : performance_schema 06:19:20> SELECT
EVENT_NAME,SUM_TIMER_WAIT FROM
events_waits_summary_global_by_event_name

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

EVENT_NAME: stage/sql/After create

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

admin@localhost : performance_schema 10:28:45> select * from
rwlock_instances limit 1;

COUNT_STAR: 0

|
events_transactions_summary_by_thread_by_event_name |

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

| events_waits_summary_by_host_by_event_name |

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

MAX_TIMER_EXECUTE: 0

| events_waits_summary_by_thread_by_event_name |

|wait/io/file/myisam/kfile | 102 |

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

SUM_SORT_SCAN: 6

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

metadata_locks表字段含义如下:

1 row in set (0.01 sec)

……

SUM_TIMER_WAIT: 412754363625

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

| setup_actors |

SUM_LOCK_TIME: 0

注意:那么些表只针对阶段事件音信进行总结,即包罗setup_instruments表中的stage/%开头的采集器,每种阶段事件在各类表中的总括记录行数须要看如何分组(例如:根据用户分组总括的表中,有稍许个活泼用户,表中就会有微微条相同采集器的笔录),其余,总括计数器是不是见效还索要看setup_instruments表中相应的阶段事件采集器是或不是启用。

等级事件记录表,记录语句执行的阶段事件的表,与话语事件类型的相关记录表类似:

OBJECT_TYPE: TABLE

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

|
events_waits_summary_by_thread_by_event_name |

COUNT_STAR: 24

*
HIGH_COUNT_USED和HIGH_NUMBER_OF_BYTES_USED是较高的高水位估摸值。performance_schema输出的低水位值能够确定保障总结表中的内部存款和储蓄器分配次数和内部存款和储蓄器大于或等于当前server中真实的内部存款和储蓄器分配值

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

1 row in set (0.00 sec)

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

_current表中每一个线程只保留一条记下,且只要线程完结工作,该表中不会再记录该线程的风浪消息,_history表中记录各个线程已经执行到位的风云新闻,但各样线程的只事件音信只记录10条,再多就会被遮住掉,*_history_long表中著录所无线程的轩然大波消息,但总记录数据是一千0行,当先会被遮盖掉,未来大家查看一下历史表events_waits_history
中著录了什么样:

·PHP定义的个性正视于编写翻译的属性:

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

2.4.
performance_schema简单安顿与利用

依照数据库对象名称(库级别对象和表级别对象,如:库名和表名)举办总括的等候事件。遵照OBJECT_TYPE、OBJECT_SCHEMA、OBJECT_NAME列实行分组,按照COUNT_STAR、xxx_TIMER_WAIT字段进行总计。包括一张objects_summary_global_by_type表。

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

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

TIMER_PREPARE: 896167000

MIN _TIMER_READ_ONLY: 57571000

| events_transactions_history |

·当呼吁立时获得元数据锁时,将插入状态为GRANTED的锁音讯行;

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

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

责编:

*
要是3个线程开启了搜集效用,不过内部存款和储蓄器相关的instruments未有启用,则该内部存款和储蓄器释放操作不会被监督到,计算数据也不会产生变动

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

·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从闲暇状态切换成活动状态,并回复套接字连接的年华采访功效。

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

|Transactions | XA |Savepoints
|

·OWNER_THREAD_ID:请求元数据锁的线程ID;

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

图片 1

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

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

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

3 rows in set (0.00 sec)

performance_schema会记录内部存款和储蓄器使用情状并集结内部存款和储蓄器使用计算消息,如:使用的内部存款和储蓄器类型(各类缓存,内部缓冲区等)和线程、帐号、用户、主机的相关操作直接举行的内部存款和储蓄器操作。performance_schema从使用的内部存储器大小、相关操作数量、高低水位(内部存款和储蓄器1回操作的最大和微小的有关总括值)。

下篇将为大家分享
“performance_schema之2(配置表详解)”
,多谢您的读书,大家不见不散!归来腾讯网,查看越多

| file_summary_by_event_name |

| events_stages_summary_global_by_event_name |

|
events_stages_summary_by_user_by_event_name |

EVENT_NAME: wait/io/socket/sql/client_connection

* 如果DIGEST =
NULL行的COUNT_STA奥迪Q五列值占据整个表中全体总计音讯的COUNT_STA翼虎列值的比重大于0%,则代表存在由于该表限制已满导致壹些语句总计音信无法归类保存,假诺你供给保留全部语句的总括音信,能够在server运行在此以前调整系统变量performance_schema_digests_size的值,私下认可大小为200

| cond_instances |

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

内存事件计算表有如下几张表:

| events_stages_current |

truncate
*_summary_global总括表也会隐式地truncate其对应的连天和线程总结表中的新闻。例如:truncate
events_waits_summary_global_by_event_name会隐式地truncate遵照帐户,主机,用户或线程总计的守候事件总结表。

出品:沃趣科学技术

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

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

属性事件计算表在setup_consumers表中只受控于”global_instrumentation”配置项,也正是说1旦”global_instrumentation”配置项关闭,所有的计算表的总结条目都不执行总结(总计列值为0);

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

* _pid:客户端进度ID

performance_schema把工作事件总计表也遵从与等待事件计算表类似的规则进行归类总结,事务事件instruments唯有1个transaction,私下认可禁止使用,事务事件总括表有如下几张表:

EVENT_NAME:
wait/synch/mutex/innodb/log_sys_mutex

(2)file_instances表

USER: NULL

主要编辑:

hosts表包括客户端连接到MySQL
server的主机音讯,八个主机名对应壹行记录,该表针对主机作为唯一标识进行计算当前连接数和总连接数。server运行时,表的大小会活动调整。
要显式设置该表大小,能够在server运维在此以前安装系统变量performance_schema_hosts_size的值。假设该变量设置为0,则意味着禁用hosts表总括新闻。

| 等待事件总结表

| Engine |Support | Comment

·对此已接受的连年,performance_schema根据performance_schema_session_connect_attrs_size系统变量的值检查总结连接属性大小。假设属性大小当先此值,则会进行以下操作:

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

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

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

| Tables_in_performance_schema (%prepare%) |

“翻过这座山,你就足以见到一片海”

SUM _TIMER_READ: 56688392

MAX _TIMER_WAIT: 0

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

对于使用C
API运行的连年,libmysqlclient库对客户端上的客户端面连接属性数据的总计大小的固化长度限制为64KB:超出限制时调用mysql_options()函数会报CR_INVALID_PARAMETER_NO错误。其余MySQL连接器恐怕会安装自个儿的客户端面包车型大巴总是属性长度限制。

COUNT_ALLOC: 216

本篇内容到那边就像尾声了,相信广大人都觉得,我们大部分时候并不会直接动用performance_schema来查询品质数据,而是采纳sys
schema下的视图代替,为何不直接攻读sys schema呢?那你领会sys
schema中的数据是从哪个地方吐出来的呢?performance_schema
中的数据实际上主借使从performance_schema、information_schema中获得,所以要想玩转sys
schema,全面精通performance_schema不可或缺。另外,对于sys
schema、informatiion_schema甚至是mysql
schema,咱们继续也会推出分裂的如10草芥小说分享给我们。

OBJECT _INSTANCE_BEGIN: 139968890586816

PS2:至于存款和储蓄程序监察和控制行为:对于在setup_objects表中启用了instruments的贮存程序类型,events_statements_summary_by_program将保险存款和储蓄程序的计算音讯,如下所示:

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

·借助于于连接表中国国投息的summary表在对那几个连接表执行truncate时会同时被隐式地推行truncate,performance_schema维护着根据accounts,hosts或users总结各样风浪总括表。那一个表在名称包罗:_summary_by_account,_summary_by_host,*_summary_by_user

OBJECT_NAME: ps_setup_enable_consumer

| FILE_NAME |EVENT_NAME | OPEN_COUNT |

table_io_waits_summary_by_index_usage表:

| 语句事件总计表

相关文章