事件统计,performance_schema全方位介绍

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

| qfsys |1| 1 |

| 温馨提示

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

OBJECT_TYPE: TABLE

* CURRENT_COUNT_USED:增加1

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

AVG _TIMER_READ: 56688392

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

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

·当二个pending状态的锁被死锁检查和测试器检查和测试并选定为用于打破死锁时,那几个锁会被注销,并赶回错误音讯(EOdyssey_LOCK_DEADLOCK)给请求锁的对话,锁状态从PENDING更新为VICTIM;

HOST: NULL

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

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

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

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

SUM_TIMER_READ_NORMAL: 0

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

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

·prepare语句预编写翻译:COM_STMT_PREPARE或SQLCOM_PREPARE命令在server中开创八个prepare语句。如若语句检查和测试成功,则会在prepared_statements_instances表中新添加一行。要是prepare语句不能够检查和测试,则会扩充Performance_schema_prepared_statements_lost状态变量的值。

EVENT_NAME: stage/sql/After create

|
events_stages_summary_by_host_by_event_name |

admin@localhost : performance_schema 06:50:03> show tables like
‘%table%summary%’;

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

| file_summary_by_instance |

·OBJECT_NAME:instruments对象的名目,表级别对象;

| events_waits_summary_global_by_event_name |

| Tables_in_performance_schema
(%memory%) |

·hosts:遵照host名称对种种客户端连接举办总括;

SUM_ROWS_SENT: 1635

| EVENT_NAME |COUNT_STAR |

·rwlock_instances:查看当前rwlock行的片段锁音讯(独占锁被哪些线程持有,共享锁被某些个线程持有等)。

COUNT _READ_ONLY: 1

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

cond_instances表字段含义如下:

MAX _TIMER_WAIT: 0

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

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

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

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

COUNT_EXECUTE: 0

SUM _TIMER_WAIT: 0

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

咱俩先来探望表中记录的总括信息是怎么体统的。

| events_stages_summary_by_user_by_event_name |

| cond_instances |

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

EVENT_NAME: memory/innodb/fil0fil

| Tables_in_performance_schema
(%setup%) |

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

THREAD_ID: 1

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

·ORDINAL_POSITION:将接连属性添加到连年属性集的一一。

1 row in set (0.00 sec)

蹲点内部存款和储蓄器使用的表:

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

SUM _SELECT_FULL _RANGE_JOIN: 0

|
events_stages_summary_by_thread_by_event_name |

……

| events_waits_summary_by_user_by_event_name |

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

rwlock_instances表列出了server执行rwlock
instruments时performance_schema所见的享有rwlock(读写锁)实例。rwlock是在代码中央银行使的联合机制,用于强制在加以时间内线程能够遵照有些规则访问一些公共财富。能够认为rwlock保养着这几个能源不被别的线程随意抢占。访问格局能够是共享的(四个线程能够而且具有共享读锁)、排他的(同时只有四个线程在加以时间能够有所排他写锁)或共享独占的(某些线程持有排他锁定时,同时允许别的线程执行差别性读)。共享独占访问被称为sxlock,该访问形式在读写场景下能够进步并发性和可扩充性。

LOW _NUMBER_OF _BYTES_USED: 0

  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本子暗中认可安装

* _client_license:连接器许可证类型

prepared_statements_instances表有谈得来额外的总计列:

|
events_statements_summary_by_program |

·VICTIM,TIMEOUT和KILLED状态值停留时间很简短,当2个锁处于这么些场馆时,那么表示该锁行消息就要被删除(手动执行SQL恐怕因为日子原因查看不到,能够动用程序抓取);

performance_schema把内部存款和储蓄器事件总计表也根据与等待事件总结表类似的规则进行分拣总计。

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

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

DIGEST: 4fb483fe710f27d1d06f83573c5ce11c

#
该事件消息表示线程ID为4的线程正在守候innodb存款和储蓄引擎的log_sys_mutex锁,那是innodb存款和储蓄引擎的3个互斥锁,等待时间为65664微秒(*_ID列表示事件源于哪个线程、事件编号是有个别;EVENT_NAME表示检查和测试到的求实的剧情;SOUQashqaiCE表示那些检查和测试代码在哪些源文件中以及行号;计时器字段TIME昂Cora_START、TIMER_END、TIMER_WAIT分别代表该事件的上猪时间、停止时间、以及总的开支时间,借使该事件正在运营而尚未终结,那么TIME揽胜极光_END和TIMER_WAIT的值呈现为NULL。注:计时器计算的值是看似值,并不是一点一滴规范)

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

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

2.2. 启用performance_schema

·对此已接受的连年,performance_schema根据performance_schema_session_connect_attrs_size系统变量的值检查总结连接属性大小。倘使属性大小超越此值,则会执行以下操作:

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

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

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

MAX_TIMER_WAIT: 80968744000

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

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

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

|
events_transactions_summary_by_account_by_event_name |

这一个音讯使您能够领会会话之间的元数据锁信赖关系。不仅能够见见会话正在守候哪个锁,还足以阅览近期持有该锁的会话ID。

OBJECT_NAME: ps_setup_enable_consumer

|performance_schema | ON |

小编:

| events_stages_summary_by_account_by_event_name |

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

COUNT_STAR: 24

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

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

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

# events_waits_summary_global_by_event_name表

performance_schema完毕机制服从以下设计目的:

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

| events_waits_summary_by_thread_by_event_name |

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

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

1 row in set (0.00 sec)

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

1 row in set (0.00 sec)

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

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

该表允许使用TRUNCATE
TABLE语句。只将总括列重置为零,而不是剔除行。该表执行truncate时也会隐式触发table_io_waits_summary_by_table表的truncate操作。其余利用DDL语句更改索引结构时,会促成该表的具备索引总括新闻被重置

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

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

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

我们先来探视那几个表中记录的总结消息是怎么样体统的(由于单行记录较长,那里只列出memory_summary_by_account_by_event_name
表中的示例数据,其他表的演示数据省略掉一部分雷同字段)。

EVENT_NAME:
wait/synch/mutex/innodb/log_sys_mutex

performance_schema还总结后台线程和无法证实用户的连日,对于那些连接总结行消息,USE卡宴和HOST列值为NULL。

EVENT_NAME: transaction

20rows inset (0.00sec)

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

5rows inset ( 0. 00sec)

选取show命令来查询你的数据库实例是还是不是支持INFOXC60MATION_SCHEMA引擎

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

| Tables_in_performance_schema (%events_stages_summary%) |

监视文件系统层调用的表:

MAX _TIMER_WAIT: 56688392

5rows inset ( 0. 00sec)

| TABLE_NAME |

metadata_locks表不允许利用TRUNCATE TABLE语句。

USER: root

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

2. 总是属性总结表

* COUNT_ALLOC:增加1

INDEX_NAME: NULL

·ATTR_VALUE:连接属性值;

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

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

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

| events_statements_summary_by_host_by_event_name |

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

咱俩先来探望表中记录的总计音讯是何许体统的。

# events_statements_summary_by_user_by_event_name表

| NO |NO | NO |

# table_lock_waits_summary_by_table表

# events_stages_summary_by_account_by_event_name表

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

·FILE_NAME:磁盘文件名称;

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

2.1. 反省当前数据库版本是还是不是支持

数据库对象总计表

events_statements_summary_global_by_event_name:根据每一种事件名称实行总计的Statement事件

| events_transactions_history |

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

内部存款和储蓄器大小计算新闻有助于驾驭当下server的内部存款和储蓄器消耗,以便及时开始展览内部存款和储蓄器调整。内部存款和储蓄器相关操作计数有助于精晓当下server的内部存款和储蓄器分配器的全体压力,及时间控制制server品质数据。例如:分配单个字节一百万次与单次分配一百万个字节的属性开支是见仁见智的,通过跟踪内部存款和储蓄器分配器分配的内部存款和储蓄器大小和分配次数就足以掌握互相的差别。

  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帮忙的享有平弗罗茨瓦夫事件监察和控制作用都可用,但分歧平塞内加尔达喀尔用于计算事件时间支出的计时器类型可能会有着差距。

OBJECT_SCHEMA: xiaoboluo

MIN _TIMER_WAIT: 0

……

由此对以下多个表执行查询,能够实现对应用程序的督察或DBA能够检查和测试到事关锁的线程之间的一对瓶颈或死锁新闻:

MAX _TIMER_WAIT: 0

产品:沃趣科学和技术

各样连接新闻表都有CU福特ExplorerRENT_CONNECTIONS和TOTAL_CONNECTIONS列,用于跟踪连接的此时此刻连接数和总连接数。对于accounts表,各样连接在表中每行新闻的唯一标识为USE兰德酷路泽+HOST,不过对于users表,只有3个user字段举办标识,而hosts表唯有二个host字段用于标识。

| memory_summary_by_user_by_event_name |

|
events_waits_summary_by_thread_by_event_name |

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

HIGH_COUNT_USED: 1

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

# file_summary_by_event_name表

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

1row inset (0.00sec)

……

1 row in set (0.01 sec)

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

·依靠于连接表中国国投息的summary表在对那个连接表执行truncate时会同时被隐式地履行truncate,performance_schema维护着依照accounts,hosts或users总结各类风云总结表。那一个表在称呼包罗:_summary_by_account,_summary_by_host,*_summary_by_user

# events_stages_summary_by_host_by_event_name表

TIMER_END: 1582395491787190144

·OBJECT_NAME:instruments对象的称号,表级别对象;

SCHEMA_NAME: NULL

| Tables_in_performance_schema
(%statement%) |

STATEMENT_NAME: stmt

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

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

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

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

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

admin@localhost : performance _schema 01:56:16> select * from
table_io _waits_summary _by_table where SUM _TIMER_WAIT!=0G;

MAX _TIMER_WAIT: 0

后天,你能够在performance_schema下接纳show
tables语句或许通过查询
INFOSportageMATION_SCHEMA.TABLES表中performance_schema引擎相关的元数据来领会在performance_schema下存在着什么表:

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

从上边表中的演示记录音讯中,大家得以看出,同样与等待事件类似,遵照用户、主机、用户+主机、线程等纬度实行分组与计算的列,这么些列的含义与等待事件类似,那里不再赘言,但对于工作总计事件,针对读写事务和只读事务还独立做了总括(xx_READ_WRITE和xx_READ_ONLY列,只读事务必要安装只读事务变量transaction_read_only=on才会举行总括)。

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

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

| memory_summary_by_host_by_event_name |

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

Performance Schema通过metadata_locks表记录元数据锁音信:

SUM _TIMER_READ_WRITE: 8592136000

|
events_waits_summary_by_account_by_event_name |

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

events_statements_summary_by_host_by_event_name:依照每一种主机名和事件名称进行总结的Statement事件

END_EVENT_ID: 60

·各种文件I/O事件计算表有如下总计字段:

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

11rows inset (0.00sec)

socket_instances表列出了连接到MySQL
server的龙腾虎跃接连的实时快速照相新闻。对于每种连接到mysql
server中的TCP/IP或Unix套接字文件延续都会在此表中著录一行音讯。(套接字总计表socket_summary_by_event_name和socket_summary_by_instance中提供了一部分叠加新闻,例如像socket操作以及互联网传输和接到的字节数)。

MIN _TIMER_READ_ONLY: 57571000

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

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

* SUM_NUMBER_OF_BYTES_FREE:增加N

……

| Tables_in_performance_schema (%socket%summary%) |

performance_schema把等待事件总括表依据区别的分组列(不一样纬度)对等候事件相关的多寡开始展览联谊(聚合总结数据列包含:事件发生次数,总等待时间,最小、最大、平均等待时间),注意:等待事件的搜集作用有部分暗中认可是禁止使用的,须要的时候能够由此setup_instruments和setup_objects表动态开启,等待事件总计表包括如下几张表:

|
events_waits_summary_global_by_event_name |

两张表中著录的始末很相近:

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

|
events_statements_summary_by_user_by_event_name |

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

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

|1、**什么是performance_schema**

hosts表字段含义如下:

# events_waits_summary_by_account_by_event_name表

ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

| NULL |41| 45 |

1 row in set (0.00 sec)

| events_stages_history_long |

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;

*
事务所占用的能源要求多少也只怕会因工作隔绝级别有所差异(例如:锁能源)。不过:每一种server恐怕是应用同一的割裂级别,所以不单独提供隔开分离级别相关的总括列

9rows inset (0.00sec)

当客户端与server端建立连接时,performance_schema使用符合各样表的唯一标识值来显然每一个连接表中怎样进展记录。即便不够对应标识值的行,则新添加一行。然后,performance_schema会追加该行中的CU福睿斯RENT_CONNECTIONS和TOTAL_CONNECTIONS列值。

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

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

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

LOW_COUNT_USED: 0

| events_statements_summary_by_digest
|

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

events_statements_summary_by_digest:依据各种库级别对象和语句事件的原始语句文本计算值(md5
hash字符串)进行计算,该总计值是依照事件的原始语句文本进行简短(原始语句转换为尺度语句),每行数据中的相关数值字段是持有相同总计值的总计结果。

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

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

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

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

SUM _NUMBER_OF _BYTES_READ: 0

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

NESTING_EVENT_ID: NULL

·OWNER_THREAD_ID,OWNER_EVENT_ID:这一个列表示制造prepare语句的线程ID和事件ID。

| 内部存款和储蓄器事件总计表

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

·COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT:这几个列计算全数socket读写操作的次数和时间音信

内存事件总括表有如下几张表:

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

* _program_name:客户端程序名称

1 row in set (0.00 sec)

IT从业多年,历任运维工程师、高级运营工程师、运转老板、数据库工程师,曾插手版本揭橥种类、轻量级监察和控制体系、运营管理平台、数据库管理平台的宏图与编写制定,熟识MySQL种类布局,Innodb存款和储蓄引擎,喜好专研开源技术,追求八面玲珑。

EVENT_NAME: wait/io/socket/sql/client_connection

5rows inset ( 0. 00sec)

Database changed

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

……

|
memory_summary_global_by_event_name |

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

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

| Tables_in_performance_schema
(%transaction%) |

1 row in set (0.00 sec)

当某给定对象在server中第二遍被利用时(即采纳call语句调用了储存进度或自定义存款和储蓄函数时),将在events_statements_summary_by_program表中添加一行总计消息;

图片 1

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

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

| variables_by_thread |

·execute步骤:语法EXECUTE stmt_name[USING @var_name [,
@var_name] …],示例:execute stmt;
再次回到执行结果为1,此时在prepared_statements_instances表中的总计新闻会进行翻新;

*
将COUNT_ALLOC和COUNT_FREE列重置,一碗水端平复最先计数(等于内部存款和储蓄器总计音讯以重置后的数值作为基准数据)

| events_stages_current |

连日来计算消息表允许利用TRUNCATE
TABLE。它会同时删除总计表中从未连接的帐户,主机或用户对应的行,重置有连接的帐户,主机或用户对应的行的并将其余行的CURAV4RENT_CONNECTIONS和TOTAL_CONNECTIONS列值。

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

FLAGS: NULL

metadata_locks表字段含义如下:

EVENT_NAME: memory/innodb/fil0fil

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

·PHP定义的属性注重于编写翻译的属性:

performance_schema把阶段事件计算表也如约与等待事件总结表类似的规则进行分类聚合,阶段事件也有一些是暗中认可禁止使用的,一部分是敞开的,阶段事件计算表包涵如下几张表:

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

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

events_statements_summary_by_program:根据每种存款和储蓄程序(存款和储蓄进程和函数,触发器和事件)的轩然大波名称进行计算的Statement事件

| file_instances |

1row inset ( 0. 00sec)

COUNT_STAR: 1

1 row in set (0.02 sec)

……

# memory_summary_by_host_by_event_name表

ORDER BY COUNT_STAR DESC LIMIT 10;

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

admin@localhost : performance_schema 06:27:58> show tables like
‘%events_statements_summary%’;

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

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

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

QueryOK, 3 rowsaffected(0.04sec)

COUNT_STAR: 802

SUM_SELECT_SCAN: 45

OBJECT_NAME: NULL

·TIMER_PREPARE:执行prepare语句小编消耗的时光。

# events_transactions_summary_by_account_by_event_name表

|
events_waits_summary_by_user_by_event_name |

·OBJECT_INSTANCE_BEGIN:instruments对象的内存地址;

MAX _TIMER_WAIT: 0

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

MAX_TIMER_READ: 9498247500

USER: root

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

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

events_statements_summary_by_account_by_event_name:依据种种帐户和讲话事件名称举行总计

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

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

COUNT_STAR: 7

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

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

HOST: localhost

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

6 rows inset (0.00 sec)

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

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

table_handles表字段含义如下:

AVG _TIMER_WAIT: 0

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

SUM_WARNINGS: 0

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

2.1反省当前数据库版本是不是支持

…………

MIN _TIMER_WAIT: 0

THREAD_ID: 4

*
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操作没有字节计数新闻。

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

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

file_instances表不允许使用TRUNCATE TABLE语句。

| events_stages_summary_by_thread_by_event_name |

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

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

EVENT_NAME: stage/sql/After create

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

table_lock_waits_summary_by_table表:

COUNT_STAR: 0

接下来,不难介绍了怎么样高效上手使用performance_schema的方法;

1.数码库表级别对象等待事件总括

# events_statements_summary_by_digest表

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

MAX _TIMER_READ: 56688392

HIGH _NUMBER_OF _BYTES_USED: 32

主要编辑:

通过对以下多少个表执行查询,能够兑现对应用程序的监察或DBA能够检查和测试到关系互斥体的线程之间的瓶颈或死锁新闻(events_waits_current可以查阅到当前正在等待互斥体的线程音信,mutex_instances能够查看到当前有个别互斥体被哪些线程持有)。

HOST: localhost

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

EVENT_NAME: wait/io/socket/sql/client_connection

OBJECT_TYPE: PROCEDURE

SOURCE: log0log.cc:1572

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

| events_statements_summary_global_by_event_name |

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

·HOST:某老是的客户端主机名。假诺是四当中间线程创立的连年,或许是力不从心证实的用户创造的总是,则该字段为NULL;

MIN _TIMER_WAIT: 0

|
events_transactions_summary_by_thread_by_event_name |

*
COUNT_READ,SUM_TIMER_READ,MIN_TIMER_READ,AVG_TIMER_READ,MAX_TIMER_READ,SUM_NUMBER_OF_BYTES_READ:那一个列总括了具备文件读取操作,包含FGETS,FGETC,FREAD和READ系统调用,还隐含了那一个I/O操作的数据字节数

……

2.3. performance_schema表的分类

1. 连连音讯总结表

HOST: NULL

| setup_objects |

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

| 事务事件总结表

| users |

AVG_TIMER_WAIT: 24366870

SUM_SELECT_RANGE: 0

OBJECT_TYPE: NULL

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

| Tables_in_performance_schema (%events_statements_summary%) |

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

总是属性记录在如下两张表中:

MIN _TIMER_WAIT: 0

|
memory_summary_by_host_by_event_name |

小编们先来探视表中著录的总括音讯是怎么样体统的。

*
固然多少个线程没有开启采集作用,可是内部存款和储蓄器相关的instruments启用了,则该内部存款和储蓄器释放的操作会被监督到,总结数据会发生变动,那也是眼下提到的怎么反复在运维时修改memory
instruments可能导致总括数据为负数的原因

从上文中我们曾经知晓,performance_schema在5.7.x会同以上版本中默许启用(5.6.x及其以下版本暗中同意关闭),假诺要显式启用或关闭时,我们供给采用参数performance_schema=ON|OFF设置,并在my.cnf中实行配置:

·当从前请求不能够即时赢得的锁在那之后被予以时,其锁新闻行状态更新为GRANTED;

*
COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE:执行prepare语句对象的总结音信

2.2. 启用performance_schema

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

COUNT_STAR: 0

正文首先,差不多介绍了什么是performance_schema?它能做怎么着?

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

EVENT_NAME: transaction

mysqld运维之后,通过如下语句查看performance_schema是不是启用生效(值为ON代表performance_schema已伊始化成功且能够行使了。固然值为OFF表示在启用performance_schema时发生一些错误。能够查阅错误日志进行排查):

STATEMENT_ID: 1

……

5rows inset (0.00sec)

AVG_TIMER_WAIT: 514656000

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

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

* _client_version:客户端libmysql库版本

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

|PERFORMANCE_SCHEMA | YES
|Performance Schema

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

| events_statements_summary_by_digest |

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

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

# events_stages_summary_global_by_event_name表

_current表中各种线程只保留一条记下,且只要线程实现工作,该表中不会再记录该线程的风浪音信,_history表中记录种种线程已经履行到位的事件消息,但每一个线程的只事件新闻只记录10条,再多就会被遮住掉,*_history_long表中记录全数线程的事件消息,但总记录数据是10000行,超越会被遮盖掉,今后大家查看一下历史表events_waits_history
中记录了怎样:

OBJECT_TYPE: TABLE

MAX _TIMER_WAIT: 0

EVENT_ID: 60

AVG_TIMER_EXECUTE: 0

events_statements_summary_by_user_by_event_name:遵照种种用户名和事件名称举行总计的Statement事件

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

我们先来探视表中著录的总计音讯是何等样子的。

*
若是该线程在threads表中从不拉开采集作用也许说在setup_instruments中对应的instruments没有拉开,则该线程分配的内部存款和储蓄器块不会被监察和控制

| events_waits_history |

图片 2

SUM _SELECT_RANGE_CHECK: 0

|Transactions | XA |Savepoints
|

| Tables_in_performance_schema (%file_summary%) |

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

| events_transactions_history_long
|

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

EVENT_NAME: stage/sql/After create

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

SOURCE: sql_parse.cc:6031

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

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

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

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

|目
1、什么是performance_schema

cond_instances表列出了server执行condition instruments
时performance_schema所见的富有condition,condition表示在代码中一定事件发生时的一路信号机制,使得等待该标准的线程在该condition知足条件时方可恢复工作。

SUM _SELECT_FULL_JOIN: 21

SPINS: NULL

·OBJECT_TYPE:元数据锁子系统中运用的锁类型(类似setup_objects表中的OBJECT_TYPE列值):有效值为:GLOBAL、SCHEMA、TABLE、FUNCTION、PROCEDURE、T宝马X5IGGECR-V(当前未选取)、EVENT、COMMIT、USELX570LEVEL LOCK、TABLESPACE、LOCKING SE昂科拉VICE,USE本田UR-V LEVEL
LOCK值表示该锁是选用GET_LOCK()函数获取的锁。LOCKING
SE奇骏VICE值表示使用锁服务赢得的锁;

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

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

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

| 阶段事件总计表

QueryOK, 0 rowsaffected(0.00sec)

COUNT_READ: 0

# events_stages_summary_by_user_by_event_name表

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

SUM_ERRORS: 0

SUM_WARNINGS: 0

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

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

SUM_ROWS_AFFECTED: 0

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

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

OBJECT_SCHEMA: sys

|
memory_summary_by_thread_by_event_name |

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

*
LOW_COUNT_USED:如果CURRENT_COUNT_USED收缩1今后是叁个新的最低值,则该字段相应回落

8rows inset (0.00sec)

| 4 |program_name | mysql |5|

| events_waits_summary_by_account_by_event_name |

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

MAX_TIMER_WAIT: 18446696808701862260

# events_waits_summary_by_thread_by_event_name表

| cond_instances |

SUM _TIMER_READ _WITH_SHARED_LOCKS: 0

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

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

·OBJECT_INSTANCE_BEGIN:prepare语句事件的instruments
实例内部存款和储蓄器地址。

EVENT_NAME: statement/sql/select

|
events_waits_summary_by_host_by_event_name |

…………

# memory_summary_by_thread_by_event_name表

| FILE_NAME |EVENT_NAME | OPEN_COUNT |

·倘使值为NULL,则意味表I/O没有采用到目录

COUNT_STAR: 7

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

·PRE_ACQUIRE_NOTIFY和POST_RELEASE_NOTIFY状态值停留事件都很简单,当一个锁处于那几个情景时,那么表示元数据锁子系统正在公告有关的蕴藏引擎该锁正在举行分配或释。这个景况值在5.7.11本子中新增。

IT从业多年,历任运维工程师、高级运转工程师、运营首席营业官、数据库工程师,曾参预版本宣布系统、轻量级监察和控制体系、运转管理平台、数据库管理平台的统筹与编辑,熟习MySQL类别布局,Innodb存款和储蓄引擎,喜好专研开源技术,追求完善。

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;

MAX_TIMER_EXECUTE: 0

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

| THREAD_ID |EVENT_ID | EVENT_NAME |TIMER_WAIT |

mutex_instances表字段含义如下:

注意:那个表只针对工作事件消息举办总结,即蕴含且仅包蕴setup_instruments表中的transaction采集器,每种业务事件在各类表中的总结记录行数须求看怎么样分组(例如:根据用户分组总括的表中,有微微个活泼用户,表中就会有些许条相同采集器的记录),其余,总结计数器是或不是见效还须求看transaction采集器是还是不是启用。

| setup_timers |

当客户端断开连接时,performance_schema将审核消减对应连接的行中的CU宝马X5RENT_CONNECTIONS列,保留TOTAL_CONNECTIONS列值。

MIN _TIMER_WAIT: 0

本文小结

OBJECT_TYPE: TABLE

COUNT_ALLOC: 193

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

| table_lock_waits_summary_by_table |#
依据各个表展开总结的表锁等待事件

1 row in set (0.00 sec)

本篇内容到此地就接近尾声了,相信广大人都觉着,大家半数以上时候并不会直接选取performance_schema来查询质量数据,而是利用sys
schema下的视图代替,为何不直接攻读sys schema呢?那您精晓sys
schema中的数据是从哪个地方吐出来的啊?performance_schema
中的数据实际上根本是从performance_schema、information_schema中取得,所以要想玩转sys
schema,全面摸底performance_schema必不可少。别的,对于sys
schema、informatiion_schema甚至是mysql
schema,大家后续也会生产不一样的千家万户小说分享给大家。

大家先来探望表中记录的总结消息是何等体统的。

*
CURRENT_NUMBER_OF_BYTES_USED:增加N

|
memory_summary_by_account_by_event_name |

……

由于performance_schema表内存限制,所以拥戴了DIGEST
= NULL的特别行。
当events_statements_summary_by_digest表限制容积已满的图景下,且新的口舌计算音信在要求插入到该表时又从不在该表中找到匹配的DIGEST列值时,就会把这几个语句计算音信都总括到
DIGEST =
NULL的行中。此行可帮衬您猜想events_statements_summary_by_digest表的范围是还是不是必要调整

|
events_transactions_summary_by_user_by_event_name |

·HOST:有些连接的主机名,假诺是1个之中线程创设的连日,也许是心有余而力不足申明的用户创制的总是,则该字段为NULL;

* 注意:若是在server运转之后再修改memory
instruments,恐怕会招致由于丢失从前的分红操作数据而致使在出狱之后内部存款和储蓄器计算音信出现负值,所以不建议在运维时往往开关memory
instruments,假如有内部存储器事件总括须要,提议在server运行在此之前就在my.cnf中布局好内需总括的风云采访

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

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

performance_schema把语句事件计算表也遵照与等待事件总计表类似的规则举办归类总括,语句事件instruments暗中认可全部开启,所以,语句事件总括表中私下认可会记录全体的话语事件总结音信,言语事件总计表包涵如下几张表:

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

| NULL |41| 45 |

AVG _TIMER_WAIT: 1235672000

|
events_transactions_summary_global_by_event_name |

accounts表字段含义如下:

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

数据库刚刚起先化并运维时,并非全数instruments(事件采访项,在征集项的配备表中每一项都有一个开关字段,或为YES,或为NO)和consumers(与征集项类似,也有二个应和的风云类型保存表配置项,为YES就代表对应的表保存品质数据,为NO就意味着对应的表不保留品质数据)都启用了,所以暗中同意不会收集全体的轩然大波,也许您须求检查和测试的事件并没有打开,要求开始展览设置,能够选用如下八个语句打开对应的instruments和consumers(行计数恐怕会因MySQL版本而异),例如,大家以布署监测等待事件数量为例进行求证:

……

AVG _TIMER_WAIT: 0

| events_waits_current |

| NAME |OBJECT_INSTANCE_BEGIN | WRITE_LOCKED_BY_THREAD_ID
|READ_LOCKED_BY_COUNT |

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

|
events_statements_summary_by_account_by_event_name |

……

| Tables_in_performance_schema (%memory%summary%) |

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

元数据锁instruments使用wait/lock/metadata/sql/mdl,暗中认可未张开。

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

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

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

| 等待事件总括表

| setup_instruments |

大家先来探望表中记录的总计音讯是何许体统的。

THREAD_ID: 47

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

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

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

87rows inset (0.00sec)

LOCK_STATUS: GRANTED

AVG _TIMER_WAIT: 0

21 rows inset (0.00 sec)

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

出品:沃趣科学技术

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

应用程序能够应用部分键/值对转移一些几次三番属性,在对mysql
server成立连接时传递给server。对于C
API,使用mysql_options()和mysql_options4()函数定义属性集。别的MySQL连接器能够使用部分自定义连接属性方法。

# events_waits_summary_by_host_by_event_name表

#
这个结果申明,THSportage_LOCK_malloc互斥事件是最热的。注:TH瑞鹰_LOCK_malloc互斥事件仅在DEBUG版本中存在,GA版本不设有

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

SUM _TIMER_WAIT: 0

使用
INFORMATION_SCHEMA.ENGINES表来查询你的数据库实例是不是辅助INFO君越MATION_SCHEMA引擎

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

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

OBJECT_INSTANCE_BEGIN: 955681576

MIN _TIMER_READ _WITH_SHARED_LOCKS: 0

* SUM_NUMBER_OF_BYTES_ALLOC:增加N

| users |

OBJECT_NAME: test

events_statements_summary_by_thread_by_event_name:依照各个线程和事件名称举行总计的Statement事件

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

session_account_connect_attrs表字段含义:

THREAD_ID: 46

2.3.
performance_schema表的分类

(1)cond_instances表

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

2、performance_schema使用便捷入门

FILE_NAME: /data/mysqldata1/innodb_ts/ibdata1

COUNT_ALLOC: 158

|
events_statements_summary_global_by_event_name |

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

*
LOW_NUMBER_OF_BYTES_USED:如果CURRENT_NUMBER_OF_BYTES_USED减弱N之后是1个新的最低值,则该字段相应收缩

……

file_instances表字段含义如下:

AVG _TIMER_WAIT: 0

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

大家先来探望表中记录的计算音讯是何等体统的。

SUM _TIMER_WAIT: 0

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

1row inset ( 0. 00sec)

1 row in set (0.00 sec)

| Tables_in_performance_schema
(%wait%) |

AVG_TIMER_READ: 530278875

# events_statements_summary_by_thread_by_event_name表

performance_schema被视为存款和储蓄引擎。假诺该内燃机可用,则应该在INFOQX56MATION_SCHEMA.ENGINES表或SHOW
ENGINES语句的出口中都能够看来它的SUPPO大切诺基T值为YES,如下:

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

SUM _TIMER_WAIT: 0

| events_transactions_current |

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

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

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

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

EVENT_NAME: memory/performance_schema/mutex_instances

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

MIN_TIMER_READ: 15213375

HOST: localhost

Rowsmatched: 323 Changed: 0 Warnings: 0

IP:PO福睿斯T列组合值可用于标识3个两次三番。该组合值在events_waits_xxx表的“OBJECT_NAME”列中使用,以标识那些事件消息是缘于哪个套接字连接的:

SUM _NUMBER_OF _BYTES_ALLOC: 3296

| events_waits_summary_by_instance
|

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

属性事件总括表中的某部instruments是还是不是执行总计,注重于在setup_instruments表中的配置项是不是打开;

[mysqld]

COUNT_STAR: 1

COUNT_FREE: 103

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

MIN_TIMER_READ_NORMAL: 0

MIN _TIMER_WAIT: 0

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

SUM_ROWS_AFFECTED: 0

| memory_summary_by_thread_by_event_name |

|导
很久在此以前,当自个儿还在品尝着系统地球科学习performance_schema的时候,通过在网上各样搜索资料进行学习,但很遗憾,学习的功能并不是很鲜明,很多标称类似
“深刻浅出performance_schema”
的篇章,基本上都是那种动不动就贴源码的作风,然后深刻了后头却出不来了。对系统学习performance_schema的效应甚微。

table_io_waits_summary_by_table表:

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

| 0 |

友情提醒:下文中的计算表中山大学部字段含义与上一篇
《事件总结 | performance_schema全方位介绍》
中关系的总结表字段含义相同,下文中不再赘述。别的,由于局地总括表中的记录内容过长,限于篇幅会简单部分文件,如有须要请自行安装MySQL
5.7.11以上版本跟随本文举办同步操作查看。

AVG _TIMER_WAIT: 0

TIMER_WAIT: 65664

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

  • SUM_NUMBER_OF_BYTES_FREE

发表评论

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