数据库对象事件与属性统计 | performance,沃趣科技

6047acom

图片 3

数据库对象事件与属性统计 | performance,沃趣科技

| 0 comments

在上一篇《事件记录 |
performance_schema全方位介绍”》中,大家详细介绍了performance_schema的事件记录表,恭喜大家在就学performance_schema的中途度过了五个最艰巨的时期。以往,相信大家已经相比清楚什么是事件了,但神跡我们无需精通每时每刻发生的每一条事件记录音信,
举个例子:大家期望了然数据库运维以来一段时间的风浪总计数据,那一年就必要查阅事件计算表了。今日将引导我们一齐踏上三番五次串第四篇的道路(全系共7个篇章),在这一期里,我们将为大家关怀备至授课performance_schema中事件计算表。总计事件表分为5个类型,分别为等候事件、阶段事件、语句事件、事务事件、内部存款和储蓄器事件。上边,请随行我们共同起来performance_schema系统的学习之旅吧。

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;

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

percona
server原本提供了一工具pt-ioprofile,但是那工具是使用strace完结的,有一点都不小可能率在系统繁忙时产生进程被kill恐怕hang。。。所以依旧通过performance_schema入手。

SORT_SCAN:像Sort_scan状态变量同样的计数值,不过此地只用于这么些事件中的语句总括而不对准全局、会话品级

从地点表中的演示记录新闻中,我们得以看出,同样与等待事件类似,遵照用户、主机、用户+主机、线程等纬度举办分组与总计的列,那些列的含义与等待事件类似,这里不再赘述,但对于职业计算事件,针对读写事务和只读事务还独立做了总结(xx_READ_WRITE和xx_READ_ONLY列,只读事务供给安装只读事务变量transaction_read_only=on才会开始展览计算)。

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

| Tables_in_performance_schema
(%stage%) |

**在上边的查询中,大家得以看到,data/ioana/t1.ibd文本的写入是最多的。在大家的类别中,超越54%场所下真的是写入的IO是瓶颈的意况非常多,重假若计量危机值实时写入所致。**

events_stages_current 表

我们先来拜访这个表中著录的总计消息是什么样体统的(由于单行记录较长,这里只列出memory_summary_by_account_by_event_name
表中的示例数据,其他表的言传身教数据省略掉一部分同样字段)。

SUM_WARNINGS: 0

| setup_timers |

那二日开掘集团有些台Ali云ECS上的mysql生产服务器繁忙时期io等待高达百分之二三十(测度十分七是从未write
back),并且规定是mysql进度发生,由于跑的行使过多,开拓和保卫安全没办法直接规定怎么样表繁忙,哪些表不繁忙。。。

NESTING_EVENT_TYPE:嵌套事件类型。有效值为:TRANSACTION,STATEMENT,STAGE,WAIT。阶段事件的嵌套事件不以为奇是statement

MIN _TIMER_WAIT: 0

1row inset ( 0. 00sec)

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

**找到具体的文本后,就足以依靠事业形式和架构进行针对性的优化。**

events_statements_history_long表富含目前的N个语句事件。在server运行时,N的值会自动调节。
要显式设置N的大大小小,能够在server运转在此之前安装系统变量performance_schema_events_statements_history_long_size的值。
statement事件供给实践达成时才会增多到该表中。
当增多新事件到该表时,假诺该表的大局分配的定额已满,则会抛弃该表中较旧的事件

SUM_SELECT_SCAN: 45

该表包蕴关于内部和表面锁的音信:

NESTING_EVENT_TYPE: NULL

为了找到来源,大家必要精晓怎么文件、表的io读写量最高,然后开始展览针对性的优化。

PS:允许利用TRUNCATE TABLE语句

* CURRENT_NUMBER_OF_BYTES_USED:减少N

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

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

mysql> select * from file_summary_by_instance order by
SUM_TIMER_WAIT desc limit 5\G;
*************************** 1. row
***************************
                FILE_NAME:
/usr/local/mysql-5.6.19-linux-glibc2.5-x86_64/data/ioana/t1.ibd
               EVENT_NAME: wait/io/file/innodb/innodb_data_file
    OBJECT_INSTANCE_BEGIN: 139999261742528
               COUNT_STAR: 11739
           SUM_TIMER_WAIT: 1617275634994
           MIN_TIMER_WAIT: 5797000
           AVG_TIMER_WAIT: 137769394
           MAX_TIMER_WAIT: 100739635708
               COUNT_READ: 1
           SUM_TIMER_READ: 34699788
           MIN_TIMER_READ: 34699788
           AVG_TIMER_READ: 34699788
           MAX_TIMER_READ: 34699788
 SUM_NUMBER_OF_BYTES_READ: 16384
              COUNT_WRITE: 11472
          SUM_TIMER_WRITE: 1184834714832
          MIN_TIMER_WRITE: 5797000
          AVG_TIMER_WRITE: 103280406
          MAX_TIMER_WRITE: 7278810168
SUM_NUMBER_OF_BYTES_WRITE: 377339904
               COUNT_MISC: 266
           SUM_TIMER_MISC: 432406220374
           MIN_TIMER_MISC: 8252820
           AVG_TIMER_MISC: 1625586835
           MAX_TIMER_MISC: 100739635708
*************************** 2. row
***************************
                FILE_NAME:
/usr/local/mysql-5.6.19-linux-glibc2.5-x86_64/data/ibdata1
               EVENT_NAME: wait/io/file/innodb/innodb_data_file
    OBJECT_INSTANCE_BEGIN: 139999261496128
               COUNT_STAR: 1709
           SUM_TIMER_WAIT: 814764332152
           MIN_TIMER_WAIT: 3623652
           AVG_TIMER_WAIT: 476748969
           MAX_TIMER_WAIT: 33581165152
               COUNT_READ: 166
           SUM_TIMER_READ: 22098794292
           MIN_TIMER_READ: 3623652
           AVG_TIMER_READ: 133124943
           MAX_TIMER_READ: 10389786028
 SUM_NUMBER_OF_BYTES_READ: 4784128
              COUNT_WRITE: 1215
          SUM_TIMER_WRITE: 488756864260
          MIN_TIMER_WRITE: 5788568
          AVG_TIMER_WRITE: 402268586
          MAX_TIMER_WRITE: 6710965560
SUM_NUMBER_OF_BYTES_WRITE: 364969984
               COUNT_MISC: 328
           SUM_TIMER_MISC: 303908673600
           MIN_TIMER_MISC: 7460212
           AVG_TIMER_MISC: 926550320
           MAX_TIMER_MISC: 33581165152
*************************** 3. row
***************************
                FILE_NAME:
/usr/local/mysql-5.6.19-linux-glibc2.5-x86_64/data/ioana/t2.ibd
               EVENT_NAME: wait/io/file/innodb/innodb_data_file
    OBJECT_INSTANCE_BEGIN: 139999261741120
               COUNT_STAR: 12011
           SUM_TIMER_WAIT: 678760914098
           MIN_TIMER_WAIT: 5073956
           AVG_TIMER_WAIT: 56511264
           MAX_TIMER_WAIT: 7126760128
               COUNT_READ: 6309
           SUM_TIMER_READ: 65882736360
           MIN_TIMER_READ: 5073956
           AVG_TIMER_READ: 10442505
           MAX_TIMER_READ: 68216988
 SUM_NUMBER_OF_BYTES_READ: 103366656
              COUNT_WRITE: 5510
          SUM_TIMER_WRITE: 434740598494
          MIN_TIMER_WRITE: 5778028
          AVG_TIMER_WRITE: 78899805
          MAX_TIMER_WRITE: 7126760128
SUM_NUMBER_OF_BYTES_WRITE: 184696832
               COUNT_MISC: 192
           SUM_TIMER_MISC: 178137579244
           MIN_TIMER_MISC: 8811440
           AVG_TIMER_MISC: 927799837
           MAX_TIMER_MISC: 2063390504
*************************** 4. row
***************************
                FILE_NAME:
/usr/local/mysql-5.6.19-linux-glibc2.5-x86_64/data/ib_logfile0
               EVENT_NAME: wait/io/file/innodb/innodb_log_file
    OBJECT_INSTANCE_BEGIN: 139999261496832
               COUNT_STAR: 258
           SUM_TIMER_WAIT: 213773061014
           MIN_TIMER_WAIT: 594456
           AVG_TIMER_WAIT: 828577331
           MAX_TIMER_WAIT: 14386901848
               COUNT_READ: 6
           SUM_TIMER_READ: 54982964
           MIN_TIMER_READ: 594456
           AVG_TIMER_READ: 9163476
           MAX_TIMER_READ: 46464536
 SUM_NUMBER_OF_BYTES_READ: 69632
              COUNT_WRITE: 141
          SUM_TIMER_WRITE: 64075588012
          MIN_TIMER_WRITE: 10415628
          AVG_TIMER_WRITE: 454436316
          MAX_TIMER_WRITE: 2400912924
SUM_NUMBER_OF_BYTES_WRITE: 149283328
               COUNT_MISC: 111
           SUM_TIMER_MISC: 149642490038
           MIN_TIMER_MISC: 1692724
           AVG_TIMER_MISC: 1348130294
           MAX_TIMER_MISC: 14386901848
*************************** 5. row
***************************
                FILE_NAME:
/usr/local/mysql-5.6.19-linux-glibc2.5-x86_64/data/ib_logfile1
               EVENT_NAME: wait/io/file/innodb/innodb_log_file
    OBJECT_INSTANCE_BEGIN: 139999261497536
               COUNT_STAR: 71
           SUM_TIMER_WAIT: 128004164104
           MIN_TIMER_WAIT: 1294312
           AVG_TIMER_WAIT: 1802875432
           MAX_TIMER_WAIT: 11708167172
               COUNT_READ: 0
           SUM_TIMER_READ: 0
           MIN_TIMER_READ: 0
           AVG_TIMER_READ: 0
           MAX_TIMER_READ: 0
 SUM_NUMBER_OF_BYTES_READ: 0
              COUNT_WRITE: 48
          SUM_TIMER_WRITE: 60748006720
          MIN_TIMER_WRITE: 9237256
          AVG_TIMER_WRITE: 1265583122
          MAX_TIMER_WRITE: 2272031912
SUM_NUMBER_OF_BYTES_WRITE: 135080448
               COUNT_MISC: 23
           SUM_TIMER_MISC: 67256157384
           MIN_TIMER_MISC: 1294312
           AVG_TIMER_MISC: 2924180710
           MAX_TIMER_MISC: 11708167172
5 rows in set (0.00 sec)

SPINS: NULL

| memory_summary_global_by_event_name |

* _client_version:客户端libmysql库版本

| NO |NO | NO |

file_summary_by_instance表中记录了针对各样文件的Io读写意况,如下所示:**

SELECT_SCAN:像Select_scan状态变量同样的计数值,可是此地只用于那几个事件中的语句总括而不对准全局、会话等第

events_waits_summary_by_instance表:按照列EVENT_NAME、OBJECT_INSTANCE_BEGIN举行分组事件消息。如果一个instruments(event_name)创设有几个实例,则每一种实例都有所独一的OBJECT_INSTANCE_BEGIN值,由此各样实例会议及展览开独立分组

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

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

LOCK_TIME:等待表锁的年华。该值以阿秒进行测算,但最后转变为皮秒显示,以便更易于与任何performance_schema中的计时器进行比较

USER: root

OBJECT_TYPE: TABLE

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

ROWS_AFFECTED:受该语句影响的行数。有关“受影响”的含义的描述,参见连接:

| Tables_in_performance_schema (%events_stages_summary%) |

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

  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帮忙的有着平新竹事件监控功能都可用,但差异平桃园用来计算事件时间支付的放大计时器类型也许会具备出入。

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

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

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

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

END_EVENT_ID:当贰个事变正在施行时该列值为NULL,当贰个平地风波实践完成时把该事件的ID更新到该列

# events_statements_summary_global_by_event_name表

OBJECT_SCHEMA: xiaoboluo

| Tables_in_performance_schema
(%memory%) |

WA奥德赛NINGS:语句警告数,此值来自代码区域的言辞会诊区域

| Tables_in_performance_schema (%memory%summary%) |

…………

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

*
4)、OBJECT_INSTANCE_BEGIN列是内部存款和储蓄器中的地方,解释同上

COUNT_STAR: 11

# file_summary_by_instance表

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

OBJECT_INSTANCE_BEGIN:未利用,字段值总是为NULL

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

OBJECT_SCHEMA: xiaoboluo

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

ISOLATION_LEVEL: READ COMMITTED

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

OBJECT _INSTANCE_BEGIN: 140568048055488

| Tables_in_performance_schema
(%wait%) |

OPERATION: timed_wait

1 row in set (0.00 sec)

笔者们先来看看表中著录的计算消息是什么体统的。

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

NUMBER _OF_RELEASE_SAVEPOINT: 0

| Tables_in_performance_schema (%prepare%) |

1row inset ( 0. 00sec)

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

events_waits_history 表

# events_transactions_summary_by_account_by_event_name表

这一个连接表都允许利用TRUNCATE TABLE语句:

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

END _EVENT_ID: NULL

AVG _TIMER_WAIT: 0

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

……

平日,大家在遇见品质瓶颈时,假使别的的办法难以找寻质量瓶颈的时候(比方:硬件负载不高、SQL优化和库表结构优化都难以奏效的时候),大家通常供给借助等待事件来举办分析,搜索在MySQL
Server内部,到底数据库响应慢是慢在何地。

HOST: localhost

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

|
events_waits_summary_by_host_by_event_name |

WORK_COMPLETED,WORK_ESTIMATED:这么些列提供了阶段事件进程新闻

| events_stages_summary_global_by_event_name |

SUM_ROWS_SENT: 0

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

END_EVENT_ID: NULL

AVG _TIMER_WAIT: 0

# file_summary_by_event_name表

|
events_stages_summary_by_host_by_event_name |

CREATED_TMP_TABLES: 0

THREAD_ID: 47

*
如果log_error_verbosity系统变量设置值超过1,则performance_schema还有恐怕会将错误音信写入错误日志:

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

表记录内容示例(那是贰个举行select
sleep(100);语句的线程等待事件新闻)

EVENT_NAME: stage/sql/After create

(5) socket_instances表

ORDER BY COUNT_STAR DESC LIMIT 10;

DIGEST: NULL

MAX _TIMER_READ_ONLY: 57571000

01

21 rows inset (0.00 sec)

1row in set ( 0.00sec)

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

·ATTR_NAME:连接属性名称;

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

ROWS_EXAMINED:在实践语句期间从存储引擎读取的数码行数

COUNT_STAR: 0

套接字总括表允许选用TRUNCATE
TABLE语句(除events_statements_summary_by_digest之外),只将总计列重新恢复设置为零,实际不是去除行。

| file_summary_by_instance |

SQL_TEXT:SQL语句的公文。若是该行事件是与SQL语句毫无干系的command事件,则该列值为NULL。暗中同意情状下,语句最大呈现长度为1024字节。假设要修改,则在server运行在此之前安装系统变量performance_schema_max_sql_text_length的值

EVENT_NAME: memory/innodb/fil0fil

·已呼吁但未给予的锁(突显怎会话正在等候哪些元数据锁);

|
events_statements_summary_by_program |

RETURNED_SQLSTATE:语句推行的SQLSTATE值,此值来自代码区域的话语会诊区域

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

instance表记录了什么项目标指标被检查测验。那几个表中著录了事件名称(提供采摘作用的instruments名称)及其一些解释性的情况消息(比方:file_instances表中的FILE_NAME文件名称和OPEN_COUNT文件张开次数),instance表首要有如下多少个:

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

NUMBER_OF_SAVEPOINTS,NUMBER_OF_ROLLBACK_TO_SAVEPOINT,NUMBER_OF_RELEASE_SAVEPOINT:在业务内实施的SAVEPOINT,ROLLBACK
TO SAVEPOINT和RELEASE SAVEPOINT语句的多少

| Tables_in_performance_schema (%events_waits_summary%) |

AVG _TIMER_WAIT: 56688392

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

events_waits_current表完整的字段含义如下:

*
将COUNT_ALLOC和COUNT_FREE列重新恢复设置,同仁一视新起先计数(等于内部存款和储蓄器总计新闻以重新载入参数后的数值作为标准数据)

该表允许选用TRUNCATE
TABLE语句。只将总括列重新恢复设置为零,并非剔除行。该表实行truncate时也会隐式触发table_io_waits_summary_by_table表的truncate操作。其余利用DDL语句更动索引结构时,会促成该表的装有索引计算新闻被复位

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

要留神:等待事件相关配置中,setup_instruments表中多方面包车型地铁等候事件instruments都尚未拉开(IO相关的等候事件instruments私下认可一大半已展开),setup_consumers表中waits相关的consumers配置暗中同意未有张开

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

·MySQL
Connector/J定义了之类属性:

2.1反省当前数据库版本是或不是帮忙

events_waits_current表包括当前的等待事件信息,各种线程只突显一行如今监视的等候事件的日前景观

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

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

8rows inset (0.00sec)

*
5)、因为mysql_affected_rows()重返的是多个无符号值,所以row_count()函数再次来到值小于等于0时都转移为0值重回也许不回来给effected值,row_count()函数重临值大于0时则赶回给effected值

EVENT_NAME: statement/sql/select

·OBJECT_INSTANCE_BEGIN:读写锁实例的内部存款和储蓄器地址;

产品:沃趣科技

NESTING_EVENT_ID,NESTING_EVENT_TYPE,NESTING_EVENT_LEVEL:那三列与任何列结合一齐利用,为一等(未知抽象的话语恐怕说是父语句)语句和嵌套语句(在仓库储存的次序中进行的言语)提供以下事件新闻

EVENT_NAME: transaction

下边前境遇这一个表分别开始展览介绍。

| events_waits_summary_by_instance
|

events_stages_history表包涵各样线程最新的N个阶段事件。
在server运维时,N的值会自动调解。
如果要显式设置N值大小,能够在server运行在此之前设置系统变量performance_schema_events_stages_history_size的值。stages事件在实施完成时才增加到events_stages_history表中。
当加多新事件到events_stages_history表时,如果events_stages_history表已满,则会废弃对应线程较旧的风云events_stages_history与events_stages_current表结构一样

COUNT_STAR: 59

·对于已接受的总是,performance_schema根据performance_schema_session_connect_attrs_size系统变量的值检查总计连接属性大小。若是属性大小超过此值,则会实行以下操作:

|
events_statements_summary_global_by_event_name |

events_stages_history 表

MIN_TIMER_WAIT: 72775000

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

正文小结

在含有事务事件音讯的表中,events_transactions_current是基础表。其余包蕴事务事件新闻的表中的数目逻辑上源于当前风浪表。举例:events_transactions_history和events_transactions_history_long表分别富含种种线程最近10行事务事件音讯和全局近日一千0行事务事件音信

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

4rows inset ( 0. 00sec)

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

* 2)、OBJECT_NAME列是文本名

对此内部存款和储蓄器块的自由,依照如下法规进行检验与聚焦:

·SOURCE:源文件的称呼,个中饱含生成事件消息的检查实验代码行号;

|
events_statements_summary_by_user_by_event_name |

*
3)、instruments扶助过程,总专业量可预估(有限进程):WOENVISIONK_COMPLETED和WORK_ESTIMATED列值有效。那体系型的速度呈现可用于online
DDL时期的copy表阶段监视。通过查询events_stages_current表,可监察和控制应用程序当前一度成功了有一些干活,况且可以经过WO奥德赛K_COMPLETED
/ WORK_ESTIMATED总括的比率来预估有个别阶段总体变成比例

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

·WRITE_LOCKED_BY_THREAD_ID:当五个线程当前在独占(写入)格局下持有二个rwlock时,WMuranoITE_LOCKED_BY_THREAD_ID列能够查阅到具有该锁的线程THREAD_ID,如果没有被别的线程持有则该列为NULL;

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

1 row in set (0.00 sec)

1 row in set (0.00 sec)

MAX _TIMER_WAIT: 121025235946125

| events_statements_history_long
|

NESTING_EVENT_LEVEL: 0

SUM _SELECT_FULL _RANGE_JOIN: 0

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

|
events_transactions_summary_by_user_by_event_name |

NESTING_EVENT_ID: NULL

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

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

打开等待事件的搜罗器配置项开关,必要修改setup_instruments
配置表中对应的搜罗器配置项

NO_INDEX_USED: 0

……

COUNT_STAR: 1

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

等第事件表

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

1 row in set (0.00 sec)

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

*
3)、WORK_ESTIMATED值依照检验代码,大概在等第事件实践进度中发生变化

AVG _TIMER_WAIT: 0

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

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

THREAD_ID,EVENT_ID:与事件涉及的线程号和事件运营时的事件编号,能够利用THREAD_ID和EVENT_ID列值来独一标记该行,这两行的值作为整合条件时不会冒出同样的数据行

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

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

20rows inset (0.00sec)

TIMER_WAIT: 59766000

SUM _SORT_MERGE_PASSES: 0

对于利用C
API运营的连天,libmysqlclient库对客户端上的客户端面连接属性数据的总计大小的定点长度限制为64KB:高出限制时调用mysql_options()函数会报CRubicon_INVALID_PARAMETER_NO错误。其余MySQL连接器只怕会安装本身的客户端面包车型地铁接连属性长度限制。

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

LOCK_TIME: 0

对于内部存款和储蓄器总结表中的低水位猜测值,在memory_summary_global_by_event_name表中要是内存全体权在线程之间传输,则该猜度值或许为负数

·OBJECT_NAME:instruments对象的名称,表品级对象;

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

NUMBER_OF_SAVEPOINTS: 0

MAX _TIMER_WAIT: 0

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

1row inset (0.00sec)

events_statements_history_long与events_statements_current表结构一样

HIGH _NUMBER_OF _BYTES_USED: 32

(2)file_instances表

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

*
4)、对于SIGNAL语句:row_count()函数重返0

LOW _NUMBER_OF _BYTES_USED: 0

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

12rows inset (0.01sec)

* 对于文本I/O对象:

EVENT_NAME: transaction

·prepare语句解除财富分配:对已检查评定的prepare语句实例试行COM_STMT_CLOSE或SQLCOM_DEALLOCATE_PREPARE命令,同有的时候候将去除prepare_statements_instances表中对应的行新闻。为了幸免能源泄漏,请务必在prepare语句无需动用的时候实行此步骤释放能源。

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

END_EVENT_ID:当三个事件初阶实践时,对应行记录的该列值被设置为NULL,当三个平地风波执行实现时,对应的行记录的该列值被更新为该事件的ID

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

这一个表列出了守候事件中的sync子类事件相关的对象、文件、连接。个中wait
sync相关的靶子类型有三种:cond、mutex、rwlock。种种实例表都有一个EVENT_NAME或NAME列,用于体现与每行记录相关联的instruments名称。instruments名称也许具有多少个部分并产生档期的顺序结构,详见”配置详解
| performance_schema全方位介绍”。

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

地点的出口结果中,TIME酷威_WAIT字段即意味着该事件的时光支出,单位是飞秒,在骨子里的行使场景中,我们得以使用该字段音讯实行倒序排序,以便寻觅时间支付最大的等待事件。

prepared_statements_instances:依照各类prepare语句实例聚合的计算信息

·execute步骤:语法EXECUTE stmt_name[USING @var_name [,
@var_name] …],示例:execute stmt;
重返实行结果为1,此时在prepared_statements_instances表中的计算信息会议及展览开创新;

| Tables_in_performance_schema
(%transaction%) |

TIMER_START,TIMER_END,TIMER_WAIT:事件的时间消息。那几个值的单位是飞秒(万亿分之一秒)。TIMEPRADO_START和TIMER_END值表示事件的初叶时间和了结时间。TIMESportage_WAIT是事件实践消耗的时日(持续时间)

除此以外,根据帐户、主机、用户、线程聚合的种种等待事件计算表恐怕events_waits_summary_global_by_event_name表,假诺借助的连接表(accounts、hosts、users表)施行truncate时,那么依赖的那几个表中的总计数据也会同一时间被隐式truncate

COUNT_READ: 577

|
events_stages_summary_by_user_by_event_name |

ACCESS_MODE:事务访谈形式。有效值为:READ ONLY或READ W凯雷德ITE

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

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

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

STATE:当前事景况态。有效值为:ACTIVE(推行了START
TRANSACTION或BEGIN语句之后,事务未提交或未回滚此前)、COMMITTED(推行了COMMIT之后)、ROLLED
BACK(推行了ROLLBACK语句之后)

THREAD_ID: 46

COUNT_STAR: 33

performance_schema被视为存款和储蓄引擎。尽管该电动机可用,则应当在INFORMATION_SCHEMA.ENGINES表或SHOW
ENGINES语句的出口中都能够见见它的SUPPORT值为YES,如下:

  • 万一事件未进行到位,则TIME汉兰达_END为日前时光,TIMEEnclave_WAIT为眼下结束所通过的岁月(TIMEPAJERO_END –
    TIMER_START)。
  • 倘若监视仪器配置表setup_instruments中对应的监视器TIMED字段被安装为
    NO,则不会收罗该监视器的岁月音信,那么对于该事件访问的音讯记录中,TIME福睿斯_START,TIMER_END和TIMER_WAIT字段值均为NULL

HOST: localhost

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

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

ESportageROEscortS:语句推行是不是发生错误。假若SQLSTATE值以00(达成)或01(警告)开头,则该列值为0。别的任何SQLSTATE值时,该列值为1

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

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

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

EVENT_ID: 38685

| events_statements_summary_global_by_event_name |

– END –

|
events_statements_summary_by_account_by_event_name |

events_transactions_history_long与events_transactions_current表结构一样

……

OWNER _EVENT_ID: 49

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

EVENT_NAME: wait/synch/cond/sql/Item_func_sleep::cond

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

·假如采用到了目录,则这里展现索引的名字,如若为POdysseyIMA库罗德Y,则意味表I/O使用到了主键索引

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

THREAD_ID: 46

MAX _TIMER_READ_WRITE: 2427645000

| qfsys |10.10. 20.15| 1 |1|

OBJECT_SCHEMA: NULL

如上的出口结果与话语的等候事件方式类似,这里不再赘言,events_transactions_current表完整字段含义如下:

SUM_LOCK_TIME: 26026000000

OBJECT _INSTANCE_BEGIN: 2658003840

|PERFORMANCE_SCHEMA | YES
|Performance Schema

SORT_ROWS:像Sort_rows状态变量一样的计数值,不过此间只用于这几个事件中的语句计算而不对准全局、会话等级

对此较高档其余聚众(全局,按帐户,按用户,按主机)总括表中,低水位和高水位适用于如下法规:

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

SPINS: NULL

  • 对于嵌套语句:OBJECT_TYPE =父语句对象类型,OBJECT_SCHEMA
    =父语句数据库级名称,OBJECT_NAME
    =父语句表级对象名称,NESTING_EVENT_ID
    =父语句EVENT_ID,NESTING_EVENT_TYPE =’STATEMENT’,NESTING_LEVEL
    =父语句NESTING_LEVEL加一,举个例子:1,表示父语句的下一层嵌套语句

5rows inset ( 0. 00sec)

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

END_EVENT_ID: 60

SOURCE: handler.cc:1421

由于performance_schema表内部存款和储蓄器限制,所以保养了DIGEST
= NULL的出格行。
当events_statements_summary_by_digest表限制容积已满的意况下,且新的说话总结音讯在急需插入到该表时又从未在该表中找到相配的DIGEST列值时,就能把这几个语句总括新闻都总计到
DIGEST =
NULL的行中。此行可帮助你测度events_statements_summary_by_digest表的范围是不是须要调动

当客户端断开连接时,performance_schema将核减对应连接的行中的CU奥迪Q7RENT_CONNECTIONS列,保留TOTAL_CONNECTIONS列值。

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

允许利用TRUNCATE TABLE语句

IT从业多年,历任运行技术员、高档运转程序猿、运行高管、数据库技术员,曾到场版本公布系列、轻量级监察和控制系统、运行管理平台、数据库管理平台的布置与编写制定,熟识MySQL体系布局,Innodb存款和储蓄引擎,喜好专研开源本领,追求左右逢原。

·PORT:TCP/IP端口号,取值范围为0〜65535;

2.2. 启用performance_schema

UPDATEsetup_consumers SETENABLED=
‘YES’WHERENAMELIKE’events_stages_%’;

USER: NULL

可通过如下语句查看:

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

CREATED_TMP_DISK_TABLES: 0

1 row in set (0.00 sec)

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

| accounts |

events_transactions_history与events_transactions_current表结构同样

events_statements_summary_by_thread_by_event_name:遵照各类线程和事件名称实行总结的Statement事件

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

2、performance_schema使用高效入门

TIMER_END: 14132636159944419

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

| socket_summary_by_event_name |

| Tables_in_performance_schema
(%statement%) |

  • 借使instruments未有提供进度相关的意义,则该instruments实施事件访谈时就不会有速度消息展现,WOPRADOK_COMPLETED和WORK_ESTIMATED列都会来得为NULL。如若进程新闻可用,则进程消息怎么样展示取决于instruments的执市价况。performance_schema表提供了三个积存进度数据的容器,但不会如果你会定义何种度量单位来使用那么些进程数据:

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

* mutex_instances表中的THREAD_ID列呈现该互斥呈未来被哪些线程持有。

| Engine |Support | Comment

OBJECT_TYPE: NULL

  • SUM_NUMBER_OF_BYTES_FREE

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

| FILE_NAME |EVENT_NAME | OPEN_COUNT |

SOURCE:源文件的称谓及其用于检验该事件的代码位于源文件中的行号

*
LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED将重新恢复设置为CU大切诺基RENT_NUMBER_OF_BYTES_USED列值

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

INDEX_NAME: NULL

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

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

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

3rows inset (0.01sec)

*
对于联合对象(cond,mutex,rwlock):

AVG _TIMER_WAIT: 0

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

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

SORT_MERGE_PASSES:像Sort_merge_passes状态变量一样的计数值,不过此地只用于这些事件中的语句总结而不针对全局、会话品级

*
通常,truncate操作会重新初始化总结消息的规范化数据(即清空从前的多寡),但不会修改当前server的内存分配等气象。也正是说,truncate内部存储器总计表不会放出已分配内部存款和储蓄器

| admin |1| 1 |

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

SELECT_FULL_RANGE_JOIN:像Select_full_range_join状态变量同样的计数值,不过此间只用于这一个事件中的语句总计而不针对全局、会话等第

THREAD_ID: 1

……

|
events_transactions_summary_by_host_by_event_name |

OBJECT_SCHEMA: NULL

performance_schema会记录内部存款和储蓄器使用意况并集合内部存储器使用总结音信,如:使用的内部存款和储蓄器类型(各类缓存,内部缓冲区等)和线程、帐号、用户、主机的相关操作直接进行的内部存款和储蓄器操作。performance_schema从利用的内部存款和储蓄器大小、相关操作数量、高低水位(内部存款和储蓄器三遍操作的最大和纤维的相干计算值)。

OWNER_EVENT_ID: 54

| setup_instruments |

图片 1

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

7.锁对象记录表

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

ROWS_SENT:语句重回给客户端的数额行数

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

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

等级事件记录表,记录语句实践的级差事件的表,与话语事件类型的连锁记录表类似:

*
2)、WORK_COMPLETED值依照检查评定的代码分裂,可以一遍扩张二个或八个单元

AVG _TIMER_WAIT: 0

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

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

上述的输出结果与话语的守候事件情势类似,这里不再赘述,events_statements_current表完整的字段含义如下:

# events_transactions_summary_by_user_by_event_name表

| NULL |41| 45 |

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

events_waits_history_long 表

COUNT_STAR: 7

·各类文件I/O计算表都有贰个或多个分组列,以表明怎么样计算那一个事件消息。这一个表中的事件名称来自setup_instruments表中的name字段:

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

*
1)、WORK_COMPLETED:展现阶段事件已形成的做事单元数

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

MAX_TIMER_EXECUTE: 0

| events_stages_current |

* 1)、OBJECT_SCHEMA列是包括该表的库名称

events_statements_summary_by_program:依据每一种存款和储蓄程序(存款和储蓄进程和函数,触发器和事件)的事件名称举办总结的Statement事件

| localhost |1| 1 |

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

伺机事件表

HOST: localhost

……

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

TIMER_WAIT: 53240151754000

……

……

2.1. 反省当前数据库版本是不是补助

PS:stage事件具有八个速度显示效果,我们得以行使该进程展示效果来询问一些长日子实行的SQL的快慢百分比,比如:对于急需使用COPY情势施行的online
ddl,那么须求copy的数据量是必然的,能够显明的,so..这就可以为”stage/sql/copy
to tmp table stage”
instruments提供三个有停止边界参照的快慢数据消息,这么些instruments所利用的行事单元就是亟需复制的数码行数,此时WOLacrosseK_COMPLETED和WORK_ESTIMATED列值都以立竿见影的可用的,两个的计量比例就象征方今copy表完成copy的行数据百分比。

| events_waits_summary_by_thread_by_event_name |

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

Database changed

PS:允许施行TRUNCATE TABLE语句

AVG _TIMER_WAIT: 0

……

主编:

events_waits_current 表

EVENT_NAME: stage/sql/After create

PS:socket计算表不会总计空闲事件生成的等候事件消息,空闲事件的等候新闻是记录在等候事件总计表中张开计算的。

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

SELECT_RANGE_CHECK: 0

MIN _TIMER_WAIT: 0

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

|performance_schema | ON |

SELECT_RANGE:就像Select_range状态变量同样的计数值,可是此地只用于那一个事件中的语句总结而不针对全局、会话品级

| events_statements_summary_by_account_by_event_name |

从表中的笔录内容能够见到,遵照库xiaoboluo下的表test举办分组,计算了表相关的等候事件调用次数,总括、最小、平均、最大延迟时间音信,利用这个音讯,大家能够概况精晓InnoDB中表的拜访效能排名总括意况,一定水准上反应了对存款和储蓄引擎接口调用的作用。

| THREAD_ID |EVENT_ID | EVENT_NAME |TIMER_WAIT |

events_statements_history表包括每种线程最新的N个语句事件。
在server运转时,N的值会自动调节。
要显式设置N的轻重,能够在server运维在此之前安装系统变量performance_schema_events_statements_history_size的值。
statement事件实施到位时才会增多到该表中。
当增添新事件到该表时,假如对应线程的事件在该表中的分配的定额已满,则会舍弃对应线程的较旧的事件

SUM_TIMER_WAIT: 234614735000

# table_io_waits_summary_by_index_usage表

……

言辞事件表

# events_statements_summary_by_user_by_event_name表

COUNT _READ_WITH _SHARED_LOCKS: 0

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

OBJECT_TYPE: NULL

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

两张表中著录的始末很类似:

2.4.
performance_schema轻易安排与行使

* 对于套接字对象:

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

performance_schema还总计后台线程和不可能注脚用户的总是,对于那几个连接总括行信息,USE景逸SUV和HOST列值为NULL。

| setup_actors |

EVENT_ID: 280

Rows matched: 377 Changed: 377 Warnings: 0

4 rows in set (0.00 sec)

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

events_transactions_history_long 表

EVENT_NAME: memory/performance_schema/mutex_instances

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

今天,很喜欢的报告我们,大家根据 MySQL
官方文档加上大家的印证,整理了一份可以系统学习 performance_schema
的质感分享给大家,为了便利我们阅读,大家整理为了三个多级,一共7篇小说。上面,请随行大家共同开端performance_schema系统的就学之旅吧。

SUM_ERRORS: 2

OWNER_OBJECT_TYPE: NULL

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

*
2)、对于除SELECT之外的DML语句:row_count()函数再次来到实际多少变动的行数。比方:UPDATE、INSERT、DELETE语句,未来也适用于LOAD
DATA
INFILE之类的话语,大于0的再次来到值表示DML语句做了数码变动,假使回到为0,则代表DML语句未有做任何数据变动,也许未有与where子句相配的笔录,若是回去-1则象征语句重返了不当

events_statements_summary_by_account_by_event_name:遵照每个帐户和言辞事件名称举办总结

·ORDINAL_POSITION:将接连属性加多到连年属性集的各种。

8rows inset (0.00sec)

performance_schema_events_transactions_history_size的值。事务事件未实施到位在此以前不会增加到该表中。当有新的专门的职业事件增多到该表时,假设该表已满,则会丢掉对应线程较旧的业务事件

COUNT _READ_ONLY: 1

3rows inset ( 0. 00sec)

|1、**什么是performance_schema**

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

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

MIN_TIMER_READ: 0

| 0 |

events_waits_history_long与events_waits_current表结构一样

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

1 row in set (0.00 sec)

QueryOK, 0 rowsaffected(0.00sec)

  • 使用mysql_query()或mysql_real_query()函数施行语句后,也许会及时调用mysql_affected_rows()函数。假如是UPDATE,DELETE或INSERT,则赶回最终一条语句改造、删除、插入的行数。对于SELECT语句,mysql_affected_rows()的劳作情势与mysql_num_rows()同样(在试行结果最终回来的消息中看不到effected总计新闻)
  • 对于UPDATE语句,受影响的行值默以为实际改换的行数。借使在延续到mysqld时钦定了CLIENT_FOUND_ROWS标志给mysql_real_connect()函数,那么affected-rows的值是“found”的行数。即WHERE子句相称到的行数
  • 对于REPLACE语句,即使发生新旧行替换操作,则受影响的行值为2,因为在这种情景下,实际上是先删除旧值,后插入新值八个行操作
  • 对于INSERT … ON DUPLICATE KEY
    UPDATE语句,假使行作为新行插入,则每行的affected计数为1,即便产生旧行更新为新行则每行affected计数为2,如果未有生出别的插入和立异,则每行的affected计数为0
    (但借使钦点了CLIENT_FOUND_ROWS标记,则未有爆发其余的插入和翻新时,即set值就为当下的值时,每行的受影响行值计数为1实际不是0)
  • 在仓库储存进度的CALL语句调用之后,mysql_affected_rows()重返的熏陶行数是累积程序中的最终叁个言语推行的熏陶行数值,倘若该语句再次来到-1,则存款和储蓄程序最后再次来到0受影响。所以在存款和储蓄程序实践时重回的影响行数并不牢靠,可是你能够自行在仓库储存程序中贯彻一个计数器变量在SQL等级使用ROW_COUNT()来赢得种种语句的受影响的行值并相加,最终通过存款和储蓄程序重回那一个变量值。
  • 在MySQL
    5.7中,mysql_affected_rows()为越多的话语再次回到一个有含义的值。

COUNT_STAR: 0

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

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

* 对于表I/O对象:

HOST: localhost

(1)metadata_locks表

| events_stages_history_long |

EVENT_NAME: transaction

COUNT_STAR: 7

· NAME:与condition相关联的instruments名称;

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

1 row in set (0.00 sec)

当server中的某线程实施了内部存款和储蓄器分配操作时,依照如下法规进行检查评定与集中:

·EXTERNAL_LOCK:在积存引擎品级使用的表锁。有效值为:READ
EXTE昂CoraNAL、WMuranoITE EXTESportageNAL。

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

  • 设若事件未推行到位,则TIME帕杰罗_END为当前放大计时器时间值(当前光阴),TIME福特Explorer_WAIT为最近甘休所通过的时间(TIME奇骏_END –
    TIMER_START)
  • 假诺收集该事件的instruments配置项TIMED =
    NO,则不会征集事件的命宫新闻,TIME瑞虎_START,TIMER_END和TIMER_WAIT在这种情景下均记录为NULL

图片 2

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

今昔,你能够在performance_schema下使用show
tables语句可能通过询问
INFORMATION_SCHEMA.TABLES表中performance_schema引擎相关的元数据来打探在performance_schema下存在着哪些表:

NUMBER _OF_BYTES: NULL

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

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

|EVENT_NAME | SUM_TIMER_WAIT |

TIMER_END: 14698320697396000

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

MIN_TIMER_WAIT: 1905016

|
events_statements_summary_by_host_by_event_name |

SELECT_FULL_JOIN:像Select_full_join状态变量同样的计数值,不过此地只用于那一个事件中的语句总计而不针对全局、会话品级

# events_transactions_summary_by_host_by_event_name表

·TOTAL_CONNECTIONS:某帐号的总连接数(新增加贰个老是累计多个,不会像当前连接数那样连接断开会降低)。

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

表记录内容示例(以下新闻依旧来自select
sleep(100);语句的口舌事件新闻)

*
内存instruments在setup_instruments表中具备memory/code_area/instrument_name格式的名称。但默许情形下大比较多instruments都被剥夺了,默许只开启了memory/performance_schema/*开头的instruments

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

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

NESTING_EVENT_TYPE:表示该行音信中的EVENT_ID事件嵌套的平地风波类型。有效值有:TRANSACTION,STATEMENT,STAGE或WAIT,即父事件的轩然大波类型,假如为TRANSACTION则需要到业务事件表中找对应NESTING_EVENT_ID值的事件,别的连串同理

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

咱们先来探视表中记录的总括消息是何等体统的。

至今,我们掌握了在 MySQL 5.7.17
版本中,performance_schema
下一共有87张表,那么,那87帐表都以寄放什么数据的呢?我们怎么着使用他们来询问大家想要查看的数额吧?先别焦急,大家先来探视那几个表是何等分类的。

MESSAGE_TEXT:语句实施的实际错误音讯,此值来自代码区域的口舌检查判断区域

1 row in set (0.00 sec)

图片 3

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

SOURCE: item_func.cc:6056

# events_waits_summary_global_by_event_name表

COUNT_STAR: 1

| file_instances |

EVENT_NAME: stage/sql/User sleep

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

6 rows inset (0.00 sec)

数据库刚刚初步化并运营时,并不是全部instruments(事件访谈项,在征集项的配置表中每一种都有四个开关字段,或为YES,或为NO)和consumers(与征集项类似,也许有一个对应的平地风波类型保存表配置项,为YES就意味着对应的表保存质量数据,为NO就象征对应的表不保留质量数据)都启用了,所以私下认可不会搜集全部的风云,或许你需求检查评定的平地风波并从未展开,供给进行安装,能够使用如下八个语句展开对应的instruments和consumers(行计数恐怕会因MySQL版本而异),比如,大家以安插监测等待事件数量为例举行表明:

FLAGS:留作现在选拔

相关文章

发表评论

Required fields are marked *.


网站地图xml地图