【新京葡娱乐场388官网】初相识|performance_schema全方位介绍(一)

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

users表字段含义如下:

DIGEST_TEXT: SELECT @@`version_comment` LIMIT ?

EVENT_ID: 60

·THREAD_ID:由server分配的里边线程标识符,各类套接字都由单个线程进行田管,因而种种套接字都得以映射到一个server线程(借使能够映射的话);

COUNT_STAR: 0

Rowsmatched: 3 Changed: 3 Warnings: 0

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

| memory_summary_by_account_by_event_name |

| events_transactions_history |

……

1 row in set (0.00 sec)

……

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

events_statements_summary_by_program表有协调额外的总结列:

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

MIN _TIMER_READ: 56688392

DIGEST: 4fb483fe710f27d1d06f83573c5ce11c

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

rwlock_instances表字段含义如下:

OBJECT_SCHEMA: sys

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

hosts表包蕴客户端连接到MySQL
server的主机音信,二个主机名对应一行记录,该表针对主机作为唯一标识举办总括当前连接数和总连接数。server运行时,表的大小会活动调整。
要显式设置该表大小,能够在server运行从前安装系统变量performance_schema_hosts_size的值。如果该变量设置为0,则象征禁止使用hosts表计算音讯。

USER: root

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

| wait/io/socket/sql/client_connection |110667840 | 45 |51|
::ffff:10.10.20.15 |56842| ACTIVE |

THREAD_ID: 47

2.3. performance_schema表的归类

* _client_version:客户端libmysql库版本

7rows inset ( 0. 00sec)

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

·server只接受的连日属性数据的总结大小限制为64KB。假设客户端尝试发送超过64KB(正好是1个表全体字段定义长度的总限制长度)的属性数据,则server将不容该连接;

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

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

metadata_locks表字段含义如下:

events_statements_summary_global_by_event_name:依据每种事件名称举办计算的Statement事件

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

3rows inset ( 0. 00sec)

root@localhost : performance _schema 11:03:19> select * from
events_statements _summary_by _thread_by _event_name where
COUNT_STAR!=0 limit 1G

| setup_actors |

该表允许使用TRUNCATE
TABLE语句。只将计算列重置为零,而不是去除行。该表执行truncate时也会隐式触发table_io_waits_summary_by_table表的truncate操作。别的利用DDL语句更改索引结构时,会促成该表的装有索引总计音讯被重置

1 row in set (0.00 sec)

END_EVENT_ID: 60

OBJECT_SCHEMA: xiaoboluo

AVG _TIMER_WAIT: 0

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

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

# events_transactions_summary_by_user_by_event_name表

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

·WRITE_LOCKED_BY_THREAD_ID:当八个线程当前在独占(写入)方式下持有三个rwlock时,W奥迪Q3ITE_LOCKED_BY_THREAD_ID列可以查阅到独具该锁的线程THREAD_ID,假如没有被其它线程持有则该列为NULL;

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

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

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

| events_statements_summary_by_program |

OBJECT_INSTANCE_BEGIN: 955681576

OBJECT_SCHEMA: xiaoboluo

# events_waits_summary_by_account_by_event_name表

运用show命令来查询你的数据库实例是或不是帮助INFO景逸SUVMATION_SCHEMA引擎

Performance Schema通过metadata_locks表记录元数据锁消息:

admin@localhost : performance_schema 06:28:48> show tables like
‘%prepare%’;

ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

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

OBJECT_NAME: ps_setup_enable_consumer

| setup_instruments |

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

1 row in set (0.01 sec)

| variables_by_thread |

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

MAX _TIMER_READ_ONLY: 57571000

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;

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

# events_transactions_summary_by_thread_by_event_name表

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

OBJECT_TYPE: TABLE

SUM_TIMER_WAIT: 234614735000

| users |

·ATTR_VALUE:连接属性值;

SUM_ERRORS: 2

QueryOK, 0 rowsaffected(0.00sec)

socket_instances表字段含义如下:

# events_transactions_summary_global_by_event_name表

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

*
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_STATEMENTS,SUM_STATEMENTS_WAIT,MIN_STATEMENTS_WAIT,AVG_STATEMENTS_WAIT,MAX_STATEMENTS_WAIT:关于存款和储蓄程序执行时期调用的嵌套语句的总结新闻

| Tables_in_performance_schema
(%stage%) |

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

| memory_summary_by_host_by_event_name |

SOURCE: log0log.cc:1572

session_account_connect_attrs表仅包括当前三番五次及其相关联的别样总是的总是属性。要查看全体会话的接连属性,请查看session_connect_attrs表。

别的,根据帐户、主机、用户、线程聚合的种种等待事件总括表或然events_waits_summary_global_by_event_name表,固然借助的连接表(accounts、hosts、users表)执行truncate时,那么依赖的那一个表中的总结数据也会同时被隐式truncate

直接在performance_schema库下利用show
tables语句来查阅有哪些performance_schema引擎表:

performance_schema提供了针对性prepare语句的督察记录,并依据如下方法对表中的始末展开管制。

*
假使给定语句的计算信息行在events_statements_summary_by_digest表中没有已存在行,且events_statements_summary_by_digest表空间范围已满的气象下,则该语句的总括音信将增进到DIGEST
列值为
NULL的特殊“catch-all”行,借使该尤其行不存在则新插入一行,FI景逸SUVST_SEEN和LAST_SEEN列为当前岁月。要是该特别行已存在则更新该行的音信,LAST_SEEN为如今几日子

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

从上边表中的记录消息大家得以看出,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等待时间,那个表的分组和总结列含义请大家自行举一反三,那里不再赘述,上面针对那三张表做一些不可或缺的表明:

prepared_statements_instances:依照每一种prepare语句实例聚合的总括新闻

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

| USER |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |

* CURRENT_COUNT_USED:减少1

| Engine |Support | Comment

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

AVG _TIMER_WAIT: 0

|
events_statements_summary_by_user_by_event_name |

OBJECT _INSTANCE_BEGIN: 2658004160

# events_statements_summary_by_account_by_event_name表

8rows inset (0.00sec)

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

COUNT_STAR: 0

Rowsmatched: 323 Changed: 0 Warnings: 0

(2)session_connect_attrs表

注意:那些表只针对阶段事件新闻举办总结,即包罗setup_instruments表中的stage/%起首的采集器,种种阶段事件在各类表中的总括记录行数须要看什么分组(例如:依据用户分组总计的表中,有个别许个活泼用户,表中就会有多少条相同采集器的笔录),其它,总结计数器是不是见效还亟需看setup_instruments表中相应的阶段事件采集器是还是不是启用。

5rows inset (0.01sec)

* _program_name:客户端程序名称

USER: NULL

| events_statements_current |

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

#
events_statements_summary_by_program表(要求调用了储存进程或函数之后才会有多少)

NUMBER_OF_BYTES: NULL

| file_summary_by_event_name |

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

[mysqld]

users表包罗连接到MySQL
server的种种用户的延续新闻,每一种用户一行。该表将对准用户名作为唯一标识实行总结当前连接数和总连接数,server运转时,表的大大小小会自动调整。
要显式设置该表大小,能够在server运维从前安装系统变量performance_schema_users_size的值。该变量设置为0时意味着禁止使用users总结新闻。

COUNT_STAPRADO:事件被实践的数据。此值包蕴拥有事件的进行次数,须要启用等待事件的instruments

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

·当已予以的锁或挂起的锁请求被杀死时,其锁状态从GRANTED或PENDING更新为KILLED;

EVENT_NAME: statement/sql/select

performance_schema达成机制遵从以下设计目的:

| NAME |OBJECT_INSTANCE_BEGIN | LOCKED_BY_THREAD_ID |

MIN _TIMER_WAIT: 57571000

| TABLE_NAME |

1 row in set (0.00 sec)

HOST: NULL

下篇将为我们分享
“performance_schema之二(配置表详解)”
,感谢您的读书,大家不见不散!回到乐乎,查看越多

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

小编们先来探视那么些表中记录的总括新闻是怎么体统的(由于单行记录较长,那里只列出memory_summary_by_account_by_event_name
表中的示例数据,别的表的演示数据省略掉一部分同样字段)。

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

COUNT_REPREPARE: 0

| events_statements_summary_by_digest |

OPERATION: lock

admin@localhost : performance_schema 02:50:02> select * from
cond_instances limit 1;

# memory_summary_by_host_by_event_name表

“翻过那座山,你就可以见见一片海”

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

MAX _TIMER_WAIT: 0

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

OBJECT_NAME: test

COUNT_STAR: 7

TIMER_WAIT: 65664

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

# events_statements_summary_global_by_event_name表

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

session_account_connect_attrs表字段含义:

COUNT_STAR: 7

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

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

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

|
events_waits_summary_by_host_by_event_name |

EVENT_NAME: wait/io/file/innodb/innodb_data_file

| memory_summary_by_user_by_event_name |

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

·PROCESSLIST_ID:会话的连年标识符,与show
processlist结果中的ID字段相同;

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

本篇内容到那里就接近尾声了,相信广大人都是为,大家大多数时候并不会直接采用performance_schema来查询品质数据,而是选用sys
schema下的视图代替,为啥不直接攻读sys schema呢?那您了然sys
schema中的数据是从何地吐出来的吗?performance_schema
中的数据实际上根本是从performance_schema、information_schema中取得,所以要想玩转sys
schema,周密摸底performance_schema必不可少。此外,对于sys
schema、informatiion_schema甚至是mysql
schema,大家后续也会推出区别的不足为奇小说分享给我们。

·PS:cond_instances表不容许采纳TRUNCATE TABLE语句。

EVENT_NAME: transaction

|
memory_summary_by_host_by_event_name |

– END –

1 row in set (0.00 sec)

| Tables_in_performance_schema
(%memory%) |

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

MAX _TIMER_WAIT: 0

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

rwlock_instances表列出了server执行rwlock
instruments时performance_schema所见的有所rwlock(读写锁)实例。rwlock是在代码中央银行使的联合署名机制,用于强制在给定时间内线程可以根据有个别规则访问一些公共能源。可以认为rwlock珍重着这个能源不被别的线程随意抢占。访问方式能够是共享的(多少个线程能够同时负有共享读锁)、排他的(同时只有2个线程在加以时间足以有所排他写锁)或共享独占的(有个别线程持有排他锁定时,同时允许别的线程执行分歧性读)。共享独占访问被称为sxlock,该访问情势在读写场景下能够升高并发性和可扩大性。

COUNT _READ_ONLY: 1

MySQL的performance schema 用于监察和控制MySQL
server在一个较低级别的运营进程中的资源消耗、能源等待等情景,它装有以下特点:

该表的分组列与table_io_waits_summary_by_table表相同

MAX _TIMER_WAIT: 0

#
该事件新闻表示线程ID为4的线程正在等待innodb存款和储蓄引擎的log_sys_mutex锁,那是innodb存款和储蓄引擎的1个互斥锁,等待时间为65664飞秒(*_ID列表示事件源于哪个线程、事件编号是稍稍;EVENT_NAME表示检查和测试到的现实的剧情;SOU奥迪Q3CE表示那些检查和测试代码在哪些源文件中以及行号;计时器字段TIMECRUISER_START、TIMER_END、TIMER_WAIT分别代表该事件的始发时间、甘休时间、以及总的费用时间,假如该事件正在周转而从不实现,那么TIME奥迪Q5_END和TIMER_WAIT的值展现为NULL。注:计时器总计的值是看似值,并不是全然规范)

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

USER: root

……

COUNT_STAR: 213055844

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

QueryOK, 3 rowsaffected(0.04sec)

| FILE_NAME |EVENT_NAME | OPEN_COUNT |

| 语句事件计算表

今昔,很欣喜的告诉我们,大家依据 MySQL
官方文书档案加上大家的求证,整理了一份能够系统学习 performance_schema
的素材分享给大家,为了有利于大家阅读,大家整理为了二个两种,一共7篇小说。下边,请随行大家一并起来performance_schema系统的上学之旅吧。

* _pid:客户端进度ID

1 row in set (0.00 sec)

| Tables_in_performance_schema
(%wait%) |

SUM _NUMBER_OF _BYTES_READ: 0

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

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

SUM_TIMER_READ: 0

*
倘使三个线程开启了征集成效,可是内部存款和储蓄器相关的instruments没有启用,则该内部存款和储蓄器释放操作不会被监察和控制到,总括数据也不会时有发生转移

performance_schema库下的表能够服从监视不相同的纬度进行了分组,例如:或依据分歧数据库对象举行分组,或遵照分化的轩然大波类型实行分组,或在遵照事件类型分组之后,再进一步根据帐号、主机、程序、线程、用户等,如下:

·当server中部分代码创造了3个互斥量时,在mutex_instances表中会添加一行对应的互斥体音信(除非不可能再制造mutex
instruments
instance就不会添加行)。OBJECT_INSTANCE_BEGIN列值是互斥体的绝无仅有标识属性;

SUM_SELECT_SCAN: 45

|
events_statements_summary_by_thread_by_event_name |

file_instances表列出执行文书I/O
instruments时performance_schema所见的享有文件。
假诺磁盘上的文件没有打开,则不会在file_instances中著录。当文件从磁盘中除去时,它也会从file_instances表中删除相应的笔录。

如果setup_consumers配置表中statements_digest
consumers启用,则在讲话执行到位时,将会把讲话文本进行md5 hash总计之后
再发送到events_statements_summary_by_digest表中。分组列基于该语句的DIGEST列值(md5
hash值)

|1、**什么是performance_schema**

MIN_TIMER_READ_NORMAL: 0

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

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

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

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

产品:沃趣科学技术

OBJECT_TYPE: TABLE

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

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

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

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

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

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

HOST: localhost

正文小结

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

对于内部存款和储蓄器块的刑满释放解除劳教,依照如下规则进行检查和测试与聚集:

2.2. 启用performance_schema

……

AVG_TIMER_WAIT: 4426693000

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

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

1 row in set (0.00 sec)

| events_stages_history |

AVG_TIMER_READ: 0

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

当大家看来PE讴歌RDXFO卡宴MANCE_SCHEMA
对应的Support
字段输出为YES时就意味着我们当前的数据库版本是永葆performance_schema的。但敞亮大家的实例帮衬performance_schema引擎就足以行使了呢?NO,很不满,performance_schema在5.6及其以前的本子中,暗许没有启用,从5.7会同之后的版本才修改为暗中认可启用。今后,我们来看看哪些设置performance_schema暗许启用吧!

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

# events_waits_summary_by_thread_by_event_name表

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

STATEMENT_ID: 1

# events_stages_summary_global_by_event_name表

现行反革命,是或不是觉得上边的牵线内容太过平淡呢?尽管你如此想,那就对了,笔者那时上学的时候也是那样想的。但今后,对于怎么着是performance_schema那些难点上,比起更早以前更清晰了呢?借使您还不曾打算要吐弃读书本文的话,那么,请随行大家初叶进入到”边走边唱”环节呢!

# socket_summary_by_instance表

检查和测试内存工作负荷峰值、内部存款和储蓄器总体的劳作负荷稳定性、恐怕的内部存储器泄漏等是生死攸关的。

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

accounts表字段含义如下:

SUM_TIMER_WAIT:计算给定计时事件的总等待时间。此值仅针对有计时效劳的事件instruments或打开了计时作用事件的instruments,借使某事件的instruments不协助计时要么没有开启计时效率,则该字段为NULL。别的xxx_TIMER_WAIT字段值类似

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

·LOCK_DURATION:来自元数据锁子系统中的锁定时间。有效值为:STATEMENT、TRANSACTION、EXPLICIT,STATEMENT和TRANSACTION值分别代表在讲话或业务甘休时会释放的锁。
EXPLICIT值表示能够在言语或工作甘休时被会保留,必要显式释放的锁,例如:使用FLUSH
TABLES WITH READ LOCK获取的全局锁;

| events_waits_summary_by_account_by_event_name |

当今,你可以在performance_schema下选用show
tables语句也许经过询问
INFOEvoqueMATION_SCHEMA.TABLES表中performance_schema引擎相关的元数据来询问在performance_schema下存在着怎么表:

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

EVENT_NAME: transaction

| setup_consumers |

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

1 row in set (0.01 sec)

| events_transactions_history_long
|

每种连接消息表都有CU奥德赛RENT_CONNECTIONS和TOTAL_CONNECTIONS列,用于跟踪连接的近来连接数和总连接数。对于accounts表,每种连接在表中每行音信的绝无仅有标识为USE奇骏+HOST,可是对于users表,唯有3个user字段实行标识,而hosts表唯有3个host字段用于标识。

# events_statements_summary_by_thread_by_event_name表

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

| socket_summary_by_event_name |

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

|
events_statements_summary_global_by_event_name |

14 rows inset (0.01 sec)

在上一篇《事件记录 |
performance_schema全方位介绍”》中,大家详细介绍了performance_schema的轩然大波记录表,恭喜我们在就学performance_schema的旅途度过了多少个最劳苦的时期。今后,相信咱们早就相比清楚什么是事件了,但神迹大家不须求精通每时每刻发生的每一条事件记录消息,
例如:大家愿意领会数据库运转以来一段时间的轩然大波总括数据,那几个时候就须求查阅事件总括表了。前几日将引导大家齐声踏上聚讼纷繁第4篇的征途(全系共七个篇章),在这一期里,大家将为大家无微不至授课performance_schema中事件总括表。总括事件表分为四个品种,分别为等候事件、阶段事件、语句事件、事务事件、内部存款和储蓄器事件。上面,请跟随大家一同起来performance_schema系统的学习之旅吧。

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

| admin |1| 1 |

各种表都有各自的三个或两个分组列,以明确哪些聚合事件消息(全体表都有EVENT_NAME列,列值与setup_instruments表中NAME列值对应),如下:

|PERFORMANCE_SCHEMA | YES
|Performance Schema

# file_summary_by_instance表

SUM _TIMER_WAIT: 0

| events_waits_summary_by_instance
|

·SOU奥迪Q7CE:源文件的称谓,在那之中蕴藏生成事件消息的检查和测试代码行号;

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

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

(1)accounts表

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

instance表记录了哪些类型的目的会被检查和测试。那几个目的在被server使用时,在该表中校会时有发生一条事件记录,例如,file_instances表列出了文本I/O操作及其关系文件名:

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

1 row in set (0.00 sec)

|
memory_summary_by_account_by_event_name |

·OBJECT_TYPE:元数据锁子系统中应用的锁类型(类似setup_objects表中的OBJECT_TYPE列值):有效值为:GLOBAL、SCHEMA、TABLE、FUNCTION、PROCEDURE、TOdysseyIGGE卡宴(当前未选用)、EVENT、COMMIT、USEKugaLEVEL LOCK、TABLESPACE、LOCKING SE福特ExplorerVICE,USECR-V LEVEL
LOCK值表示该锁是选择GET_LOCK()函数获取的锁。LOCKING
SECRUISERVICE值表示使用锁服务赢得的锁;

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

| accounts |

……

* COUNT_ALLOC:增加1

| FILE_NAME |EVENT_NAME | OPEN_COUNT |

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

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

2.4.
performance_schema容易计划与使用

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

prepared_statements_instances表有投机额外的总括列:

|
memory_summary_by_user_by_event_name |

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

PS:内部存款和储蓄器总括表不包罗计时消息,因为内部存款和储蓄器事件不扶助时间消息征集。

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

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

events_waits_summary_by_instance表:按照列EVENT_NAME、OBJECT_INSTANCE_BEGIN举办分组事件音讯。假若三个instruments(event_name)创制有多个实例,则每一个实例都享有唯一的OBJECT_INSTANCE_BEGIN值,因而每一种实例会进展独立分组

使用
INFORMATION_SCHEMA.ENGINES表来询问你的数据库实例是或不是扶助INFOSportageMATION_SCHEMA引擎

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

USER: root

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

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

EVENT_NAME: memory/innodb/fil0fil

| cond_instances |

咱俩先来看看表中著录的计算音讯是哪些样子的。

1 row in set (0.00 sec)

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

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

SUM _TIMER_WAIT: 0

|
events_stages_summary_by_user_by_event_name |

·users:根据用户名对每种客户端连接进行总括。

COUNT_STAR: 1

|
events_stages_summary_global_by_event_name |

MAX_TIMER_WAIT: 9498247500

COUNT_STAR: 0

3rows inset (0.01sec)

mutex_instances表字段含义如下:

# events_statements_summary_by_user_by_event_name表

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

SUM_ROWS_SENT: 0

当某给定对象被执行时,其相应的总括消息将记录在events_statements_summary_by_program表中并展开总计。

  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帮助的有着平西安事件监察和控制功效都可用,但不相同平哈博罗内用来总括事件时间支付的计时器类型或然会持大相径庭。

STATEMENT_NAME: stmt

| events_transactions_summary_by_thread_by_event_name |

2、performance_schema使用高效入门

01

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

| file_instances |

·当呼吁元数据锁不能够即时赢得时,将插入状态为PENDING的锁新闻行;

本性事件总结表中的某部instruments是还是不是实施总结,信赖于在setup_instruments表中的配置项是或不是打开;

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

3rows inset ( 0. 00sec)

COUNT _READ_WRITE: 6

布置好之后,大家就足以查看server当前正在做哪些,能够透过查询events_waits_current表来获知,该表中种种线程只包罗一行数据,用于显示每一个线程的摩登监视事件(正在做的工作):

SUM_TIMER_WAIT: 412754363625

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

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

COUNT_STAR: 1

关于events_statements_summary_by_digest表

| events_statements_summary_by_digest
|

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

MIN _TIMER_WAIT: 0

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

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

SCHEMA_NAME: NULL

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

·MySQL Connector/Net定义了如下属性:

SUM _TIMER_WAIT: 0

ORDER BY COUNT_STAR DESC LIMIT 10;

·HOST:某老是的客户端主机名。假如是四个中间线程创制的接连,大概是力不从心证实的用户创设的连接,则该字段为NULL;

1 row in set (0.00 sec)

| Tables_in_performance_schema
(%file%) |

[Warning] Connection attributes oflength N were truncated

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

终极,简单介绍了performance_schema中由什么表组成,这么些表大致的功效是何许。

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

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

NESTING_EVENT_TYPE: NULL

5.prepare语句实例总结表

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

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

该表允许采纳TRUNCATE
TABLE语句。只将总括列重置为零,而不是删除行。对该表执行truncate还会隐式truncate
table_io_waits_summary_by_index_usage表

| events_statements_summary_by_account_by_event_name |

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

通过对以下八个表执行查询,能够兑现对应用程序的监察和控制或DBA可以检查和测试到关系互斥体的线程之间的瓶颈或死锁信息(events_waits_current能够查看到近日正值班守护候互斥体的线程音信,mutex_instances能够查阅到近日某些互斥体被哪些线程持有)。

EVENT_NAME: statement/sql/select

数据库刚刚早先化并运维时,并非全数instruments(事件采访项,在搜集项的配置表中每一项都有一个开关字段,或为YES,或为NO)和consumers(与征集项类似,也有一个心心相印的事件类型保存表配置项,为YES就表示对应的表保存品质数据,为NO就象征对应的表不保留质量数据)都启用了,所以默许不会采集全部的事件,大概您必要检测的风浪并不曾打开,须求展开设置,能够应用如下四个语句打开对应的instruments和consumers(行计数大概会因MySQL版本而异),例如,大家以布置监测等待事件数量为例进行验证:

大家先来探望表中记录的总计消息是哪些体统的。

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

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

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

# events_waits_summary_by_host_by_event_name表

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

OWNER_OBJECT_SCHEMA: NULL

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

|
events_statements_summary_by_account_by_event_name |

作者们先来探视表中记录的计算消息是怎么着体统的。

小编们先来探视那个表中记录的总计消息是如何体统的(由于单行记录较长,这里只列出events_transactions_summary_by_account_by_event_name表中的示例数据,别的表的演示数据省略掉一部分同样字段)。

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

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

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

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

可经过如下语句查看:

COUNT_STAR: 3

mysqld运营现在,通过如下语句查看performance_schema是或不是启用生效(值为ON表示performance_schema已开始化成功且能够应用了。即使值为OFF表示在启用performance_schema时发出一些错误。能够查阅错误日志实行排查):

……

*
HIGH_COUNT_USED:如果CURRENT_COUNT_USED扩大1是3个新的最高值,则该字段值相应增多

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

accounts表包罗连接到MySQL
server的种种account的笔录。对于每个帐户,没个user+host唯一标识一行,每行单独总括该帐号的方今连接数和总连接数。server运维时,表的大大小小会活动调整。要显式设置表大小,能够在server运行此前安装系统变量performance_schema_accounts_size的值。该系统变量设置为0时,表示禁止使用accounts表的总计音信意义。

MAX_TIMER_WAIT: 80968744000

……

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

*
LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED将重置为CUPRADORENT_NUMBER_OF_BYTES_USED列值

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

SUM _TIMER_READ: 56688392

从上边表中的言传身教记录信息中,大家得以见见,同样与等待事件类似,依照用户、主机、用户+主机、线程等纬度举办分组与总括的列,分组列与等待事件类似,这里不再赘言,但对于内部存款和储蓄器总结事件,计算列与任何三种事件总计列不一致(因为内存事件不总结时间支付,所以与其它三种事件类型相比较无一致计算列),如下:

| variables_by_thread |

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

root@localhost : performance _schema 11:01:51> select * from
events_statements _summary_by_digest limit 1G

  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在5.7.x版本私下认可安装

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

1 row in set (0.00 sec)

Database changed

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

| events_stages_summary_by_thread_by_event_name |

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

COUNT_READ: 0

1 row in set (0.00 sec)

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

* _runtime_vendor:Java运转环境(JRE)供应商名称

内部存储器事件instruments中除去performance_schema自个儿内部存款和储蓄器分配相关的轩然大波instruments配置暗中同意开启之外,别的的内部存款和储蓄器事件instruments配置都私下认可关闭的,且在setup_consumers表中从未像等待事件、阶段事件、语句事件与作业事件那样的独自布署项。

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

EVENT_NAME: wait/io/socket/sql/client_connection

EVENT_NAME: stage/sql/After create

87rows inset (0.00sec)

内需拥有互斥体的工作负荷能够被认为是处于贰个生死攸关地点的做事,多少个查询大概供给以种类化的法门(三回三个串行)执行这一个关键部分,但那可能是贰个私人住房的属性瓶颈。

Query OK, 377 rows affected (0.00 sec)

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

·OWNER_EVENT_ID:触发table
handles被打开的风波ID,即持有该handles锁的轩然大波ID;

| 事务事件总括表

通过从INFORMATION_SCHEMA.tables表查询有哪些performance_schema引擎的表:

OBJECT_NAME: test

*
倘使该线程在threads表中平昔不拉开采集成效或许说在setup_instruments中对应的instruments没有拉开,则该线程分配的内部存款和储蓄器块不会被监督

|
events_stages_summary_by_account_by_event_name |

应用程序能够采纳一些键/值对转移一些老是属性,在对mysql
server创设连接时传递给server。对于C
API,使用mysql_options()和mysql_options4()函数定义属性集。别的MySQL连接器能够行使一些自定义连接属性方法。

MAX _TIMER_WAIT: 0

……

同意实施TRUNCATE TABLE语句,可是TRUNCATE
TABLE只是重置prepared_statements_instances表的总括新闻列,不过不会去除该表中的记录,该表中的记录会在prepare对象被灭绝释放的时候自动删除。

HOST: NULL

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

OBJECT_TYPE: TABLE

*
COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE:执行prepare语句对象的总括消息

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

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

| events_transactions_summary_by_user_by_event_name |

从上文中大家已经精晓,performance_schema在5.7.x及其以上版本中默许启用(5.6.x及其以下版本默许关闭),如若要显式启用或关闭时,大家须求动用参数performance_schema=ON|OFF设置,并在my.cnf中开始展览布局:

EVENT_NAME: wait/io/socket/sql/client_connection

HIGH _NUMBER_OF _BYTES_USED: 32

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

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

EVENT_NAME: transaction

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

(4)rwlock_instances表

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

伺机事件记录表,与话语事件类型的相关记录表类似:

·表面锁对应存款和储蓄引擎层中的锁。通过调用handler::external_lock()函数来贯彻。(官方手册上说有贰个OPERATION列来区分锁类型,该列有效值为:read
external、write external。但在该表的定义上并不曾看到该字段)

*
FIRST_SEEN,LAST_SEEN:呈现某给定语句第3回插入
events_statements_summary_by_digest表和最后贰遍立异该表的时日戳

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

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

SUM _SELECT_FULL _RANGE_JOIN: 0

2.3.
performance_schema表的分类

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

COUNT_STAR: 0

| events_stages_history_long |

| qfsys |10.10. 20.15| 1 |1|

内部存款和储蓄器大小总括新闻有助于明白当下server的内部存款和储蓄器消耗,以便及时举行内部存款和储蓄器调整。内部存款和储蓄器相关操作计数有助于领悟当下server的内部存款和储蓄器分配器的完整压力,及时间控制制server质量数据。例如:分配单个字节第一百货公司万次与单次分配一百万个字节的性质花费是例外的,通过跟踪内部存款和储蓄器分配器分配的内部存款和储蓄器大小和分配次数就足以领略两岸的距离。

| Tables_in_performance_schema
(%statement%) |

应用程序可以采用mysql_options()和mysql_options4()C
API函数在一而再时提供一些要传递到server的键值对连日属性。

COUNT_STAR: 58

|导
很久从前,当自家还在品味着系统地球科学习performance_schema的时候,通过在网上各个搜索资料实行学习,但很不满,学习的作用并不是很扎眼,很多标称类似
“深切浅出performance_schema”
的篇章,基本上都是那种动不动就贴源码的作风,然后深刻了随后却出不来了。对系统学习performance_schema的作用有限。

7.锁对象记录表

HOST: localhost

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

1 row in set (0.00 sec)

root@localhost : performance _schema 11:02:15> select * from
events_statements _summary_by _host_by _event_name where
COUNT_STAR!=0 limit 1G

2.1. 检查当前数据库版本是或不是辅助

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

SUM_WARNINGS: 0

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

大家先来看望表中记录的总计消息是什么样子的。

我们先来看望那么些表中著录的计算消息是如何样子的。

| events_statements_history_long
|

SUM_TIMER_EXECUTE: 0

events_statements_summary_by_account_by_event_name:根据各类帐户和说话事件名称进行计算

PS:本体系作品所选拔的数据库版本为 MySQL
官方 5.7.17版本

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

USER: root

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

·已被死锁检查和测试器检查和测试到并被杀掉的锁,恐怕锁请求超时正在等候锁请求会话被甩掉。

当某给定对象在server中第3遍被运用时(即选拔call语句调用了蕴藏进程或自定义存款和储蓄函数时),将在events_statements_summary_by_program表中添加一行总括音讯;

| events_waits_history |

OBJECT_SCHEMA: xiaoboluo

MIN _TIMER_WAIT: 0

|
events_transactions_summary_by_account_by_event_name |

3rows inset ( 0. 00sec)

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

performance_schema被视为存款和储蓄引擎。比方该内燃机可用,则应当在INFO凯雷德MATION_SCHEMA.ENGINES表或SHOW
ENGINES语句的出口中都能够观察它的SUPPO昂科威T值为YES,如下:

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

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

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

数据库对象计算表

HOST: localhost

| setup_timers |

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

1 row in set (0.00 sec)

|
events_statements_summary_by_program |

AVG_TIMER_READ: 530278875

……

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

·CURRENT_CONNECTIONS:某帐号的近来连接数;

COUNT_STAR: 7

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

mutex_instances表不一致意使用TRUNCATE TABLE语句。

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

……

3rows inset ( 0. 00sec)

1 row in set (0.01 sec)

| cond_instances |

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

由于performance_schema表内部存款和储蓄器限制,所以敬服了DIGEST
= NULL的例外行。
当events_statements_summary_by_digest表限制体积已满的情况下,且新的言语总括音讯在要求插入到该表时又不曾在该表中找到匹配的DIGEST列值时,就会把那个语句总结音讯都计算到
DIGEST =
NULL的行中。此行可支持您猜度events_statements_summary_by_digest表的限量是不是必要调动

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

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

MAX _TIMER_WAIT: 0

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

OBJECT _INSTANCE_BEGIN: 2655350784

| Tables_in_performance_schema (%memory%summary%) |

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

MAX _TIMER_WAIT: 56688392

内部存储器事件在setup_consumers表中从未单身的安顿项,且memory/performance_schema/*
instruments私下认可启用,不也许在运转时或运营时关闭。performance_schema相关的内部存款和储蓄器总结音信只保存在memory_summary_global_by_event_name表中,不会保存在根据帐户,主机,用户或线程分类聚合的内部存款和储蓄器总括表中。

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

table_io_waits_summary_by_table表:

| 等待事件总括表

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

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

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

|
events_waits_summary_by_user_by_event_name |

OBJECT_NAME: test

SUM _CREATED_TMP _DISK_TABLES: 3

| users |

OBJECT _INSTANCE_BEGIN: 139968890586816

COUNT_STAR: 59

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

AVG_TIMER_WAIT: 514656000

SUM _TIMER_WAIT: 0

|performance_schema | ON |

·metadata_locks:元数据锁的兼具和伸手记录;

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

近日,大家通晓了在 MySQL 5.7.17
版本中,performance_schema
下一共有87张表,那么,那87帐表都是存放在什么数据的啊?大家怎样采纳他们来查询我们想要查看的数目吧?先别着急,我们先来探视那么些表是怎么分类的。

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

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

动态对performance_schema举行计划的配置表:

(3)hosts表

# events_statements_summary_by_digest表

|
events_statements_summary_by_host_by_event_name |

OBJECT_SCHEMA: xiaoboluo

对于种种线程的总结新闻,适用以下规则。

| events_waits_current |

文件I/O事件总结表只记录等待事件中的IO事件(不分包table和socket子体系),文件I/O事件instruments暗许开启,在setup_consumers表中无具体的附和配置。它包涵如下两张表:

# memory_summary_by_user_by_event_name表

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

| 4 |program_name | mysql |5|

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

| NO |NO | NO |

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

COUNT_STAR: 0

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

总是总括音讯表允许使用TRUNCATE
TABLE。它会同时删除总括表中尚无连接的帐户,主机或用户对应的行,重置有延续的帐户,主机或用户对应的行的并将其余行的CUCRUISERRENT_CONNECTIONS和TOTAL_CONNECTIONS列值。

COUNT_STAR: 0

| 0 |

truncate
*_summary_global计算表也会隐式地truncate其对应的一而再和线程总括表中的音信。例如:truncate
events_waits_summary_global_by_event_name会隐式地truncate按照帐户,主机,用户或线程计算的等待事件总结表。

MIN _TIMER_WAIT: 0

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

AVG_TIMER_EXECUTE: 0

*
LOW_NUMBER_OF_BYTES_USED,HIGH_NUMBER_OF_BYTES_USED:对应CURRENT_NUMBER_OF_BYTES_USED列的低和高水位标记

| file_summary_by_instance |

IP:PO陆风X8T列组合值可用以标识3个总是。该组合值在events_waits_xxx表的“OBJECT_NAME”列中使用,以标识那些事件消息是根源哪个套接字连接的:

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

今昔,大家早已大致知道了performance_schema中的首要表的归类,但,怎么样行使他们来为大家提供应和要求要的质量事件数量吧?下边,大家介绍如何通过performance_schema下的安排表来配置与运用performance_schema。

· 当行新闻中CUGL450RENT_CONNECTIONS
字段值为0时,执行truncate语句会删除这几个行;

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

|EVENT_NAME | SUM_TIMER_WAIT |

|admin | localhost |1| 1 |

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

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

咱俩先来看看表中记录的总括音讯是怎样样子的。

*
CURRENT_NUMBER_OF_BYTES_USED:增加N

打开等待事件的采集器配置项开关,要求修改setup_instruments
配置表中对应的采集器配置项

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

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

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

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

HOST: NULL

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

socket_instances表不容许采纳TRUNCATE TABLE语句。

| events_waits_summary_global_by_event_name |

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

socket_instances表列出了三番五次到MySQL
server的外向接连的实时快照新闻。对于各类连接到mysql
server中的TCP/IP或Unix套接字文件一连都会在此表中著录一行消息。(套接字总括表socket_summary_by_event_name和socket_summary_by_instance中提供了有的附加音讯,例如像socket操作以及互连网传输和收受的字节数)。

COUNT_ALLOC: 103

| events_transactions_current |

MIN_TIMER_READ: 15213375

*
读写作业经常比只读事务占用越多能源,由此事务总计表包涵了用于读写和只读事务的单身计算列

|
events_waits_summary_by_account_by_event_name |

EVENT_NAME: wait/io/socket/sql/client_connection

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

5rows inset (0.00sec)

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

*
内存instruments在setup_instruments表中具有memory/code_area/instrument_name格式的称号。但私下认可情形下当先4/8instruments都被剥夺了,暗中认可只开启了memory/performance_schema/*开头的instruments

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

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

| 导语

12rows inset (0.01sec)

# socket_summary_by_event_name表

*
平时,truncate操作会重置总计新闻的规格数据(即清空从前的数额),但不会修改当前server的内部存款和储蓄器分配等意况。也正是说,truncate内部存储器总结表不会放出已分配内部存款和储蓄器

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

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

| events_stages_summary_by_host_by_event_name |

相关文章

发表评论

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

*
*
Website