[MySQL 5.6] Performance Schema 表类型纵览 (3)

前面已经提到过了部分Performance Schema表，这里再总结下，PS库下主要分为几类表

1.SETUP table配置表

文档点击，上一篇博客已经介绍过，这里不再展开描述

2.CURRENT EVENT table

最近的事件表，例如 events_waits_current包含每个线程最近的事件


2.1.events_waits_current

该表列出了当前线程正在等待的事件，主要包括以下几列：

THREAD_ID:线程ID

EVENT_ID：当前线程的事件ID，和THREAD_ID组成一个Primary Key.

END_EVENT_ID:当事件开始时，这一列被设置为NULL。当事件结束时，再更新为当前的事件ID

EVENT_NAME：产生该事件的INSTRUMENT名

SOURCE：该事件产生时的源码文件；例如如果在等待一个Mutex，查看对应的源码，就可以知道在那里被阻塞住。

TIMER_START, TIMER_END, TIMER_WAIT：事件开始/结束和等待的时间，单位为皮秒（picoseconds）

SPINS：互斥锁或读写锁SPIN的次数




OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE, OBJECT_INSTANCE_BEGIN：这几列的值取决于不同的对象类型

     a.对于cond, mutex, rwlock类型，OBJECT_SCHEMA, OBJECT_NAME, 以及 OBJECT_TYPE 的值为NULL.OBJECT_INSTANCE_BEGIN表示该同步对象创建的内存地址

     b.对于文件IO对象，OBJECT_SCHEMA为NULL，OBJECT_NAME为文件名，OBJECT_TYPE为FILE，OBJECT_INSTANCE_BEGIN是内存地址。

     c.对于SOCKET对象，OBJECT_NAME为该socket的IP:SOCK值,OBJECT_INSTANCE_BEGIN是对象内存地址

     d.对于表I/O对象，OBJECT_SCHEMA是表的SCHEMA名，OBJECT_NAME是表名，OBJECT_TYPE为TABLE或者TEMPORARY TABLE，OBJECT_INSTANCE_BEGIN是对象的内存地址

INDEX:使用到的索引名

NESTING_EVENT_ID：该事件锁嵌套在的事件ID，

NESTING_EVENT_TYPE：嵌套事件类型(STATEMENT, STAGE, WAIT)

OPERATION:操作类型（lock, read, write）

NUMBER_OF_BYTES:该操作读或写的比特数，对于表的I/O对象，NUMBER_OF_BYTES值为NULL

FLAGS：预留列

2.2.events_stages_current

stage表中列出了一条SQL执行的过程，例如解析SQL，打开一个表，或者执行一次filesort操作等等，可以与show processlist结合起来。该表每一行显示了该线程最近的一条记录

主要包括以下几列：

THREAD_ID：线程ID

EVENT_ID：事件ID

END_EVENT_ID：刚结束的事件ID，以上三列的含义和wait表的相同

SOURCE：源码位置

TIMER_START, TIMER_END, TIMER_WAIT：本阶段开始、结束以及持续的时间；如果事件没有结束，TIMER_END和TIMER_WAIT值为NULL；如果该事件对应的INSTRUMENT的TIMED列设置为NO(SETUP_INSTRUMENTS)，这三列的值都为NULL

NESTING_EVENT_ID：当前事件被嵌套的事件ID，一个stage事件的嵌套事件通常是一个STATEMENT事件

NESTING_EVENT_TYPE：嵌套事件类型（STATEMENT, STAGE 或者WAIT）

2.3.events_statements_current

对statement的监控从发现一个线程活跃开始，到线程的活跃行为结束。换句话说，是从服务器接受客户端的第一个通信包开始，到服务器发送完所有的响应，监控只发生在最顶层的语句，对于在语句中包含的存储过程或者子查询不会单独列出。

从客户端发出的一个请求，既可以是一个COMMAND，也可以是一条SQL，通过statement/com 和statement/sql来划分，再往下划分就是具体的SQL类型或者COMMAND。

另外还有一些错误处理的INSTRUMENT：

statement/com/Error：用于处理服务器不能理解的COMMAND

statement/sql/error：用于处理无法解析的SQL。

在刚开始服务器接受到一条SQL时，先将看做statement/com/Query，在完成解析后，再将其设置成statement/sql/*

该表的列比较多，主要包括：

THREAD_ID、EVENT_ID、END_EVENT_ID、EVENT_NAME、SOURCE：和上面介绍的两个表含义类似，这里不再赘述

TIMER_START, TIMER_END, TIMER_WAIT：和表events_stages_current解释类似，不再赘述

LOCK_TIME：等待表锁的时间

SQL_TEXT：SQL语句，对于COMMAND，值为NULL

DIGEST：该SQL格式化后的 MD5值，需要statement_digest打开才生效

DIGEST_TEXT：该SQL格式化后的字符串，需要statement_digest打开才生效

CURRENT_SCHEMA：该SQL的默认链接的数据库

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE：保留列，值为NULL

OBJECT_INSTANCE_BEGIN：用于标示该对象在内存中的地址




MYSQL_ERRNO：该SQL产生的错误号

RETURNED_SQLSTATE：SQLSTATE值

MESSAGE_TEXT：错误信息

ERRORS：是否发生错误，如果SQLSTATE值以00（完成） 或者01（警告）开始，值为0；否则为1

WARNINGS：告警次数，以上列都取自该SQL的diagnostics area

ROWS_AFFECTED：该SQL影响的行数

ROWS_SENT：发送到客户端的行数

ROWS_EXAMINED：在SQL执行过程中从存储引擎读取的记录数

CREATED_TMP_DISK_TABLES、CREATED_TMP_TABLES、SELECT_FULL_JOIN、SELECT_FULL_RANGE_JOIN、SELECT_RANGE、SELECT_RANGE_CHECK、SELECT_SCAN、SORT_MERGE_PASSES、SORT_RANGE、SORT_ROWS、SORT_SCAN：这些列的名字也有对应的status变量，含义相同，但这里只针对当前这个SQL的统计。

NO_INDEX_USED：如果SQL执行了一次全表扫描，没有用到索引的话值为1，否则为0

NO_GOOD_INDEX_USED：如果优化器没有为该SQL找到一个好的执行计划，值为1，否则值为0.更多的信息查阅EXPLAIN输出的EXTRA列中的“Range checked for each record”

NESTING_EVENT_ID, NESTING_EVENT_TYPE：保留列，当前值为NULL

3.HISTORY table

历史事件表，比CURRENT EVENT table的记录更多点。例如events_waits_history包含每个线程最近的10个事件，而 events_waits_history_long包含每个线程最近的10,000个事件。你可以通过选项performance_schema_events_waits_history_size和performance_schema_events_waits_history_long_size来配置这两个表的大小。

HISTORY/HISTORY LONG表跟CUREENT 表结构类似，只是存储的数据量不同，这里不再赘述。


4.SUMMARY table

汇总表，对事件信息进行聚集。

汇总表是我们关注的重点，因为它省略了人工处理数据的过程，由服务器来进行数据聚集。

主要包括以下几种：

4.1.Event Wait Summaries

events_waits_summary_global_by_event_name




events_waits_summary_by_instance

events_waits_summary_by_thread_by_event_name

这三个表分别根据EVENT名/INSTANCE（EVENT_NAME、OBJECT_INSTANCE_BEGIN）以及（THREAD_ID，EVENT_NAME）进行聚合，聚合列包括：

COUNT_STAR：事件计数

SUM_TIMER_WAIT：总的等待时间

MIN_TIMER_WAIT：最小等待时间

AVG_TIMER_WAIT：平均等待时间

4.2.Stage Summaries

events_stages_summary_by_thread_by_event_name




events_stages_summary_global_by_event_name

同样包含COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT


4.3.Statement Summaries

events_statements_summary_by_thread_by_event_name




events_statements_summary_global_by_event_name

除了COUNT_STAR, SUM_TIMER_WAIT, MIN_TIMER_WAIT, AVG_TIMER_WAIT, MAX_TIMER_WAIT，还包括：

SUM_xxx：一些状态信息的SUM值，例如SUM_LOCK_TIME、SUM_ERRORS等等

 在events_statements_summary_by_digest中，还包含了额外的信息：

FIRST_SEEN_TIMESTAMP, LAST_SEEN_TIMESTAMP,该SQL的摘要（DIGEST）信息第一次生成，以及最近一次生成的时间戳。




聚合的SQL在DIGEST表中生成的规则：

a.存在对应的格式化的SQL,将其信息聚合到该记录中，更新LAST_SEEN_TIMESTAMP

b.新的记录加入到表中（表未满），FIRST_SEEN_TIMESTAMP和LAST_SEEN_TIMESTAMP更新为当前时间

c.如果表已经满了，新记录被聚合到DIGEST=NULL的那一列。该列可以帮助你确认DIGEST SUMMARY表的记录是否具有代表性，DIGEST = NULL行记录的COUNT_STAR，一般如果小于总的5%，则说明汇总记录具有代表性，如果超过50%，可能DBA就需要调整 performance_schema_digests_size变量的值了。

4.4.Object Wait Summaries:

objects_summary_global_by_type




4.5.File I/O Summaries

file_summary_by_event_name




file_summary_by_instance

跟文件操作相关的统计信息（文档http://dev.mysql.com/doc/refman/5.6/en/file-summary-tables.html）

4.6.Table I/O and Lock Wait Summaries

table_io_waits_summary_by_index_usage




table_io_waits_summary_by_table

table_lock_waits_summary_by_table

table_io_waits_summary_by_table是根据wait/io/table/sql/handler，并根据表名进行分组
而table_lock_waits_summary_by_table是我们需要关注的表，因为其中聚合了表锁等待事件，包括internal lock 和 external lock：

internal lock通过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

external lock则通过接口函数handler::external_lock调用存储引擎层，OPERATION列的值为：

read external

write external

4.7.Connection Summaries

events_waits_summary_by_account_by_event_name




events_waits_summary_by_user_by_event_name

events_waits_summary_by_host_by_event_name

events_stages_summary_by_account_by_event_name

events_stages_summary_by_user_by_event_name

events_stages_summary_by_host_by_event_name

events_statements_summary_by_account_by_event_name

events_statements_summary_by_user_by_event_name

events_statements_summary_by_host_by_event_name

4.8.Socket Summaries

socket_summary_by_instance




socket_summary_by_event_name


5.INSTANCE table

实例表记录了当前被监控的事件状态，主要包括以下几种：

  • cond_instances: 条件等待对象实例

    列出当前正在运行的condition wait对象，只包含两列：

    NAME：正在等待的INSTRUMENT名

    OBJECT_INSTANCE_BEGIN： 该condition被监控时的内存地址

  • file_instances: 文件实例

    当执行file io instrument时的文件信息，当一个文件从未被打开时，不会在其中显示，如果从磁盘上删除了文件，也会从该表中删除。

    包含3列：

    NAME:文件名

    EVENT_NAME:instrument名

    OPEN_COUNT：当前文件打开的次数；如果一个文件先打开，再关闭了，这个文件的OPEN_COUNT值为0.

  • mutex_instances: 互斥同步对象实例

    列出了所有当前等待的互斥量,该表包含三列：

    NAME:该mutex的命名

    OBJECT_INSTANCE_BEGIN：对象实例的内存地址

    LOCKED_BY_THREAD_ID：当前锁住该互斥量的线程ID

    对于每一个mutex instrument，PS提供了以下信息：

    a.setup_instruments列出了mutex的命名，以wait/synch/mutex/为命名前缀

    b.当在代码中创建了一个mutex时，就在 mutex_instances中增加一行记录。OBJECT_INSTANCE_BEGIN可以认为是该mutex的唯一标示符。

    c.当一个线程试图锁住一个mutex时， events_waits_current为该线程记录了一行数据，表明其在等待一个mutex（在EVENT_NAME列），以及哪个MUTEX在被等待（OBJECT_INSTANCE_BEGIN列）

    d.当一个线程成功锁住一个mutex,会

    d.1.events_waits_current显示等待该mutex已经完成(TIMER_END和TIMER_WAIT列)

    d.2.完成的等待事件被加入到events_waits_history和 events_waits_history_long表中

    d.3.mutex_instances表中显示该mutex已经被占用(LOCKED_BY_THREAD_ID列)

    e.当该mutex被释放时，LOCKED_BY_THREAD_ID列被设置为NULL

    f.当该mutex对象被销毁时，从mutex_instances中移除对应记录

    通过在以下两个表上执行查询，可以有助于发现性能瓶颈：

    查询events_waits_current：发现线程正在等待什么mutex

    查询mutex_instances,发现该mutex当前被谁占用




  • rwlock_instances: 读写锁同步对象实例

    这个表和mutex_instances类似，不同的是记录的读写锁，包含如下列：

    NAME: 该读写锁instrument命名

    OBJECT_INSTANCE_BEGIN：被创建时的内存地址

    WRITE_LOCKED_BY_THREAD_ID：当前持有写锁的线程ID

    READ_LOCKED_BY_COUNT：读锁计数器

  • socket_instances: 活跃会话对象实例 

    记录当前所有的实时socket连接对象。主要包括两种监听socket（server_tcpip_socket或者server_unix_socket）以及一种客户端连接（client_connection），当一个用户线程中断，对应的记录被删除。

    该表主要包含以下几列：

    EVENT_NAME：命名为 wait/io/socket/*

    OBJECT_INSTANCE_BEGIN：该对象的内存地址

    THREAD_ID：线程ID

    SOCKET_ID： 内部socket id

    IP：客户端IP地址

    PORT:客户端端口号

    STATE:用户线程状态，IDLE或者ACTIVE

文档点击：http://dev.mysql.com/doc/refman/5.6/en/performance-schema-instance-tables.html

6.其他杂项表

客户端连接信息表

accounts、hosts、users.

文档点击：http://dev.mysql.com/doc/refman/5.6/en/performance-schema-connection-tables.html

链接属性表：session_account_connect_attrs、session_connect_attrs 前者记录当前session，后者记录所有的session

相对而言，这些杂项表不是我们性能调优的重点，有兴趣的可以自行阅读文档

host_cache：用于显示内部的host cache信息

performance_timers：有哪些可用的计数器




threads:当前的服务器线程,包括前台和后台线程

时间： 2024-10-04 19:58:39

[MySQL 5.6] Performance Schema 表类型纵览 (3)的相关文章

MySQL5.7新增Performance Schema表

在前面有几篇博客我们已经介绍过MySQL5.6的Performance Schema,详细可点击博客1,博客2,博客3.在MySQL5.6里这些PS表已经包含了足够丰富的信息,帮助我们来分析MySQL的内部运行状态:另外由MySQL官方开发人员写的ps_helper是一组相当好用的ps配套工具,就算对Performance Schema不熟悉的同学,也能读懂其中的信息,感兴趣的同学可以自行谷歌下载. 当然本文的重点不在Performance Schema的使用上,主要是记录下MySQL5.7里新

[MySQL 5.6] Performance Schema 之 PS配置项（1）

尽管Performance Schema(以下简称PS)在5.5中已经出现,但一直没有使用过,并且相比5.6,5.5的PS表要少很多. 以下从一个初学者的角度,阅读PS的官方文档,做一些简单的笔记 官方文档见:http://dev.mysql.com/doc/refman/5.6/en/performance-schema.html 目录:  1.开启PS 2.配置PS 2.1 setup_timers表决定了不同的instrument使用的timer类型 2.2setup_instrument

浅谈MySql的存储引擎（表类型） （转）

什么是MySql数据库 通常意义上,数据库也就是数据的集合,具体到计算机上数据库可以是存储器上一些文件的集合或者一些内存数据的集合. 我们通常说的MySql数据库,sql server数据库等等其实是数据库管理系统,它们可以存储数据,并提供查询和更新数据库中的数据的功能等等.根据数据库如何存储数据和如何操作数据的实现机制不同,这些数据库之间即有区别又有共同点. MySql数据库是开放源代码的关系型数据库.目前,它可以提供的功能有:支持sql语言.子查询.存储过程.触发器.视图.索引.事务.锁.外

浅谈MySql的存储引擎（表类型）_Mysql

什么是MySql数据库     通常意义上,数据库也就是数据的集合,具体到计算机上数据库可以是存储器上一些文件的集合或者一些内存数据的集合.    我们通常说的MySql数据库,sql server数据库等等其实是数据库管理系统,它们可以存储数据,并提供查询和更新数据库中的数据的功能等等.根据数据库如何存储数据和如何操作数据的实现机制不同,这些数据库之间即有区别又有共同点.    MySql数据库是开放源代码的关系型数据库.目前,它可以提供的功能有:支持sql语言.子查询.存储过程.触发器.视图

[MySQL 5.6 ] Performance Schema学习：命名规范、状态变量及其他(2)

PS Instrument命名规范   PS instrument的命名类似于树形结构,最高层次的是instrument的类型,总共四种:idle/wait/stage/statement;再下一层的命名可能是一个子模块名(例如sync,io)等,再往下一层,例如sync,又可以划分成mutex/cond/rwlock,之后也许就是具体的某个同步锁对象,或者下一层的模块. 1.1.idle: idle对象表示socket空闲信息,在setup_instrument表里只包含一列,名字就是idle

MySQL表类型详解

MySQL为我们提供了很多表类型供选择,有MyISAM.ISAM.HEAP.BerkeleyDB.InnoDB,MERGE表类型,萝卜白菜各有所爱是不假,可是真正选择何种表类型还是要看业务需要啊,每一种表类型都有其自己的属性和优点.下面我们来简单的讨论一下. MyISAM表类型: (1)MyISAM表(TYPE=MYISAM)是ISAM类型的一种延伸,具有很多优化和增强的特性. (2)是MySQL的默认表类型. (3)MyISAM优化了压缩比例和速度,并且可以很方便的在不同的操作系统和平台之间进

mysql表类型MyISAM和InnoDB区别

MyISAM:这个是默认类型,它是基于传统的ISAM类型,ISAM是Indexed Sequential Access Method (有索引的顺序访问方法) 的缩写,它是存储记录和文件的标准方法.与其他存储引擎比较,MyISAM具有检查和修复表格的大多数工具. MyISAM表格可以被压缩,而且它们支持全文搜索.它们不是事务安全的,而且也不支持外键.如果事物回滚将造成不完全回滚,不具有原子性.如果执行大量的SELECT,MyISAM是更好的选择. InnoDB:这种类型是事务安全的.它与BDB类

MySQL表类型和存储引擎版本不一致解决方法

使用的是老版本的mysql客户端Navicate 8 ,mysql 服务端用的是mysql5.6的版本,在修改版本引擎的时候出现版本不对; mysql error 'TYPE=MyISAM' 解决办法: Replace TYPE=MyISAM with ENGINE=MyISAM The problem was "TYPE=MyISAM" which should be "ENGINE=MyISAM" as per MySQL version updates – a

MySQL 5.7 SYS SCHEMA

 MySQL 5.7 SYS SCHEMA 官方地址:https://dev.mysql.com/doc/refman/5.7/en/sys-schema.html 1.performance schema:介绍 在MySQL5.7中,performance schema有很大改进,包括引入大量新加入的监控项.降低占用空间和负载,以及通过新的sys schema机制显著提升易用性.在监控方面,performance schema有如下功能: ①:元数据锁: 对于了解会话之间元数据锁的依赖关系至关