[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_STARTTIMER_ENDTIMER_WAIT:事件开始/结束和等待的时间,单位为皮秒(picoseconds
SPINS:互斥锁或读写锁SPIN的次数

OBJECT_SCHEMAOBJECT_NAMEOBJECT_TYPEOBJECT_INSTANCE_BEGIN:这几列的值取决于不同的对象类型
     a.对于condmutexrwlock类型,OBJECT_SCHEMAOBJECT_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_STARTTIMER_ENDTIMER_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_STARTTIMER_ENDTIMER_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_SCHEMAOBJECT_NAMEOBJECT_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_IDNESTING_EVENT_TYPE:保留列,当前值为NULL

3.HISTORY table

历史事件表,比CURRENT EVENT table的记录更多点。例如events_waits_history包含每个线程最近的10个事件,而 events_waits_history_long包含每个线程最近的10,000个事件。你可以通过选项performance_schema_events_waits_history_sizeperformance_schema_events_waits_history_long_size来配置这两个表的大小。
HISTORY/HISTORY LONG表跟CUREENT 表结构类似,只是存储的数据量不同,这里不再赘述。

4.SUMMARY table

汇总表,对事件信息进行聚集。
汇总表是我们关注的重点,因为它省略了人工处理数据的过程,由服务器来进行数据聚集。
主要包括以下几种:

4.1.Event Wait Summaries

这三个表分别根据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

同样包含COUNT_STARSUM_TIMER_WAITMIN_TIMER_WAITAVG_TIMER_WAITMAX_TIMER_WAIT

4.3.Statement Summaries

除了COUNT_STARSUM_TIMER_WAITMIN_TIMER_WAITAVG_TIMER_WAITMAX_TIMER_WAIT,还包括:
SUM_xxx:一些状态信息的SUM值,例如SUM_LOCK_TIME、SUM_ERRORS等等

 在events_statements_summary_by_digest中,还包含了额外的信息:

FIRST_SEEN_TIMESTAMPLAST_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:

4.5.File I/O Summaries

跟文件操作相关的统计信息(文档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_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

4.8.Socket Summaries


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


6.其他杂项表


客户端连接信息表
链接属性表:session_account_connect_attrssession_connect_attrs 前者记录当前session,后者记录所有的session

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

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

performance_timers:有哪些可用的计数器

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

 

原创文章,转载请注明: 转载自Simple Life

本文链接地址: [MySQL 5.6] Performance Schema 表类型纵览 (3)

Post Footer automatically generated by wp-posturl plugin for wordpress.


Comments

Leave a Reply

Your email address will not be published. Name and email are required


Current month ye@r day *