财神彩票app事件统计 | performance_schema全方位介绍

作者: 互联网  发布:2019-10-12

MIN _TIMER_WAIT: 0

OWNER_OBJECT_SCHEMA: NULL

# memory_summary_global_by_event_name表

* _pid:客户端进程ID

对于较高级别的聚合(全局,按帐户,按用户,按主机)统计表中,低水位和高水位适用于如下规则 :

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

MAX _TIMER_READ_ONLY: 57571000

该表允许使用TRUNCATE TABLE语句。只将统计列重置为零,而不是删除行。该表执行truncate时也会隐式触发table_io_waits_summary_by_table表的truncate操作。另外使用DDL语句更改索引结构时,会导致该表的所有索引统计信息被重置

1 row in set (0.00 sec)

SUM_ERRORS: 0

| events_statements_summary_by_digest |

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

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

OBJECT_SCHEMA: xiaoboluo

EVENT_NAME: stage/sql/After create

(1) session_account_connect_attrs表

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

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

SUM_ROWS_EXAMINED: 39718

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

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

table_io_waits_summary_by_index_usage表:

events_statements_summary_by_program表有自己额外的统计列:

| NAME |OBJECT_INSTANCE_BEGIN | WRITE_LOCKED_BY_THREAD_ID |READ_LOCKED_BY_COUNT |

| events_waits_summary_by_host_by_event_name |

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

* 通常,truncate操作会重置统计信息的基准数据(即清空之前的数据),但不会修改当前server的内存分配等状态。也就是说,truncate内存统计表不会释放已分配内存

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

USER: NULL

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

1 row in set (0.00 sec)

COUNT _READ_WITH _SHARED_LOCKS: 0

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

·当行信息中CURRENT_CONNECTIONS 字段值大于0时,执行truncate语句不会删除这些行,TOTAL_CONNECTIONS字段值被重置为CURRENT_CONNECTIONS字段值;

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

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

# events_stages_summary_by_account_by_event_name表

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

| Tables_in_performance_schema (%events_statements_summary%) |

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

events_waits_summary_by_account_by_event_name表:按照列EVENT_NAME、USER、HOST进行分组事件信息

table_io_waits_summary_by_table表:

1 row in set (0.00 sec)

·NAME:与互斥体关联的instruments名称;

......

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

# events_stages_summary_by_user_by_event_name表

| HOST |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |

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

·ATTR_NAME:连接属性名称;

| events_statements_summary_by_host_by_event_name |

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

SUM_NO_INDEX_USED: 42

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

5rows inset ( 0. 00sec)

·FILE_NAME:磁盘文件名称;

MAX _TIMER_WAIT: 0

EVENT_NAME: wait/io/socket/sql/server_unix_socket

1 row in set (0.00 sec)

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

内存行为监控设置:

COUNT_EXECUTE: 0

HOST: localhost

mutex_instances表列出了server执行mutex instruments时performance_schema所见的所有互斥量。互斥是在代码中使用的一种同步机制,以强制在给定时间内只有一个线程可以访问某些公共资源。可以认为mutex保护着这些公共资源不被随意抢占。

我们先来看看这些表中记录的统计信息是什么样子的(由于单行记录较长,这里只列出memory_summary_by_account_by_event_name 表中的示例数据,其余表的示例数据省略掉部分相同字段)。

OBJECT _INSTANCE_BEGIN: 140568048055488

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

(2)file_instances表

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

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

SUM_WARNINGS: 0

MAX_TIMER_READ: 9498247500

SUM _TIMER_WAIT: 0

| NAME |OBJECT_INSTANCE_BEGIN | LOCKED_BY_THREAD_ID |

SUM _TIMER_WAIT: 0

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

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

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

| memory_summary_by_user_by_event_name |

performance_schema如何管理metadata_locks表中记录的内容(使用LOCK_STATUS列来表示每个锁的状态):

AVG _TIMER_READ_ONLY: 57571000

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

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

[Warning] Connection attributes oflength N were truncated

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

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

USER: root

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

| memory_summary_by_thread_by_event_name |

·file_summary_by_instance:按照每个文件实例(对应具体的每个磁盘文件,例如:表sbtest1的表空间文件sbtest1.ibd)进行统计的文件IO等待事件

AVG _TIMER_WAIT: 0

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

SUM _SORT_MERGE_PASSES: 0

3rows inset ( 0. 00sec)

SUM _TIMER_WAIT: 0

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

* HIGH_COUNT_USED和HIGH_NUMBER_OF_BYTES_USED是较高的高水位估算值。performance_schema输出的低水位值可以保证统计表中的内存分配次数和内存大于或等于当前server中真实的内存分配值

·当之前请求不能立即获得的锁在这之后被授予时,其锁信息行状态更新为GRANTED;

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

1row inset ( 0. 00sec)

......

(3)hosts表

我们先来看看这些表中记录的统计信息是什么样子的。

我们先来看看表中记录的统计信息是什么样子的。

当一个可被监控的内存块N被释放时,performance_schema会对统计表中的如下列进行更新:

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

AVG _TIMER_WAIT: 0

·SOURCE:源文件的名称,其中包含生成事件信息的检测代码行号;

COUNT_STAR: 1

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

COUNT_STAR: 7

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

内存事件在setup_consumers表中没有独立的配置项,且memory/performance_schema/* instruments默认启用,无法在启动时或运行时关闭。performance_schema相关的内存统计信息只保存在memory_summary_global_by_event_name表中,不会保存在按照帐户,主机,用户或线程分类聚合的内存统计表中。

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

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

OBJECT_NAME: test

AVG _TIMER_WAIT: 0

·prepare语句解除资源分配:对已检测的prepare语句实例执行COM_STMT_CLOSE或SQLCOM_DEALLOCATE_PREPARE命令,同时将删除prepare_statements_instances表中对应的行信息。为了避免资源泄漏,请务必在prepare语句不需要使用的时候执行此步骤释放资源。

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

* 已完成的等待事件将添加到events_waits_history和events_waits_history_long表中 ;

5rows inset ( 0. 00sec)

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

出品:沃趣科技

OBJECT_NAME: test

OBJECT_SCHEMA: sys

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

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

COUNT_STAR: 33

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

AVG_TIMER_EXECUTE: 0

THREAD_ID: 47

rwlock_instances表列出了server执行rwlock instruments时performance_schema所见的所有rwlock(读写锁)实例。rwlock是在代码中使用的同步机制,用于强制在给定时间内线程可以按照某些规则访问某些公共资源。可以认为rwlock保护着这些资源不被其他线程随意抢占。访问模式可以是共享的(多个线程可以同时持有共享读锁)、排他的(同时只有一个线程在给定时间可以持有排他写锁)或共享独占的(某个线程持有排他锁定时,同时允许其他线程执行不一致性读)。共享独占访问被称为sxlock,该访问模式在读写场景下可以提高并发性和可扩展性。

EVENT_NAME: statement/sql/select

1row inset ( 0. 00sec)

# events_waits_summary_by_thread_by_event_name表

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

performance_schema把语句事件统计表也按照与等待事件统计表类似的规则进行分类统计,语句事件instruments默认全部开启,所以,语句事件统计表中默认会记录所有的语句事件统计信息,语句事件统计表包含如下几张表:

文件I/O事件统计表只记录等待事件中的IO事件(不包含table和socket子类别),文件I/O事件instruments默认开启,在setup_consumers表中无具体的对应配置。它包含如下两张表:

对于内存块的释放,按照如下规则进行检测与聚合:

我们先来看看表中记录的统计信息是什么样子的。

COUNT_STAR: 0

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

关于内存事件的行为监控设置与注意事项

1 rows in set (0.00 sec)

events_statements_summary_by_host_by_event_name:按照每个主机名和事件名称进行统计的Statement事件

truncate *_summary_global统计表也会隐式地truncate其对应的连接和线程统计表中的信息。例如:truncate events_waits_summary_global_by_event_name会隐式地truncate按照帐户,主机,用户或线程统计的等待事件统计表。

EVENT_NAME: statement/sql/select

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

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

performance_schema还统计后台线程和无法验证用户的连接,对于这些连接统计行信息,USER和HOST列值为NULL。

SUM_TIMER_WAIT:统计给定计时事件的总等待时间。此值仅针对有计时功能的事件instruments或开启了计时功能事件的instruments,如果某事件的instruments不支持计时或者没有开启计时功能,则该字段为NULL。其他xxx_TIMER_WAIT字段值类似

对于使用C API启动的连接,libmysqlclient库对客户端上的客户端面连接属性数据的统计大小的固定长度限制为64KB:超出限制时调用mysql_options()函数会报CR_INVALID_PARAMETER_NO错误。其他MySQL连接器可能会设置自己的客户端面的连接属性长度限制。

......

我们先来看看表中记录的统计信息是什么样子的。

# events_waits_summary_by_account_by_event_name表

我们先来看看表中记录的统计信息是什么样子的。

1 row in set (0.00 sec)

EVENT_NAME: wait/io/socket/sql/client_connection

# events_statements_summary_by_digest表

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

COUNT_STAR: 7

·socket_summary_by_instance表:按照EVENT_NAME(该列有效值为wait/io/socket/sql/client_connection、wait/io/socket/sql/server_tcpip_socket、wait/io/socket/sql/server_unix_socket:)、OBJECT_INSTANCE_BEGIN列进行分组

EVENT_NAME: transaction

下面对这些表分别进行介绍。

COUNT_ALLOC: 1

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

| memory_summary_by_account_by_event_name |

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

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

MIN_TIMER_READ_NORMAL: 0

COUNT_STAR: 0

SUM _TIMER_WAIT: 195829830101250

# events_statements_summary_by_thread_by_event_name表

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

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

数据库对象统计表

* CURRENT_NUMBER_OF_BYTES_USED:减少N

MIN_TIMER_READ: 0

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

两张表中记录的内容很相近:

events_waits_summary_global_by_event_name表:按照EVENT_NAME列进行分组事件信息

OBJECT _INSTANCE_BEGIN: 139968890586816

我们先来看看这些表中记录的统计信息是什么样子的(由于单行记录较长,这里只列出events_statements_summary_by_account_by_event_name 表中的示例数据,其余表的示例数据省略掉部分相同字段)。

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

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

COUNT_READ: 577

SUM _TIMER_READ_WRITE: 8592136000

SUM_TIMER_EXECUTE: 0

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

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

| events_stages_summary_by_thread_by_event_name |

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

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

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

COUNT_FREE: 103

通过对以下两个表执行查询,可以实现对应用程序的监控或DBA可以检测到涉及锁的线程之间的一些瓶颈或死锁信息:

SUM _SELECT_FULL _RANGE_JOIN: 0

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

# events_stages_summary_by_thread_by_event_name表

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

PS2:关于存储程序监控行为:对于在setup_objects表中启用了instruments的存储程序类型,events_statements_summary_by_program将维护存储程序的统计信息,如下所示:

我们先来看看表中记录的统计信息是什么样子的。

SCHEMA_NAME: NULL

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

| events_transactions_summary_by_host_by_event_name |

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

HOST: localhost

COUNT_REPREPARE: 0

事务聚合统计规则

| localhost |1| 1 |

对于每个线程的统计信息,适用以下规则。

·socket_summary_by_instance:针对每个socket实例的所有 socket I/O操作,这些socket操作相关的操作次数、时间和发送接收字节信息由wait/io/socket/* instruments产生。但当连接中断时,在该表中对应socket连接的信息行将被删除(这里的socket是指的当前活跃的连接创建的socket实例)

* 事务所占用的资源需求多少也可能会因事务隔离级别有所差异(例如:锁资源)。但是:每个server可能是使用相同的隔离级别,所以不单独提供隔离级别相关的统计列

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

SUM_ERRORS: 2

* 如果log_error_verbosity系统变量设置值大于1,则performance_schema还会将错误信息写入错误日志:

MIN _TIMER_WAIT: 0

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

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

mutex_instances表字段含义如下:

| events_transactions_summary_global_by_event_name |

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

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

(5) socket_instances表

我们先来看看这些表中记录的统计信息是什么样子的。

| 10.10.20.15 |1| 1 |

1 row in set (0.00 sec)

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

OBJECT_TYPE: PROCEDURE

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

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

02

COUNT_ALLOC: 103

·file_summary_by_event_name:按照每个事件名称进行统计的文件IO等待事件

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

从上面表中的记录信息我们可以看到(与文件I/O事件统计类似,两张表也分别按照socket事件类型统计与按照socket instance进行统计)

性能事件统计表在setup_consumers表中只受控于"global_instrumentation"配置项,也就是说一旦"global_instrumentation"配置项关闭,所有的统计表的统计条目都不执行统计(统计列值为0);

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

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

| NULL |41| 45 |

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

OWNER_THREAD_ID: 48

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

·SQL_TEXT:prepare的语句文本,带“?”的表示是占位符标记,后续execute语句可以对该标记进行传参。

HOST: localhost

EVENT_NAME: wait/io/file/innodb/innodb_data_file

* CURRENT_NUMBER_OF_BYTES_USED:当前已分配的内存块但未释放的统计大小。这是一个便捷列,等于SUM_NUMBER_OF_BYTES_ALLOC

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

1 row in set (0.00 sec)

SUM _NUMBER_OF _BYTES_READ: 0

* COUNT_ALLOC:增加1

·HOST:某个连接的主机名,如果是一个内部线程创建的连接,或者是无法验证的用户创建的连接,则该字段为NULL;

COUNT_STAR: 0

上一篇 《事件统计 | performance_schema全方位介绍》详细介绍了performance_schema的事件统计表,但这些统计数据粒度太粗,仅仅按照事件的5大类别+用户、线程等维度进行分类统计,但有时候我们需要从更细粒度的维度进行分类统计,例如:某个表的IO开销多少、锁开销多少、以及用户连接的一些属性统计信息等。此时就需要查看数据库对象事件统计表与属性统计表了。今天将带领大家一起踏上系列第五篇的征程(全系共7个篇章),本期将为大家全面讲解performance_schema中对象事件统计表与属性统计表。下面,请跟随我们一起开始performance_schema系统的学习之旅吧~

1 row in set (0.00 sec)

root@localhost : performance _schema 04:44:00> select *财神彩票app, from socket_summary _by_event_nameG;

7rows inset ( 0. 00sec)

·内部锁对应SQL层中的锁。是通过调用thr_lock()函数来实现的。(官方手册上说有一个OPERATION列来区分锁类型,该列有效值为:read normal、read with shared locks、read high priority、read no insert、write allow write、write concurrent insert、write delayed、write low priority、write normal。但在该表的定义上并没有看到该字段)

* LOW_COUNT_USED和LOW_NUMBER_OF_BYTES_USED是较低的低水位估算值。performance_schema输出的低水位值可以保证统计表中的内存分配次数和内存小于或等于当前server中真实的内存分配值

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

THREAD_ID: 1

从上面表中的记录信息我们可以看到,table_io_waits_summary_by_index_usage表和table_io_waits_summary_by_table有着类似的统计列,但table_io_waits_summary_by_table表是包含整个表的增删改查等待事件分类统计,table_io_waits_summary_by_index_usage区分了每个表的索引的增删改查等待事件分类统计,而table_lock_waits_summary_by_table表统计纬度类似,但它是用于统计增删改查对应的锁等待时间,而不是IO等待时间,这些表的分组和统计列含义请大家自行举一反三,这里不再赘述,下面针对这三张表做一些必要的说明:

THREAD_ID: 37

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

......

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

SUM _TIMER_WAIT: 0

·OBJECT_INSTANCE_BEGIN:读写锁实例的内存地址;

内存大小统计信息有助于了解当前server的内存消耗,以便及时进行内存调整。内存相关操作计数有助于了解当前server的内存分配器的整体压力,及时掌握server性能数据。例如:分配单个字节一百万次与单次分配一百万个字节的性能开销是不同的,通过跟踪内存分配器分配的内存大小和分配次数就可以知道两者的差异。

·OBJECT_TYPE:元数据锁子系统中使用的锁类型(类似setup_objects表中的OBJECT_TYPE列值):有效值为:GLOBAL、SCHEMA、TABLE、FUNCTION、PROCEDURE、TRIGGER(当前未使用)、EVENT、COMMIT、USER LEVEL LOCK、TABLESPACE、LOCKING SERVICE,USER LEVEL LOCK值表示该锁是使用GET_LOCK()函数获取的锁。LOCKING SERVICE值表示使用锁服务获取的锁;

MAX _TIMER_READ_WRITE: 2427645000

AVG_TIMER_READ_NORMAL: 0

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

友情提示:下文中的统计表中大部分字段含义与上一篇 《事件统计 | performance_schema全方位介绍》 中提到的统计表字段含义相同,下文中不再赘述。此外,由于部分统计表中的记录内容过长,限于篇幅会省略部分文本,如有需要请自行安装MySQL 5.7.11以上版本跟随本文进行同步操作查看。

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

* _program_name:客户端程序名称

SUM _TIMER_WAIT: 0

# table_lock_waits_summary_by_table表

内存事件instruments中除了performance_schema自身内存分配相关的事件instruments配置默认开启之外,其他的内存事件instruments配置都默认关闭的,且在setup_consumers表中没有像等待事件、阶段事件、语句事件与事务事件那样的单独配置项。

| socket_summary_by_event_name |

* SUM_NUMBER_OF_BYTES_ALLOC:增加N

# table_io_waits_summary_by_index_usage表

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

* COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_WRITE:这些列统计了所有文件写操作,包括FPUTS,FPUTC,FPRINTF,VFPRINTF,FWRITE和PWRITE系统调用,还包含了这些I/O操作的数据字节数 ;

Query OK, 377 rows affected (0.00 sec)

1. 连接信息统计表

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

accounts表包含连接到MySQL server的每个account的记录。对于每个帐户,没个user+host唯一标识一行,每行单独计算该帐号的当前连接数和总连接数。server启动时,表的大小会自动调整。要显式设置表大小,可以在server启动之前设置系统变量performance_schema_accounts_size的值。该系统变量设置为0时,表示禁用accounts表的统计信息功能。

SUM _TIMER_WAIT: 0

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

* 此外,按照帐户,主机,用户或线程分类统计的内存统计表或memory_summary_global_by_event_name表,如果在对其依赖的accounts、hosts、users表执行truncate时,会隐式对这些内存统计表执行truncate语句

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

SUM _TIMER_WAIT: 0

AVG _TIMER_WAIT: 3496961251500

MAX _TIMER_WAIT: 0

应用程序可以使用一些键/值对生成一些连接属性,在对mysql server创建连接时传递给server。对于C API,使用mysql_options()和mysql_options4()函数定义属性集。其他MySQL连接器可以使用一些自定义连接属性方法。

MIN _TIMER_WAIT: 0

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

USER: NULL

·PS:cond_instances表不允许使用TRUNCATE TABLE语句。

PS:内存统计表不包含计时信息,因为内存事件不支持时间信息收集。

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

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

performance_schema通过table_handles表记录表锁信息,以对当前每个打开的表所持有的表锁进行追踪记录。table_handles输出表锁instruments采集的内容。这些信息显示server中已打开了哪些表,锁定方式是什么以及被哪个会话持有。

......

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

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

我们先来看看表中记录的统计信息是什么样子的。

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

|NULL | NULL |41| 45 |

| events_transactions_summary_by_account_by_event_name |

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

COUNT_STAR: 3

·当一个pending状态的锁被死锁检测器检测并选定为用于打破死锁时,这个锁会被撤销,并返回错误信息(ER_LOCK_DEADLOCK)给请求锁的会话,锁状态从PENDING更新为VICTIM;

| events_stages_summary_global_by_event_name |

3rows inset ( 0. 00sec)

PS1:

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

EVENT_NAME: transaction

SUM _NUMBER_OF _BYTES_READ: 11567104

* 内存instruments在setup_instruments表中具有memory/code_area/instrument_name格式的名称。但默认情况下大多数instruments都被禁用了,默认只开启了memory/performance_schema/*开头的instruments

COUNT_STAR: 802

| events_stages_summary_by_user_by_event_name |

6 rows inset (0.00 sec)

SUM _CREATED_TMP_TABLES: 10

这些表列出了等待事件中的sync子类事件相关的对象、文件、连接。其中wait sync相关的对象类型有三种:cond、mutex、rwlock。每个实例表都有一个EVENT_NAME或NAME列,用于显示与每行记录相关联的instruments名称。instruments名称可能具有多个部分并形成层次结构,详见"配置详解 | performance_schema全方位介绍"。

下一篇将为大家分享 《数据库对象事件统计与属性统计 | performance_schema全方位介绍》 ,谢谢你的阅读,我们不见不散!返回搜狐,查看更多

OBJECT_NAME: test

EVENT_NAME: memory/innodb/fil0fil

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

MAX _TIMER_WAIT: 0

(2)table_handles表

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

1 row in set (0.00 sec)

| events_transactions_summary_by_thread_by_event_name |

SUM_TIMER_READ_NORMAL: 0

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

(1)accounts表

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

table_handles表是只读的,不能更新。默认自动调整表数据行大小,如果要显式指定个,可以在server启动之前设置系统变量performance_schema_max_table_handles的值。

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

metadata_locks表是只读的,无法更新。默认保留行数会自动调整,如果要配置该表大小,可以在server启动之前设置系统变量performance_schema_max_metadata_locks的值。

注意:这些表只针对等待事件信息进行统计,即包含setup_instruments表中的wait/%开头的采集器+ idle空闲采集器,每个等待事件在每个表中的统计记录行数需要看如何分组(例如:按照用户分组统计的表中,有多少个活跃用户,表中就会有多少条相同采集器的记录),另外,统计计数器是否生效还需要看setup_instruments表中相应的等待事件采集器是否启用。

MAX _TIMER_WAIT: 56688392

* 如果给定语句的统计信息行在events_statements_summary_by_digest表中已经存在,则将该语句的统计信息进行更新,并更新LAST_SEEN列值为当前时间

rwlock_instances表字段含义如下:

| memory_summary_global_by_event_name |

·prepare语句预编译:COM_STMT_PREPARE或SQLCOM_PREPARE命令在server中创建一个prepare语句。如果语句检测成功,则会在prepared_statements_instances表中新添加一行。如果prepare语句无法检测,则会增加Performance_schema_prepared_statements_lost状态变量的值。

| 语句事件统计表

1 row in set (0.00 sec)

| Tables_in_performance_schema (%events_stages_summary%) |

· COUNT_REPREPARE:该行信息对应的prepare语句在内部被重新编译的次数,重新编译prepare语句之后,之前的相关统计信息就不可用了,因为这些统计信息是作为语句执行的一部分被聚合到表中的,而不是单独维护的。

* 注意:如果在server启动之后再修改memory instruments,可能会导致由于丢失之前的分配操作数据而导致在释放之后内存统计信息出现负值,所以不建议在运行时反复开关memory instruments,如果有内存事件统计需要,建议在server启动之前就在my.cnf中配置好需要统计的事件采集

·OBJECT_INSTANCE_BEGIN:此列是套接字实例对象的唯一标识。该值是内存中对象的地址;

events_waits_summary_by_thread_by_event_name表:按照列THREAD_ID、EVENT_NAME进行分组事件信息

·当一个线程尝试获取已经被某个线程持有的互斥体时,在events_waits_current表中会显示尝试获取这个互斥体的线程相关等待事件信息,显示它正在等待的mutex 类别(在EVENT_NAME列中可以看到),并显示正在等待的mutex instance(在OBJECT_INSTANCE_BEGIN列中可以看到);

从上面表中的示例记录信息中,我们可以看到,同样与等待事件类似,按照用户、主机、用户+主机、线程等纬度进行分组与统计的列,分组列与等待事件类似,这里不再赘述,但对于内存统计事件,统计列与其他几种事件统计列不同(因为内存事件不统计时间开销,所以与其他几种事件类型相比无相同统计列),如下:

·COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT:这些列统计所有socket读写操作的次数和时间信息

# events_transactions_summary_by_account_by_event_name表

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

MAX _TIMER_WAIT: 0

·CURRENT_CONNECTIONS:某用户的当前连接数;

Rows matched: 377 Changed: 377 Warnings: 0

# socket_summary_by_instance表

| events_statements_summary_by_user_by_event_name |

OBJECT_SCHEMA: xiaoboluo

| Tables_in_performance_schema (%memory%summary%) |

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

AVG _TIMER_WAIT: 0

·libmysqlclient客户端库(在MySQL和MySQL Connector / C发行版中提供)提供以下属性:

MIN _TIMER_READ_ONLY: 57571000

·LOCK_STATUS:元数据锁子系统的锁状态。有效值为:PENDING、GRANTED、VICTIM、TIMEOUT、KILLED、PRE_ACQUIRE_NOTIFY、POST_RELEASE_NOTIFY。performance_schema根据不同的阶段更改锁状态为这些值;

* 如果DIGEST = NULL行的COUNT_STAR列值占据整个表中所有统计信息的COUNT_STAR列值的比例大于0%,则表示存在由于该表限制已满导致部分语句统计信息无法分类保存,如果你需要保存所有语句的统计信息,可以在server启动之前调整系统变量performance_schema_digests_size的值,默认大小为200

OBJECT _INSTANCE_BEGIN: 2655351104

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

SUM_TIMER_READ: 0

* 如果给定语句的统计信息行在events_statements_summary_by_digest表中没有已存在行,并且events_statements_summary_by_digest表空间限制未满的情况下,会在events_statements_summary_by_digest表中新插入一行统计信息,FIRST_SEEN和LAST_SEEN列都使用当前时间

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

MAX _TIMER_WAIT: 0

OBJECT _INSTANCE_BEGIN: 2658004160

| 温馨提示

·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从空闲状态切换到活动状态,并恢复套接字连接的时间收集功能。

| Tables_in_performance_schema (%events_transactions_summary%) |

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

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

·socket_instances:活跃连接实例。

SUM _TIMER_WAIT: 0

(1)cond_instances表

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

COUNT_READ_NORMAL: 0

* CURRENT_COUNT_USED:减少1

MIN_TIMER_WAIT: 0

MAX _TIMER_WAIT: 0

MAX_TIMER_WAIT: 18446696808701862260

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

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

| events_waits_summary_by_user_by_event_name |

按照数据库对象名称(库级别对象和表级别对象,如:库名和表名)进行统计的等待事件。按照OBJECT_TYPE、OBJECT_SCHEMA、OBJECT_NAME列进行分组,按照COUNT_STAR、xxx_TIMER_WAIT字段进行统计。包含一张objects_summary_global_by_type表。

# events_transactions_summary_by_thread_by_event_name表

MIN_TIMER_WAIT: 1905016

DIGEST: 4fb483fe710f27d1d06f83573c5ce11c

·OWNER_THREAD_ID,OWNER_EVENT_ID:这些列表示创建prepare语句的线程ID和事件ID。

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

INDEX_NAME: PRIMARY

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

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

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

·每个文件I/O统计表都有一个或多个分组列,以表明如何统计这些事件信息。这些表中的事件名称来自setup_instruments表中的name字段:

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

EVENT_NAME: wait/io/socket/sql/client_connection

EVENT_NAME: stage/sql/After create

·INTERNAL_LOCK:在SQL级别使用的表锁。有效值为:READ、READ WITH SHARED LOCKS、READ HIGH PRIORITY、READ NO INSERT、WRITE ALLOW WRITE、WRITE CONCURRENT INSERT、WRITE LOW PRIORITY、WRITE。有关这些锁类型的详细信息,请参阅include/thr_lock.h源文件;

1 row in set (0.00 sec)

# socket_summary_by_event_name表

* COUNT_FREE:增加1

session_account_connect_attrs表仅包含当前连接及其相关联的其他连接的连接属性。要查看所有会话的连接属性,请查看session_connect_attrs表。

对于内存统计表中的低水位估算值,在memory_summary_global_by_event_name表中如果内存所有权在线程之间传输,则该估算值可能为负数

|admin | localhost |1| 1 |

HIGH _NUMBER_OF _BYTES_USED: 32

* performance_schema截断超过长度的属性数据,并增加Performance_schema_session_connect_attrs_lost状态变量值,截断一次增加一次,即该变量表示连接属性被截断了多少次

COUNT _READ_WRITE: 6

4.套接字事件统计

prepared_statements_instances:按照每个prepare语句实例聚合的统计信息

OBJECT_TYPE: TABLE

AVG _TIMER_WAIT: 0

4rows inset ( 0. 00sec)

AVG_TIMER_WAIT: 4426693000

1 row in set (0.00 sec)

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

SQL_TEXT: SELECT 1

6rows inset ( 0. 00sec)

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

1 row in set (0.00 sec)

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

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

(2)users表

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

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

1 row in set (0.00 sec)

这些连接表都允许使用TRUNCATE TABLE语句:

| 等待事件统计表

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

AVG _TIMER_WAIT: 0

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

......

下篇将为大家分享 《复制状态与变量记录表 | performance_schema全方位介绍》 ,谢谢你的阅读,我们不见不散!返回搜狐,查看更多

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

PS:MySQL server使用几种缓存技术通过缓存从文件中读取的信息来避免文件I/O操作。当然,如果内存不够时或者内存竞争比较大时可能导致查询效率低下,这个时候您可能需要通过刷新缓存或者重启server来让其数据通过文件I/O返回而不是通过缓存返回。

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

SUM_LOCK_TIME: 0

events_statements_summary_by_user_by_event_name:按照每个用户名和事件名称进行统计的Statement事件

socket_instances表列出了连接到MySQL server的活跃连接的实时快照信息。对于每个连接到mysql server中的TCP/IP或Unix套接字文件连接都会在此表中记录一行信息。(套接字统计表socket_summary_by_event_name和socket_summary_by_instance中提供了一些附加信息,例如像socket操作以及网络传输和接收的字节数)。

# memory_summary_by_thread_by_event_name表

......

EVENT_NAME: transaction

·OBJECT_TYPE:显示handles锁的类型,表示该表是被哪个table handles打开的;

| Tables_in_performance_schema (%events_waits_summary%) |

·如果值为NULL,则表示表I/O没有使用到索引

关于events_statements_summary_by_digest表

......

AVG _TIMER_WAIT: 1235672000

1row inset ( 0. 00sec)

此外,按照帐户、主机、用户、线程聚合的每个等待事件统计表或者events_waits_summary_global_by_event_name表,如果依赖的连接表(accounts、hosts、users表)执行truncate时,那么依赖的这些表中的统计数据也会同时被隐式truncate 。

OWNER_EVENT_ID: 54

由于performance_schema表内存限制,所以维护了DIGEST = NULL的特殊行。 当events_statements_summary_by_digest表限制容量已满的情况下,且新的语句统计信息在需要插入到该表时又没有在该表中找到匹配的DIGEST列值时,就会把这些语句统计信息都统计到 DIGEST = NULL的行中。此行可帮助您估算events_statements_summary_by_digest表的限制是否需要调整

FILE_NAME: /data/mysqldata1/innodb_ts/ibdata1

COUNT_STAR: 0

|4| _pid |3766| 2 |

# events_transactions_summary_by_user_by_event_name表

套接字统计表允许使用TRUNCATE TABLE语句(除events_statements_summary_by_digest之外),只将统计列重置为零,而不是删除行。

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

OBJECT_SCHEMA: xiaoboluo

MIN _TIMER_WAIT: 0

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

| 阶段事件统计表

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

注意:这些表只针对事务事件信息进行统计,即包含且仅包含setup_instruments表中的transaction采集器,每个事务事件在每个表中的统计记录行数需要看如何分组(例如:按照用户分组统计的表中,有多少个活跃用户,表中就会有多少条相同采集器的记录),另外,统计计数器是否生效还需要看transaction采集器是否启用。

需要持有互斥体的工作负载可以被认为是处于一个关键位置的工作,多个查询可能需要以序列化的方式(一次一个串行)执行这个关键部分,但这可能是一个潜在的性能瓶颈。

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

IP:PORT列组合值可用于标识一个连接。该组合值在events_waits_xxx表的“OBJECT_NAME”列中使用,以标识这些事件信息是来自哪个套接字连接的:

SUM_xxx:针对events_statements_*事件记录表中相应的xxx列进行统计。例如:语句统计表中的SUM_LOCK_TIME和SUM_ERRORS列对events_statements_current事件记录表中LOCK_TIME和ERRORS列进行统计

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

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

允许执行TRUNCATE TABLE语句,但是TRUNCATE TABLE只是重置prepared_statements_instances表的统计信息列,但是不会删除该表中的记录,该表中的记录会在prepare对象被销毁释放的时候自动删除。

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

3rows inset ( 0. 00sec)

SUM _TIMER_WAIT: 0

admin@localhost : performance_schema 05:47:55> select * from table_handles;

USER: root

·prepare步骤:语法PREPARE stmt_name FROM preparable_stmt,示例:PREPARE stmt FROM'SELECT 1'; 执行了该语句之后,在prepared_statements_instances表中就可以查询到一个prepare示例对象了;

USER: root

| Tables_in_performance_schema (%file_summary%) |

EVENT_NAME: stage/sql/After create

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

MIN _TIMER_WAIT: 0

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

| events_statements_summary_by_program |

·THREAD_ID:由server分配的内部线程标识符,每个套接字都由单个线程进行管理,因此每个套接字都可以映射到一个server线程(如果可以映射的话);

MAX _TIMER_WAIT: 0

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

| events_transactions_summary_by_user_by_event_name |

# file_summary_by_event_name表

HOST: NULL

注意:rwlock_instances表中的信息只能查看到持有写锁的线程ID,但是不能查看到持有读锁的线程ID,因为写锁WRITE_LOCKED_BY_THREAD_ID字段记录的是线程ID,读锁只有一个READ_LOCKED_BY_COUNT字段来记录读锁被多少个线程持有。

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

MIN_TIMER_EXECUTE: 0

* 对于memory instruments,setup_instruments表中的TIMED列无效,因为内存操作不支持时间统计

·许多MySQL客户端程序设置的属性值与客户端名称相等的一个program_name属性。例如:mysqladmin和mysqldump分别将program_name连接属性设置为mysqladmin和mysqldump,另外一些MySQL客户端程序还定义了附加属性:

1 row in set (0.00 sec)

COUNT_READ: 0

AVG _TIMER_WAIT: 0

·已请求但未授予的锁(显示哪些会话正在等待哪些元数据锁);

* COUNT_ALLOC,COUNT_FREE:对内存分配和释放内存函数的调用总次数

COUNT_STAR: 1

1 row in set (0.00 sec)

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

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

6.instance 统计表

events_waits_summary_by_instance表:按照列EVENT_NAME、OBJECT_INSTANCE_BEGIN进行分组事件信息。如果一个instruments(event_name)创建有多个实例,则每个实例都具有唯一的OBJECT_INSTANCE_BEGIN值,因此每个实例会进行单独分组

5.prepare语句实例统计表

COUNT_STAR: 0

·file_instances:文件对象实例;

1 row in set (0.00 sec)

......

罗小波·沃趣科技高级数据库技术专家

......

COUNT_STAR: 0

属性统计表

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

STATEMENT_NAME: stmt

USER: NULL

我们先来看看表中记录的统计信息是什么样子的。

MAX _TIMER_WAIT: 2427645000

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

| events_statements_summary_global_by_event_name |

MAX_TIMER_WAIT: 9498247500

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

|4| _platform |x86_64 | 4 |

......

·table_handles:表锁的持有和请求记录。

DIGEST_TEXT: SELECT @@`version_comment` LIMIT ?

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

每个内存统计表都有如下统计列:

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

# events_statements_summary_by_host_by_event_name表

连接属性记录在如下两张表中:

COUNT_STAR: 53

我们先来看看表中记录的统计信息是什么样子的。

1 row in set (0.00 sec)

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

* 以前缀memory/performance_schema命名的instruments可以收集performance_schema自身消耗的内部缓存区大小等信息。memory/performance_schema/* instruments默认启用,无法在启动时或运行时关闭。performance_schema自身相关的内存统计信息只保存在memory_summary_global_by_event_name表中,不会保存在按照帐户,主机,用户或线程分类聚合的内存统计表中

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

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

(1)metadata_locks表

......

每个连接信息表都有CURRENT_CONNECTIONS和TOTAL_CONNECTIONS列,用于跟踪连接的当前连接数和总连接数。对于accounts表,每个连接在表中每行信息的唯一标识为USER+HOST,但是对于users表,只有一个user字段进行标识,而hosts表只有一个host字段用于标识。

* SUM_NUMBER_OF_BYTES_ALLOC,SUM_NUMBER_OF_BYTES_FREE:已分配和已释放的内存块的总字节大小

·当监听套接字检测到连接时,srever将连接转移给一个由单独线程管理的新套接字。新连接线程的instruments具有client_connection的socket_type值,组成对应的instruments名称;

SUM _NO_GOOD _INDEX_USED: 0

hosts表字段含义如下:

SUM _SELECT_FULL_JOIN: 21

MIN_TIMER_READ: 15213375

| prepared_statements_instances |

·ORDINAL_POSITION:将连接属性添加到连接属性集的顺序。

EVENT_NAME: memory/innodb/fil0fil

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

MAX _TIMER_WAIT: 0

prepared_statements_instances表字段含义如下:

每个表都有各自的一个或多个分组列,以确定如何聚合事件信息(所有表都有EVENT_NAME列,列值与setup_instruments表中NAME列值对应),如下:

COUNT_STAR: 2560

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

users表字段含义如下:

从上面表中的示例记录信息中,我们可以看到:

·HOST:某连接的客户端主机名。如果是一个内部线程创建的连接,或者是无法验证的用户创建的连接,则该字段为NULL;

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

PS:对于mutexes、conditions和rwlocks,在运行时虽然允许修改配置,且配置能够修改成功,但是有一部分instruments不生效,需要在启动时配置才会生效,如果你尝试着使用一些应用场景来追踪锁信息,你可能在这些instance表中无法查询到相应的信息。

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

根据请求锁的线程数以及所请求的锁的性质,访问模式有:独占模式、共享独占模式、共享模式、或者所请求的锁不能被全部授予,需要先等待其他线程完成并释放。

1 row in set (0.00 sec)

·rwlock_instances:查看当前rwlock行的一些锁信息(独占锁被哪个线程持有,共享锁被多少个线程持有等)。

SUM_LOCK_TIME: 26026000000

MySQL允许应用程序引入新的连接属性,但是以下划线(_)开头的属性名称保留供内部使用,应用程序不要创建这种格式的连接属性。以确保内部的连接属性不会与应用程序创建的连接属性相冲突。

1 row in set (0.00 sec)

·COUNT_MISC,SUM_TIMER_MISC,MIN_TIMER_MISC,AVG_TIMER_MISC,MAX_TIMER_MISC:这些列统计了所有其他套接字操作,如socket的CONNECT、LISTEN,ACCEPT、CLOSE、SHUTDOWN类型操作。注意:这些操作没有字节计数

对于未按照帐户、主机、用户聚合的统计表,truncate语句会将统计列值重置为零,而不是删除行。

| FILE_NAME |EVENT_NAME | OPEN_COUNT |

SUM _TIMER_READ_ONLY: 57571000

COUNT_STAR: 56

SUM _SELECT_RANGE_CHECK: 0

SUM_TIMER_WAIT: 62379854922

* 如果一个线程开启了采集功能,但是内存相关的instruments没有启用,则该内存释放操作不会被监控到,统计数据也不会发生改变

MIN _TIMER_WAIT: 2971125

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

| Tables_in_performance_schema (%table%summary%) |

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

| socket_summary_by_instance |

1 row in set (0.00 sec)

我们先来看看表中记录的统计信息是什么样子的。

本文由财神彩票app发布于互联网,转载请注明出处:财神彩票app事件统计 | performance_schema全方位介绍

关键词:

上一篇:零售升级这件事,话语权在谁?
下一篇:没有了