[MySQL Reference Manual] 23 Performance Schema结构

原标题:数据库对象事件与属性统计 | performance_schema全方位介绍(五)

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

MySQL Performance-Schema(二) 理论篇,performanceschema

     MySQL
Performance-Schema中总共包含52个表,主要分为几类:Setup表,Instance表,Wait
Event表,Stage Event表Statement
Event表,Connection表和Summary表。上一篇文章已经着重讲了Setup表,这篇文章将会分别就每种类型的表做详细的描述。

Instance表
   
 instance中主要包含了5张表:cond_instances,file_instances,mutex_instances,rwlock_instances和socket_instances。
(1)cond_instances:条件等待对象实例
表中记录了系统中使用的条件变量的对象,OBJECT_INSTANCE_BEGIN为对象的内存地址。比如线程池的timer_cond实例的name为:wait/synch/cond/threadpool/timer_cond

(2)file_instances:文件实例
表中记录了系统中打开了文件的对象,包括ibdata文件,redo文件,binlog文件,用户的表文件等,比如redo日志文件:/u01/my3306/data/ib_logfile0。open_count显示当前文件打开的数目,如果重来没有打开过,不会出现在表中。

(3)mutex_instances:互斥同步对象实例
表中记录了系统中使用互斥量对象的所有记录,其中name为:wait/synch/mutex/*。比如打开文件的互斥量:wait/synch/mutex/mysys/THR_LOCK_open。LOCKED_BY_THREAD_ID显示哪个线程正持有mutex,若没有线程持有,则为NULL。

(4)rwlock_instances: 读写锁同步对象实例
表中记录了系统中使用读写锁对象的所有记录,其中name为
wait/synch/rwlock/*。WRITE_LOCKED_BY_THREAD_ID为正在持有该对象的thread_id,若没有线程持有,则为NULL,READ_LOCKED_BY_COUNT为记录了同时有多少个读者持有读锁。通过
events_waits_current
表可以知道,哪个线程在等待锁;通过rwlock_instances知道哪个线程持有锁。rwlock_instances的缺陷是,只能记录持有写锁的线程,对于读锁则无能为力。

(5)socket_instances:活跃会话对象实例
表中记录了thread_id,socket_id,ip和port,其它表可以通过thread_id与socket_instance进行关联,获取IP-PORT信息,能够与应用对接起来。
event_name主要包含3类:
wait/io/socket/sql/server_unix_socket,服务端unix监听socket
wait/io/socket/sql/server_tcpip_socket,服务端tcp监听socket
wait/io/socket/sql/client_connection,客户端socket

Wait Event表
     
Wait表主要包含3个表,events_waits_current,events_waits_history和events_waits_history_long,通过thread_id+event_id可以唯一确定一条记录。current表记录了当前线程等待的事件,history表记录了每个线程最近等待的10个事件,而history_long表则记录了最近所有线程产生的10000个事件,这里的10和10000都是可以配置的。这三个表表结构相同,history和history_long表数据都来源于current表。current表和history表中可能会有重复事件,并且history表中的事件都是完成了的,没有结束的事件不会加入到history表中。
THREAD_ID:线程ID
EVENT_ID:当前线程的事件ID,和THREAD_ID组成一个Primary Key。
END_EVENT_ID:当事件开始时,这一列被设置为NULL。当事件结束时,再更新为当前的事件ID。
SOURCE:该事件产生时的源码文件
TIMER_START, TIMER_END,
TIMER_WAIT:事件开始/结束和等待的时间,单位为皮秒(picoseconds)

OBJECT_SCHEMA, OBJECT_NAME, OBJECT_TYPE视情况而定
对于同步对象(cond, mutex, rwlock),这个3个值均为NULL
对于文件IO对象,OBJECT_SCHEMA为NULL,OBJECT_NAME为文件名,OBJECT_TYPE为FILE
对于SOCKET对象,OBJECT_NAME为该socket的IP:SOCK值
对于表I/O对象,OBJECT_SCHEMA是表的SCHEMA名,OBJECT_NAME是表名,OBJECT_TYPE为TABLE或者TEMPORARY
TABLE
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT, STAGE, WAIT)
OPERATION:操作类型(lock, read, write)

Stage Event表 

     
 Stage表主要包含3个表,events_stages_current,events_stages_history和events_stages_history_long,通过thread_id+event_id可以唯一确定一条记录。表中记录了当前线程所处的执行阶段,由于可以知道每个阶段的执行时间,因此通过stage表可以得到SQL在每个阶段消耗的时间。

THREAD_ID:线程ID
EVENT_ID:事件ID
END_EVENT_ID:刚结束的事件ID
SOURCE:源码位置
TIMER_START, TIMER_END,
TIMER_WAIT:事件开始/结束和等待的时间,单位为皮秒(picoseconds)
NESTING_EVENT_ID:该事件对应的父事件ID
NESTING_EVENT_TYPE:父事件类型(STATEMENT, STAGE, WAIT)

Statement Event表
     
Statement表主要包含3个表,events_statements_current,events_statements_history和events_statements_history_long。通过thread_id+event_id可以唯一确定一条记录。Statments表只记录最顶层的请求,SQL语句或是COMMAND,每条语句一行,对于嵌套的子查询或者存储过程不会单独列出。event_name形式为statement/sql/*,或statement/com/*
SQL_TEXT:记录SQL语句
DIGEST:对SQL_TEXT做MD5产生的32位字符串。如果为consumer表中没有打开statement_digest选项,则为NULL。
DIGEST_TEXT:将语句中值部分用问号代替,用于SQL语句归类。如果为consumer表中没有打开statement_digest选项,则为NULL。
CURRENT_SCHEMA:默认的数据库名
OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE:保留字段,全部为NULL
ROWS_AFFECTED:影响的数目
ROWS_SENT:返回的记录数
ROWS_EXAMINED:读取的记录数目
CREATED_TMP_DISK_TABLES:创建物理临时表数目
CREATED_TMP_TABLES:创建临时表数目
SELECT_FULL_JOIN:join时,第一个表为全表扫描的数目
SELECT_FULL_RANGE_JOIN:join时,引用表采用range方式扫描的数目
SELECT_RANGE:join时,第一个表采用range方式扫描的数目
SELECT_SCAN:join时,第一个表位全表扫描的数目
SORT_ROWS:排序的记录数目
NESTING_EVENT_ID,NESTING_EVENT_TYPE,保留字段,为NULL。

Connection表
   
 Connection表记录了客户端的信息,主要包括3张表:users,hosts和account表,accounts包含hosts和users的信息。
USER:用户名
HOST:用户的IP

Summary表
   
Summary表聚集了各个维度的统计信息包括表维度,索引维度,会话维度,语句维度和锁维度的统计信息。
(1).wait-summary表
events_waits_summary_global_by_event_name
场景:按等待事件类型聚合,每个事件一条记录。
events_waits_summary_by_instance
场景:按等待事件对象聚合,同一种等待事件,可能有多个实例,每个实例有不同的内存地址,因此
event_name+object_instance_begin唯一确定一条记录。
events_waits_summary_by_thread_by_event_name
场景:按每个线程和事件来统计,thread_id+event_name唯一确定一条记录。
COUNT_STAR:事件计数
SUM_TIMER_WAIT:总的等待时间
MIN_TIMER_WAIT:最小等待时间
MAX_TIMER_WAIT:最大等待时间
AVG_TIMER_WAIT:平均等待时间

(2).stage-summary表
events_stages_summary_by_thread_by_event_name
events_stages_summary_global_by_event_name
与前面类似

(3).statements-summary表
events_statements_summary_by_thread_by_event_name表和events_statements_summary_global_by_event_name表与前面类似。对于events_statements_summary_by_digest表,
FIRST_SEEN_TIMESTAMP:第一个语句执行的时间
LAST_SEEN_TIMESTAMP:最后一个语句执行的时间
场景:用于统计某一段时间内top SQL

(4).file I/O summary表
file_summary_by_event_name [按事件类型统计]
file_summary_by_instance [按具体文件统计]
场景:物理IO维度
FILE_NAME:具体文件名,比如:/u01/my3306/data/tcbuyer_0168/tc_biz_order_2695.ibd
EVENT_NAME:事件名,比如:wait/io/file/innodb/innodb_data_file
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT
统计IO操作
COUNT_READ,SUM_TIMER_READ,MIN_TIMER_READ,AVG_TIMER_READ,MAX_TIMER_READ,
SUM_NUMBER_OF_BYTES_READ
统计读
COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,
SUM_NUMBER_OF_BYTES_WRITE
统计写
COUNT_MISC,SUM_TIMER_MISC,MIN_TIMER_MISC,AVG_TIMER_MISC,MAX_TIMER_MISC
统计其他IO事件,比如create,delete,open,close等

(5).Table I/O and Lock Wait Summaries-表
table_io_waits_summary_by_table
根据wait/io/table/sql/handler,聚合每个表的I/O操作,[逻辑IO]
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT
统计IO操作
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT
统计读
COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,
MAX_TIMER_WRITE
统计写
COUNT_FETCH,SUM_TIMER_FETCH,MIN_TIMER_FETCH,AVG_TIMER_FETCH,
MAX_TIMER_FETCH
与读相同
COUNT_INSERT,SUM_TIMER_INSERT,MIN_[MySQL Reference Manual] 23 Performance Schema结构。TIMER_INSERT,AVG_TIMER_INSERT,MAX_TIMER_INSERT
INSERT统计,相应的还有DELETE和UPDATE统计。

(6).table_io_waits_summary_by_index_usage
与table_io_waits_summary_by_table类似,按索引维度统计

(7).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

(8).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

(9).socket-summaries表
socket_summary_by_instance
socket_summary_by_event_name

其它表
performance_timers: 系统支持的统计时间单位
threads: 监视服务端的当前运行的线程

Performance-Schema(二)
理论篇,performanceschema MySQL
Performance-Schema中总共包含52个表,主要分为几类:Setup表,Instance表,Wait
Event表,Stage Ev…

23 MySQL Performance Schema

23 MySQL Performance Schema..
1

23.1 性能框架快速启动…
3

23.2 性能框架配置…
5

23.2.1 性能框架编译时配置…
5

23.2.2 性能框架启动配置…
6

23.2.3 启动时性能框架配置…
8

23.2.3.1 性能架构事件定时…
8

23.2.3.2 性能框架事件过滤…
9

23.2.3.3 事件预过滤…
10

23.2.3.4命名记录点或者消费者的过滤…
12

23.2.3.5 识别哪些已经被记录…
12

23.3 性能框架查询…
13

23.4 性能框架记录点命名约定…
13

23.5 性能框架和状态监控…
15

23.6 性能框架和分子原子性事件…
17

23.7 性能框架statement digests17

23.8 性能框架常用表特性…
19

23.9 性能框架表描述…
19

23.9.1 性能框架表索引…
19

23.9.2 性能框架setup表…
19

23.9.2.1 setup_actors表…
19

23.9.2.2 setup_consumers表…
20

23.9.2.3 setup_instruments表…
20

23.9.2.4 setup_objects表…
21

23.9.2.5 setup_timers表…
22

23.9.3 性能框架实例表…
22

23.9.3.1 cond_instances表…
22

23.9.3.2 file_instances表…
22

23.9.3.3 mutex_instances表…
22

23.9.3.4 Rwlock_instances表…
23

23.9.3.5 socket_instance表…
23

23.9.4 性能框架事件等待表…
25

23.9.4.1 events_waits_current表…
26

23.9.4.2 Events_waits_history表…
28

23.9.4.3 events_waits_history_long 表…
28

23.9.5 性能框架Stage事件表…
28

23.9.5.1 events_stages_current表…
30

23.9.5.2 events_stage_history表…
30

23.9.5.3 events_stage_history_long表…
31

23.9.6 性能框架语句事件表…
31

23.9.7 性能框架事务表…
32

23.9.8 性能框架连接表…
35

23.9.9 性能框架连接属性表…
35

23.9.10 性能框架用户变量表…
35

23.9.11 性能框架复制表…
36

23.9.11.1
replication_connection_configure表…
38

23.9.11.2
replication_connection_status38

23.9.11.3
replication_applier_configure.
39

23.9.11.4 replication_applier_status39

23.9.11.5
replication_applier_status_by_coordinator39

23.9.11.6
replication_applier_statys_by_worker40

23.9.11.7 replication_group_members40

23.9.11.8
replication_group_member_status40

23.9.12 性能框架锁相关表…
41

23.9.12.1 metadata_locks41

23.9.12.2 table_handles42

23.9.13 性能框架系统变量表…
42

23.9.14 性能框架系统状态变量表…
43

23.9.15 性能框架统计表…
43

23.9.16 性能框架其他表…
44

23.10 性能框架选项和变量…
45

23.11 性能框架命令选项…
45

23.12 性能框架系统变量…
45

23.13 性能框架状态变量…
45

23.14 性能框架内存分配模型…
45

23.15 性能框架和…
46

23.16 使用性能框架诊断…
47

23.17 迁移到性能框架系统和状态变量表…
47

 

MySQL Performance Schema用来监控MySQL
Server的运行运行在底层。性能框架有这些特性:

·         性能框架提供了一种方法检查内部的服务运行。通过PERFORMANCE_SCHEMA存储引擎和performance_schema实现。性能框架主要关注于数据性能。和INFORMANCE_SCHEMA不同,INFORMACE_SCHEMA主要检查元数据。

·         性能框架监控服务事件,事件是服务需要花时间的任何东西,并且已经被记录这样时间信息可以被收集。通常一个事件可以是一个函数调用,一个操作系统等待,SQL语句执行的阶段比如解析或者排序,或者整个语句或者一组语句。时间收集提供。时间收集提供了同步调用文件和表IO,表锁等信息。

·         性能框架事件的事件和binlog的事件,事件调度的事件不同。

·         性能框架事件被指定到某个MySQL服务。性能框架表别人我是本地服务,他们的修改不会被写入到binary
log,也不会被复制。

·         当前事件,历史事件和事件总结是可用的,那么就可以确定记录被启动了多少次,用了多少时间。事件信息可以查看指定线程的活动或者指定对象的活动,比如文件和信号量。

·        
PERFORMANCE_SCHEMA存储引擎使用代码中的记录点来收集信息。

·         收集的信息被保存在performance_schema数据库中。可以用select查询。

·         性能框架配置可以动态的被修改,通过修改performance_schema数据库配置数据收集。

·        
Performance_schema上的表是视图或者临时表,不会保存到磁盘中。

·         MySQL支持所有平台的监控。

·         通过在源代码中加入记录点实现数据收集。没有特定线程使用相关的性能框架。

必威 1

必威 2

23.1 性能框架快速启动

对于性能框架要启用,必须要在MySQL编译的时候配置好。可以通过mysqld的帮助验证。如果性能框架可用输出就会带—performance_schema参数。

如果这些参数没有出现,那么代码在编译时就不支持性能框架。

假设性能框架可用,默认是可用的。可以通过配置文件配置:

[mysqld]
performance_schema=ON

当服务启动,发现performance_schema就会试图初始化性能框架,可以查看performance_schema变量检查初始化是否成功。

mysql>
SHOW
VARIABLES LIKE ‘performance_schema’;

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

|
Variable_name      | Value |

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

|
performance_schema | ON    |

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

这个值表示,性能框架已经可用,如果为off表示发生错误,检查错误日志。

性能框架实现和存储引擎类似。如果引擎可用可以在show
engine查看是否支持PERFORMANCE_SCHEMA存储引擎。

Performance_schema中的数据库可以被划分为几块,当前时间,历史事件,总结,对象实例和安装信息。

原本,其实并不是所有的记录点和收集器都是可用。所以性能框架不会收集所有的数据。可以通过以下语句打开所有的积累点和收集器:

mysql>
UPDATE
setup_instruments SET ENABLED = ‘YES’, TIMED = ‘YES’;

Query
OK, 560 rows affected (0.04 sec)

mysql>
UPDATE
setup_consumers SET ENABLED = ‘YES’;

Query
OK, 10 rows affected (0.00 sec)

当前事件表,可以通过events_waits_current查看当前服务在做什么。每个线程都有一行。

历史表,表结构和当前事件一样,event_waits_history和event_waits_history_long表包含了每个线程最近10个event和每个线程最近10000个events。

一个新的事件被加入,老的事件就会删除。

总结表提供了所有事件的聚合的信息。这个表通过分组一不同方式计算事件数据。为了查看那个记录点呗执行的次数最多或者等待事件最长,通过对表上的count_star或者sum_timer_wait列进行排序:

mysql> SELECT EVENT_NAME, COUNT_STAR

    -> FROM events_waits_summary_global_by_event_name

    -> ORDER BY COUNT_STAR DESC LIMIT 10;

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

| EVENT_NAME                                        | COUNT_STAR |

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

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

| wait/io/file/sql/FRM                              |        452 |

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

| wait/synch/mutex/mysys/THR_LOCK_open              |        187 |

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

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

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

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

| wait/synch/mutex/mysys/THR_LOCK::mutex            |         89 |

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

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

 

mysql> SELECT EVENT_NAME, SUM_TIMER_WAIT

    -> FROM events_waits_summary_global_by_event_name

    -> ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;

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

| EVENT_NAME                             | SUM_TIMER_WAIT |

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

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

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

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

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

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

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

| wait/synch/mutex/mysys/LOCK_alarm      |      145126935 |

| wait/io/file/sql/casetest              |      104324715 |

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

| wait/io/file/sql/pid                   |       72591750 |

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

如,上面结果THR_LOCK信号量是热点,2个语句分别表示执行的热度和等待事件长度。

实例表,记录了对象类型被记录了。当服务使用了一个记录对象,那么会产生一个事件。这些表提供了事件名,解释性的注释或者状态。比如file_instances表,记录了文件io操作和他们对应的文件。

mysql> SELECT * FROM file_instancesG

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

 FILE_NAME: /opt/mysql-log/60500/binlog.000007

EVENT_NAME: wait/io/file/sql/binlog

OPEN_COUNT: 0

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

 FILE_NAME: /opt/mysql/60500/data/mysql/tables_priv.MYI

EVENT_NAME: wait/io/file/myisam/kfile

OPEN_COUNT: 1

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

 FILE_NAME: /opt/mysql/60500/data/mysql/columns_priv.MYI

EVENT_NAME: wait/io/file/myisam/kfile

OPEN_COUNT: 1

...

Setup表用来配置和监控特点的,比如setup_timers表:

mysql> SELECT * FROM setup_timers;

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

| NAME        | TIMER_NAME  |

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

| idle        | MICROSECOND |

| wait        | CYCLE       |

| stage       | NANOSECOND  |

| statement   | NANOSECOND  |

| transaction | NANOSECOND  |

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

Setup_instruments列了哪些可以被记录的事件。然后通过修改这个表开控制是否启动这个记录。

mysql> UPDATE setup_instruments SET ENABLED = 'NO'

    -> WHERE NAME = 'wait/synch/mutex/sql/LOCK_mysql_create_db';

性能框架使用,收集来的事件来更新到performance_schema数据库,数据库作为事件信息的消费者。Setup_consumers表列出了可用的消费者。

控制是否性能框架维护一个消费者作为事件信息的目标。可以设置为enabled值。

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

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

23.2 性能框架配置

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

出品:沃趣科技

23.2.1 性能框架编译时配置

为了让性能框架启用必须在编译时被配置,由官方提供的MySQL是支持性能框架的,如果是其他发布方发布的,那么要先检查是否支持。

如果是从源代码发布的,那么在发布的时候要先设置:

shell>
cmake
. -DWITH_PERFSCHEMA_STORAGE_ENGINE=1

在MySQL 5.7.3之后,也可以支持启动性能框架,但是不包含所有的记录点,比如:

shell>
cmake
. -DWITH_PERFSCHEMA_STORAGE_ENGINE=1

       
-DDISABLE_PSI_STAGE=1

       
-DDISABLE_PSI_STATEMENT=1

如果你安装MySQL到一个老的安装上,并且没有配置过性能框架,当确保performance_schema数据库包含了所有的当前表后,可以使用mysql_upgrade启动服务。然后重启,有个迹象要特别留意:

[ERROR]
Native table ‘performance_schema’.’events_waits_history’ has the
wrong structure
[ERROR] Native table
‘performance_schema’.’events_waits_history_long’has the wrong
structure

通过以下查看mysql是否支持性能框架:

shell>
mysqld
–verbose –help

 
–performance_schema

                     
Enable the performance schema.

 
–performance_schema_events_waits_history_long_size=#

                     
Number of rows in events_waits_history_long.

也可以通过连接到服务之后使用show engine查看是否存在PERFORMANCE_SCHEMA存储引擎。如果在build的时候没有被配置那么show engines不会显示PERFORMANCE_SCHEMA存储引擎。

01

IT从业多年,历任运维工程师、高级运维工程师、运维经理、数据库工程师,曾参与版本发布系统、轻量级监控系统、运维管理平台、数据库管理平台的设计与编写,熟悉MySQL体系结构,Innodb存储引擎,喜好专研开源技术,追求完美。

23.2.2 性能框架启动配置

假设性能框架是可用的,那么默认是启动的也可以在配置文件中配置:

[mysqld]
performance_schema=ON

如果服务不能在初始化性能框架的时候分配内部缓存,那么性能框架自己关闭并且设置performance_schema为off,服务在没有记录点状况下运行。

性能框架可以以命令行参数方式配置。

–performance-schema-instrument=’instrument_name=value

关闭所有记录点:

–performance-schema-instrument=’%=OFF’

比较长的记录点名会比短的积累点名要优先于短的模式名,不管顺序。

具体可以看后面章节:23.2.3.4命名记录点或者消费者的过滤

一个无法别识别的记录点名会被忽略。为了控制消费者,可以使用以下选项:

–performance-schema-consumer-consumer_name=value

consumer_name是一个消费者名比如events_waits_history,value是以下一个值:

l  OFF,False或者0:不收集这个消费者的事件

l  ON,True或者1:收集消费者的事件

比如消费者名是events_waits_history:

--performance-schema-consumer-events-waits-history=ON

被允许的消费者名可以在setup_consumers表上找到。在表中消费者名字都是下划线,在选项配置的时候,下划线和减号没有区别。

性能框架提供了很多系统变量可以用来配置:

mysql> SHOW VARIABLES LIKE 'perf%';

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

| Variable_name                                          | Value   |

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

| performance_schema                                     | ON      |

| performance_schema_accounts_size                       | 100     |

| performance_schema_digests_size                        | 200     |

| performance_schema_events_stages_history_long_size     | 10000   |

| performance_schema_events_stages_history_size          | 10      |

| performance_schema_events_statements_history_long_size | 10000   |

| performance_schema_events_statements_history_size      | 10      |

| performance_schema_events_waits_history_long_size      | 10000   |

| performance_schema_events_waits_history_size           | 10      |

| performance_schema_hosts_size                          | 100     |

| performance_schema_max_cond_classes                    | 80      |

| performance_schema_max_cond_instances                  | 1000    |

...

Performance_Schema表示了性能框架是否启动,别的参数表示表的大小伙子内存分配的值。

可以使用配置文件开设置这些变量:

[mysqld]

performance_schema

performance_schema_events_waits_history_size=20

performance_schema_events_waits_history_long_size=15000

如果没有指定值,那么默认这些变量会有一个默认值。在MySQL
5.7.6,性能框架分配内存会根据服务符合增加伙子减少,而不是在服务启动的时候一次性分配完成。所以很多参数并不需要在启动的时候都分配好,更多内容可以看23.12
性能框架系统变量。

每个自动分配的参数不是在启动时设置或者设置为-1,性能框架决定如何根据以下的参数来设置这些值:

max_connections

open_files_limit

table_definition_cache

table_open_cache

如果要覆盖自动设置的值或者自动范围的值,就在启动的时候设置一个给定的值而不是给-1这样性能框架就会设置一个给定的值。

在运行时,show variables会显示自动设置的值,自动范围设置的会给-1.如果性能框架被禁用,自动设置和自动范围参数都会被设置为-1,并且显示为-1.

数据库对象统计表

| 导语

23.2.3 启动时性能框架配置

1.数据库表级别对象等待事件统计

在上一篇《事件记录 |
performance_schema全方位介绍”》中,我们详细介绍了performance_schema的事件记录表,恭喜大家在学习performance_schema的路上度过了两个最困难的时期。现在,相信大家已经比较清楚什么是事件了,但有时候我们不需要知道每时每刻产生的每一条事件记录信息,
例如:我们希望了解数据库运行以来一段时间的事件统计数据,这个时候就需要查看事件统计表了。今天将带领大家一起踏上系列第四篇的征程(全系共7个篇章),在这一期里,我们将为大家全面讲解performance_schema中事件统计表。统计事件表分为5个类别,分别为等待事件、阶段事件、语句事件、事务事件、内存事件。下面,请跟随我们一起开始performance_schema系统的学习之旅吧。

23.2.3.1 性能架构事件定时

事件被收集也就是说记录点被加到了服务源代码中。记录点时间事件,是性能框架如何提供一个事件持续多久的方案。也可以配置记录点收集定时信息。

性能框架定时器

2个性能框架表提供了定时器信息:


Performance_timers,保存了可用的timers和它们的特点。


Setup_timers,表明了哪些记录点使用了哪个timers。

每个setup_timers使用的计时器躲在performance_timers表中。

mysql>
SELECT
* FROM performance_timers;

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

|
TIMER_NAME  | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD
|

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

|
CYCLE       |      2389029850 |                1 |             72
|

|
NANOSECOND  |      1000000000 |                1 |            112
|

|
MICROSECOND |         1000000 |                1 |            136
|

|
MILLISECOND |            1036 |                1 |            168
|

|
TICK        |             105 |                1 |           2416
|

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

TIMER_NAME:表示可用timer的名字,CYCLE表示给予cpu计数器

TIMER_FREQUENCY:表示每秒的timer个数。对于cycle timer,频率和cpu事件相关,其他timer是秒的若干分。

TIMER_RESOLUTION:表示每次增加的单位

TIMER_OVERHEAD:指定周期获取一个定时需要的最小cycles个数。每个事件都会在开始和结束的时候调用timer,因此是显示的负荷的2倍。

修改setup_timer表的timer_name:

mysql>
UPDATE
setup_timers SET TIMER_NAME = ‘MICROSECOND’

   
-> WHERE
NAME = ‘idle’;

mysql>
SELECT
* FROM setup_timers;

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

|
NAME        | TIMER_NAME  |

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

|
idle        | MICROSECOND |

|
wait        | CYCLE       |

|
stage       | NANOSECOND  |

|
statement   | NANOSECOND  |

|
transaction | NANOSECOND  |

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

默认性能框架会为每个记录点类型设置timer,也可以修改。

对于记录等待事件的时间,最重要的是在时间精度上减少负荷,所以使用cycle
timer最合适。

对于语句或者stage的执行比执行一个简单的等待要大的多,并且需要一个精确的量,并且和处理器无关,所以最好不要使用cycle。默认使用NANOSECOND。尽管负荷比cycle要大,但是不重要,因为调用2次计数器的数量级远远比执行语句本身的cpu时间要小。

Cycle提供的精度和cpu有关,如果处理器是1Gh或者更高,cycle可以提供比纳秒还小的进度。使用cycle计数器比获取一个一天的实际事件开销小。

Cycle的缺点:

l  从cycles转化为时间单位是比较费事的。为了更快,这个转化操作知识很粗糙的乘法计算。

l  处理器cycle,可能会遍,比如笔记本进入省电模式,那么cpu
cycle会下降如果cpu cycle有波动,那么转化就会出错。

l  Cycle 计数器可能是不靠谱的或者不可用的,和处理器或者操作系统有关。

l  一些处理器,乱序执行或者多处理器同步,可能会导致计数器忽高忽低。

性能框架计数器在事件中的表现

存储在性能框架表的当前事件,有3个列表示事件,TIMER_START,TIMER_END表示事件启动和结束,TIMER_WAIT表示事件的时间。

Set_instruments表有ENABLED字段来表示,事件是否要收集。TIMED字段表示记录点是否被时间标记。如果记录点没有启动,那么就不会生成事件。如果不是timed,那么生成的事件,中TIMER_START,TIME_END,TIMER_WAIT是null。那么在统计表计算最大时间,最小时间的时候会被忽略。

内部,事件启动的时候,timer以给定的单位保存在事件里面,当要显示的时候,timers被显示为标准的事件单位,不管选了什么timer都会显示为,皮秒。

Setup_timers的修改会马上生效。已经在处理的会使用老的timer。为了不导致无法预期的结果出现,最好先把统计表使用truncate
table进行重置。

Timer的基线,在服务启动的时候被初始化。TIMER_START,TIMER_END表示从基线以来的皮秒数。TIMER_WAIT表示占用的皮秒。

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

| 等待事件统计表

23.2.3.2 性能框架事件过滤

事件是以生产者消费者模式处理的:

l  记录点代码是事件的源,产生事件被用来收集,setup_instruments表列出了可以被收集的记录点。Setup_instruments表提供了很多event的产生。

l  性能框架表示事件的目的地。Setup_consumers,列出了所有消费者类型。

预过滤,通过修改性能框架配置完成,可以通过启用或者禁用记录点和消费者完成。使用预过滤的目的:

n  减少负荷。性能框架运行需要消耗资源,虽然很少。

n  不关心的事件可以不写入消费者中。

n  避免维护多个类型的事件表。

·           事后过滤,可以使用where语句在查询性能框架的时候过滤。

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

performance_schema把等待事件统计表按照不同的分组列(不同纬度)对等待事件相关的数据进行聚合(聚合统计数据列包括:事件发生次数,总等待时间,最小、最大、平均等待时间),注意:等待事件的采集功能有一部分默认是禁用的,需要的时候可以通过setup_instruments和setup_objects表动态开启,等待事件统计表包含如下几张表:

23.2.3.3 事件预过滤

预过滤有性能框架完成并且会全局的影响所有用户。预过滤可以在生产者或者消费者的处理阶段上:

·           几个表可以用来配置生产者的预过滤:

§  
Setup_instruments说明哪个记录点是可用的,如果这个表上一个记录点被禁用,不管其他表怎么配置,都不会再产生事件。

§  
Setup_objects控制了性能框架特定表和存储过程对象。

§   Threads表示是不是每个服务线程都有监控

§  
Setup_actors新的后台进程的初始监控状态

·           要配置预过滤在消费者阶段,那么要修改setup_comsumers表。setup_comsumers也会影响事件的产生。如果指定的事件不会发送给任何地方,那么性能框架不会产生

修改任意表都会马上影响监控,但是有些例外:

·         修改某些setup_instruments表只有的服务启动的时候生效。在运行时修改不会生效。

·         修改setup_actors表,只会影响后台线程。

当修改监控配置,性能框架不会刷新历史表。历史表和当前表的事件不会被替换,除非又新的事件。如果禁用一个记录点的时候,需要等待一段时间,来替换老的事件。也可以用truncate
table清空。

在修改完记录点之后,可能下那个药伤处summary表清理统计信息对于events_statements_summary_by_digest或者内存统计表。Truncate table只会重置值为0,并不会删除行。

admin@localhost : performance _schema 11:10:42> select * from
objects_summary _global_by _type where SUM_TIMER_WAIT!=0G;

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

23.2.3.3.1 记录点预过滤

控制记录点的过滤,是过滤setup_instruments表设置enables字段。修改setup_instruments大多数会马上生效。对于某些记录点,修改只会在服务器启动才会生效。setup_instruments提供了最基本的记录点控制。

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

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

23.2.3.3.2 对象预过滤

Setup_objects表控制了性能框架部分表和存储过程。修改Setup_objects会马上相应。

mysql>
SELECT
* FROM setup_objects;

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

|
OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME | ENABLED | TIMED
|

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

OBJECT_TYPE:表示对象类型,比如表或者事件,存储过程等。

OBJECT_SCHEMA和OBJECT_NAME包含了schema或者对象名的字符串,也可以是通配符

ENABLED列表示对象是否被监控,TIMED列表示是否收集timing信息。

默认会收集除了mysql,information_schema,performance_schema外所有的的数据库对象。

OBJECT_TYPE: TABLE

| Tables_in_performance_schema (%events_waits_summary%) |

23.2.3.3.3 线程预过滤

threads表为每个线程保存了一行数据。每行数据都包含了线程的信息并且表明是否被监控。对于性能框架监控一个线程必须满足一下他条件:

·         表sestup_consumers表中的thread_instrumentation必须为yes

·        
Threads.instrumented列必须为yes

·         只监控setup_instruments表中的记录点

threads表也说明了每个服务线程是否执行历史事件记录。如果要记录历史事件以下条件都必须为真:

·         对应的消费者配置,setup_consumers表必须为yes。

·        
Threads.HISTORY列必须为yes。

·         只监控setup_instruments表中的记录点

对于后台线程,instrumented和history的初始数据,取决于setup_action中的配置。

mysql>
SELECT
* FROM setup_actors;

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

|
HOST | USER | ROLE | ENABLED | HISTORY |

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

|
%    | %    | %    | YES     | YES     |

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

thread表的instrumented和history的规则如下:

·         如果最佳匹配,enabled=yes,那么instrumented=yes,最佳匹配history=yes,那么threads表的history=yes

·         如果最佳匹配,enabled=no,那么instrumented=no,最佳匹配history=no,那么threads表的history=no

·         如果无法匹配,那么instrumented,history都为no

在mysql 5.7.6 之前,没有enabled字段,只要有匹配,那么instrumented=yes

在mysql5.7.8,之前,没有history字段,线程要不全部可以进入history要不都不能,取决于setup_consumer的配置。

默认,后台的所有线程都是会被记录的,因为setup_actors有一行都是‘%’。

OBJECT_SCHEMA: xiaoboluo

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

23.2.3.3.4 消费者预过滤

Setup_cunsumers表包含了所有的消费者。修改这个表来过滤那些event会被发送。

Setup_consumers表中设置消费者,从高级到低级。主要的原则如下:

·           除非性能框架检查消费者,并且消费者是可用的,不然不会受到消息。

·           只有当消费者依赖的所有的消费者都可用了,才会被检查

·           被依赖的消费者,有自己的依赖消费者。

·           如果一个事件没有目的,那么性能框架不会被产生。

全局和线程消费者

·          
Global_instrumentation是高级消费者,如果global_instrumentation为no,那么所有的的全局记录点都被禁用。所有其他低级的都不会被检查。当global_instrumentation启动了,才会去检查thread_instrumentation

·          
Thread_instrumentation,如果是no,那么这个级别下面的级别都不会被检查,如果是yes,性能框架就会维护线程指定信息,并且检查events_xxx_current消费者。

Wait Event消费者

这些消费者,需要global_instrumentation,thread_instrumention为yes。如果被检查行为如下:

·          
Events_waits_current,如果为no,禁用对各个wait
event收集。如果为yes检查history消费者和history_long消费者。

·          
Events_waits_history,如果上级为no不检查,为yes,收集各个等待事件。

·          
Events_waits_history_long,和上面类似

Stage event,statement event和上面类似。

OBJECT_NAME: test

| events_waits_summary_by_account_by_event_name |

23.2.3.4命名记录点或者消费者的过滤

可以对指定记录名或者消费者进行过滤:

mysql>
UPDATE
setup_instruments

   
-> SET
ENABLED = ‘NO’

   
-> WHERE
NAME = ‘wait/synch/mutex/myisammrg/MYRG_INFO::mutex’;

 

mysql>
UPDATE
setup_consumers

   
-> SET
ENABLED = ‘NO’ WHERE NAME = ‘events_waits_current’;

指定一组记录点或者消费者:

mysql>
UPDATE
setup_instruments

   
-> SET
ENABLED = ‘NO’

   
-> WHERE
NAME LIKE ‘wait/synch/mutex/%’;

 

mysql>
UPDATE
setup_consumers

   
-> SET
ENABLED = ‘NO’ WHERE NAME LIKE ‘%history%’;

COUNT_STAR: 56

| events_waits_summary_by_host_by_event_name |

23.2.3.5 识别哪些已经被记录

通过检查setup_instruments表,你可以得知包含了哪些记录点被记录:

mysql>
SELECT
* FROM setup_instruments WHERE NAME LIKE
‘wait/io/file/innodb/%’;

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

|
NAME                                 | ENABLED | TIMED |

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

|
wait/io/file/innodb/innodb_data_file | YES     | YES   |

|
wait/io/file/innodb/innodb_log_file  | YES     | YES   |

|
wait/io/file/innodb/innodb_temp_file | YES     | YES   |

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

SUM _TIMER_WAIT: 195829830101250

| events_waits_summary_by_instance |

23.3 性能框架查询

预过滤限制了哪些事件信息被收集,很多用户都不同。可以通过select过滤event。

mysql>
SELECT
THREAD_ID, NUMBER_OF_BYTES

   
-> FROM
events_waits_history

   
-> WHERE
EVENT_NAME LIKE ‘wait/io/file/%’

   
-> AND
NUMBER_OF_BYTES IS NOT NULL;

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

|
THREAD_ID | NUMBER_OF_BYTES |

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

|       
11 |              66 |

|       
11 |              47 |

|       
11 |             139 |

|        
5 |              24 |

|        
5 |             834 |

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

MIN _TIMER_WAIT: 2971125

| events_waits_summary_by_thread_by_event_name |

23.4 性能框架记录点命名约定

记录点命名是一串组件然后用‘/’分割:

wait/io/file/myisam/log
wait/io/file/mysys/charset
wait/lock/table/sql/handler
wait/synch/cond/mysys/COND_alarm
wait/synch/cond/sql/BINLOG::update_cond
wait/synch/mutex/mysys/BITMAP_mutex
wait/synch/mutex/sql/LOCK_delete
wait/synch/rwlock/sql/Query_cache_query::lock
stage/sql/closing tables
stage/sql/Sorting result
statement/com/Execute
statement/com/Query
statement/sql/create_table
statement/sql/lock_tables

记录点命名类似于树形结构。从左到右越来越详细,组件的名称以来与计数器类型。

名字由2部分组成:

·           组件名,比如mysiam

·           变量名,一种是全局变量,还有一种是class::value。值class类中的变量。

顶级记录点组件

·          
Idle:表示idle事件的记录点。

·          
Memory:memory事件记录点

·          
Stage:阶段事件记录点

·          
Statement:语句事件记录点

·          
Transaction:事务事件记录点

·          
Wait:等待事件记录点

Idle记录点组件

Idle记录点用于idle事件,具体看:23.9.3.5 socket_instance表

内存记录点组件

很多内存记录点默认是不可用的,可以手动启动,修改setup_instruments表。记录点前缀,memory/performance_schema/表示有多少性能框架内部的内存分配。memory/performance_schema/总是启用的,并且不能被禁用。这件记录点被收集在 memory_summary_global_by_event_name表。

Stage记录点组件

Stage表示语句阶段性处理的比如sorting
result或者sending data。

语句记录点组件

·          
Statement/abstract/*: 抽象语句操作记录点。抽象记录点在语句早期使用。

·          
Statement/com :是记录点命令操作。并且有名字对应到com_xxx操作,比如statement/com/Connect 和 statement/com/Init DB对应到COM_CONNECT和COM_INIT_DB命令。

·          
Statement/scheduler/event:单个记录点用来跟踪所有事件调度生成的事件。

·          
Statement/sp :存储过程执行内部的记录点,比如statement/sp/cfetch
和statement/sp/freturn,用来游标获取和函数返回。

·          
Statement/sql:sql操作的记录点,比如statement/sql/create_db和statement/sql/select,用于创建数据库和select语句。

等待记录点指令

·          
Wait/io,io操作记录点

§  
Wait/io/file:文件io操作记录点,对于文件,等待是等待文件操作文件完成。因为缓存的关系,物理文件io可能在这个操作上不会执行

§  
Wait/io/socket:socket操作记录点,socket记录点有以下命名格式:wait/io/socket/sql/socket_type。服务有一个监听socket用来支持每个网络协议。这个记录点支持监听socket是tcpip或者unix
socket文件。socket_type的值为server_tcpip_socket或者server_unix_socket。当监听socket发现一个连接,服务把这个连接转换到独立的线程。那么新的连接线程的socket_type为client_connection。

§   Wait/io/table:
表io操作记录点。包含持久性表或者临时表的行级别访问。对行的影响就是fetch,insert,update,delete。对于视图,是被视图引用的基表。和其他等待不同,表的io等待报货其他等待。比如表io可能包含,文件io或者内存操作。因此events_waits_current中对于行的等待可能有2行。

·          
Wait/lock ,锁操作的记录点

§  
Wait/lock/table,表锁记录点操作

§  
Wait/lock/metadata/sql/mdl,元数据所操作

·          
Wait/synch,同步对象记录点

§  
Wait/synch/cond,条件被用来一个线程通知另外一个线程,某些它们等待的东西已经完成。如果一个线程等待一个条件,那么会醒来并且处理。如果多个线程等待那么会都新来并且完成它们等待的资源。

§  
Wait/synch/mutex,多排他对象用来访问一个资源,防止其他线程访问资源。

§  
Wait/synch/rwlock,一个读写锁对象用来锁定特定的变量,防止其他线程使用。一个共享读所可以多个线程同时获取。一个排他写锁只能由一个线程获取。

§  
Wait/synch/sxlock,共享排他锁是读写锁的rwlock的一种,提供当一个线程写时,其他线程可以非一致性读。Sxlock在mysql 5.7中使用为了优化rwlock的或展现。

AVG _TIMER_WAIT: 3496961251500

| events_waits_summary_by_user_by_event_name |

23.5 性能框架和状态监控

可以使用show status like ‘%perf%’查看性能框架的状态。

性能框架状态变量提供了关于记录点因为内存的原因没有被创建或者加载的信息。根据状态命名有几类:

·          
Performance_Schema_xxx_class_lost,表示有多少xxx类型的记录点不能被加载。

·          
Performance_schema_xxx_instance_lost,表示有多少xxx类型的记录点不能被创建。

·          
Performance_schema_xxx_handlees_lost,表示有多少xxx类型的记录点不能被打开。

·          
Performance_schema_locker_lost,表示有多少时间都是或者没有被记录。

比如,一个信号量是记录点,但是服务不能为记录点分配内存。那么会增加performnace_schema_mutex_classes_lost。但是信号量还是以用于对象同步。但是性能数据就无法被收集,如果记录点被分配,用来初始化记录点信号量实体。对于单独的信号量比如全局信号量,只有一个实例。有些信号量的实例个数会变化,比如每个连接的信号量。如果服务不能创建一个指定记录点信号量实体,就会增加,performance_schema_mutex_instance_lost。

假设有以下条件:

·           服务启动参数,–performance_schema_max_mutex_classes=200,因此有200个信号量空间。

·           150信号量已经被加载

·           插件plugin_a有40个信号量

·           插件plugin_b有20个信号量

服务为插件,分配信号量记录点依赖于已经分配了多少,比如以下语句:

INSTALL
PLUGIN plugin_a

那么服务已经有了150+40个信号量。

UNINSTALL
PLUGIN plugin_a;

虽然插件已经卸载,但是还是有190个信号量。所有插件代码生成的历史数据还是有效。但是新的记录点事件不会被分配。

INSTALL
PLUGIN plugin_a;

服务发现40个记录点已经被分配,因此新的记录点不会被创建,并且之前分配的内部buffer会被重新使用,信号量还是190个。

INSTALL
PLUGIN plugin_b;

这个使用可用信号量已经只有10个了,新的插件要20个记录点。10个已经被加载,10个会被取消或者丢失。Performance_schema_mutex_classes_lost会标记这些丢失的记录点。

mysql>
SHOW
STATUS LIKE “perf%mutex_classes_lost”;

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

|
Variable_name                         | Value |

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

|
Performance_schema_mutex_classes_lost | 10    |

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

1
row in set (0.10 sec)

Plugin_b任然会收集执行部分记录点。

当服务不能创建一个信号量记录点,那么会发生以下情况:

·           不会有新行被插入到setup_instruments表

·          
Performance_Schema_mutex_classes_lost增加1

·          
Performance_schema_mutex_instance_lost,不会改变。

上面描述的适用于所有记录点,不单单是信号量。

当Performance_Schema_mutex_classes_lost大于0那么有2种情况:

·           为了保存一些内存,你可以启动,Performance_Schema_mutex_classes=N,N小于默认值。默认值是满足加载所有插件的mysql发布。但是一些插件如果不加载可能会少一点。比如你可以不加载默写存储引擎。

·           你加载一个第三方插件,是性能框架的记录点,但是在服务启动的时候,不允许插件记录点内存获取。因为来自第三方,这个引擎的记录点内存并不会被记录在performance_schema_max_mutex_classes.
如果服务不能满足插件记录点的资源,没有显示的分配更多的 performance_schema_max_mutex_classes,那么久会出现记录点的饥饿。

 

如果performance_schema_max_mutex_classes.太小,没有错误会被写入到错误日志,并且在运行时没有错误。然而performance_schema上的表会丢失事件。performance_schema_max_mutex_classes_lost状态变量只是标记一些事件因为创建记录点失败被删除。

 

如果记录点没有丢失,那么就会通知性能框架,当在代码中(THD::LOCK_delete)创建了信号量,单个记录点就会被使用。那么就需要很多信号量实体。这个时候,每个线程都有lock_delete,比如有1000个线程,1000个lock_delete信号量记录点实例。

如果服务没有空间存放所有1000个信号量记录点实体,一些信号量会被创建记录点,一些就不会被创建。如果服务职能创建800个,那么另外200个会丢失,Performance_schema_mutex_instances_lost会增加200个。

Performance_schema_mutex_instances_lost,可能在要初始化的信号量记录点大于配置的Performance_schema_mutex_instances=N那么久会发生。

如果SHOW STATUS LIKE ‘perf%’没有丢失任何东西,那么新能框架数据是可以被依赖的。如果有一些都是了,那么数据是不完整的,并且性能框架不会记录所有。这样Performance_schema_xxx_lost就说明了问题范围。

有些时候饥饿时可以均衡的,比如你可能不需要文件io的数据,那么可以把所有性能框架参数,和文件io相关的都设置为0,那么久不会把内存分配到和文件相关的类,对象实例或者句柄中。

MAX _TIMER_WAIT: 121025235946125

| events_waits_summary_global_by_event_name |

23.6 性能框架和分子原子性事件

对于一个表的io事件,通常有2行在events_waits_current,不是一个如:

Row#
EVENT_NAME                 TIMER_START TIMER_END
—- ———-                 ———– ———
   1 wait/io/file/myisam/dfile        10001 10002
   2 wait/io/table/sql/handler        10000 NULL

行获取会导致文件读取。比如,表io获取事件在文件io事件之前,但是还没有完成。那么文件io嵌入在表io事件。

和其他原子性等待事件不同,表io事件是分子,包含其他事件。Events_waits_current中,表io事件通常有2行:

·           一行是当前表io等待事件

·           一行是其他任何类型的等待事件。

通常,其他类型的等待事件不是表io事件。当副事件完成,会从events_waits_current中消失。

1 row in set (0.00 sec)

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

23.7 性能框架statement digests

MySQL服务有能力维护statement digest信息。Digest进程把一个sql语句转化为标准的格式并且计算一个hash结果。标准化允许相似的语句分组并且总结暴露一些语句的类型和发生的频率。

在性能框架,语句digest涉及这些组件:

·          
Setup_comsumers的statement_digset控制了,性能框架如何维护digest信息。

·           语句事件表有列包含digest和相关的值的列:

§  
DIGEST_TEXT,标准化的语句。

§   DIGEST,是digest MD5 hash值。

Digest计算,最大的可用空间1024B。MySQL 5.7.8后这个值可以通过参数,performance_schema_max_digest_length修改。之前使用max_digest_length。

·           语句事件表也有sql_text列包含了原始的sql语句。语句显示的最大为1024B,可以通过performance_schema_max_sql_text_length字段修改。

·          
events_statements_summary_by_digest,提供综合的语句digset信息。

标准化一个语句转化,会保留语句结构,删除不必要的信息:

·           对象标识符,比如表或者数据库名会被保留。

·           文本值会被替换成变量。

·           注释会被删除,空格会被调整。

比如如下2个语句:

SELECT * FROM orders WHERE customer_id=10 AND quantity>20

SELECT * FROM orders WHERE customer_id = 20 AND quantity > 100

替换后会变成:

SELECT * FROM orders WHERE customer_id = ? AND quantity > ?

对于每个标准化的语句提供一个DIGEST_TEXT和DIGEST一个hash值。语句Digest总结表,提供了语句的profile信息,显示语句运行频率运行次数等。

events_statements_summary_by_digest大小固定的,所以如果满了,如果在表上没有匹配的,那么所有的语句都会被计算在schema_name和digest为null的记录里面,当然可以增加digest大小,performance_schema_digests_size,如果没有指定,那么性能框架会自己评估一个值。

performance_schema_max_digest_length系统变量决定digest buffer最大可用字节。但是现实的语句digest的长度往往比buffer长,那是因为关键字和文本值的关系。也就是说digest_text的长度可能超过performance_schema_max_digest_length。

对于应用程序生成了很长的语句,只有结尾不同,增加performance_schema_max_digest_length可以让digest得以计算,识别语句。反过来减少performance_schema_max_digest_length会导致服务牺牲很少的内存来保存语句的digest,但是增加了语句的相似度,被当成同一个digest。如果长度要求长,那么保存的也要更多。

可以通过show engine performance_schema
status语句,或者监控以下语句查看sql语句保存使用的内存量。

mysql> SELECT NAME FROM setup_instruments

    -> WHERE NAME LIKE '%.sqltext';

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

| NAME                                                             |

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

| memory/performance_schema/events_statements_history.sqltext      |

| memory/performance_schema/events_statements_current.sqltext      |

| memory/performance_schema/events_statements_history_long.sqltext |

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

 

mysql> SELECT NAME FROM setup_instruments

    -> WHERE NAME LIKE 'memory/performance_schema/%.tokens';

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

| NAME                                                                 |

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

| memory/performance_schema/events_statements_history.tokens           |

| memory/performance_schema/events_statements_current.tokens           |

| memory/performance_schema/events_statements_summary_by_digest.tokens |

| memory/performance_schema/events_statements_history_long.tokens      |

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

从表中的记录内容可以看到,按照库xiaoboluo下的表test进行分组,统计了表相关的等待事件调用次数,总计、最小、平均、最大延迟时间信息,利用这些信息,我们可以大致了解InnoDB中表的访问效率排行统计情况,一定程度上反应了对存储引擎接口调用的效率。

6rows inset ( 0. 00sec)

23.8 性能框架常用表特性

Performance_schema数据库是小写的,数据库里面的表名也是小写的。查询要使用小写。

很多表在performance_schema数据库是只读的不能被修改。一些setup表的某些列可以被修改。一些也可以被插入和删除。事务可以被允许清理收集的事件,所以truncate
table可以用来清理信息。

Truncate table可以在总结表上使用,但是不能再events_statements_summary_by_digest和内存总结表上使用,效果只是把总计列清理为0.

2.表I/O等待和锁等待事件统计

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

23.9 性能框架表描述

与objects_summary_global_by_type
表统计信息类似,表I/O等待和锁等待事件统计信息更为精细,细分了每个表的增删改查的执行次数,总等待时间,最小、最大、平均等待时间,甚至精细到某个索引的增删改查的等待时间,表IO等待和锁等待事件instruments(wait/io/table/sql/handler和wait/lock/table/sql/handler
)默认开启,在setup_consumers表中无具体的对应配置,默认表IO等待和锁等待事件统计表中就会统计相关事件信息。包含如下几张表:

# events_waits_summary_by_account_by_event_name表

23.9.1 性能框架表索引

具体看:

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

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

23.9.2 性能框架setup表

Setup表提供关于当前收集点启用信息。使用表而不是全局变量提供了更高级别的性能框架配置。比如你可以使用一个sql语句配置多个记录点。

这些setup表示可用的:

·          
Setup_actors:如何初始化后台线程

·          
Setup_consumers:决定哪些信息会被发送和存储。

·          
Setup_instruments:记录点对象,哪些事件要被收集。

·          
Setup_objects:哪些对象要被监控

·          
Setup_timers:当前事件定时器。

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

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

23.9.2.1 setup_actors表

setup_actors表包含了信息决定是否监控或者对新的后台线程进行历史数据记录。这个表默认最多100行,可以通过修改参数performance_schema_setup_actors_size修改大小。

对于新的后台线程,在setup_actors中,性能框架满足的用户和host。如果一个行负荷enabled,histroy列,对应到threads表上的instrumented和history列。如果找不到匹配那么instrumented和history列就为no。

对于后台线程, Instrumented和history默认都是yes,setup_actors默认没有限制。

Setup_actors初始化内容,不过滤任何数据:

mysql>
SELECT
* FROM setup_actors;

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

|
HOST | USER | ROLE | ENABLED | HISTORY |

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

|
%    | %    | %    | YES     | YES     |

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

修改setup_actors表只会影响后台线程,不会影响已经存在的线程。为了影响已经存在的threads表,修改instrumented和history列。

| Tables_in_performance_schema (%table%summary%) |

USER: NULL

23.9.2.2 setup_consumers表

Setup_consumers表列了各个类型的消费者:

mysql>
SELECT
* FROM setup_consumers;

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

|
NAME                             | ENABLED |

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

|
events_stages_current            | NO      |

|
events_stages_history            | NO      |

|
events_stages_history_long       | NO      |

|
events_statements_current        | YES     |

|
events_statements_history        | YES     |

|
events_statements_history_long   | NO      |

|
events_transactions_current      | NO      |

|
events_transactions_history      | NO      |

|
events_transactions_history_long | NO      |

|
events_waits_current             | NO      |

|
events_waits_history             | NO      |

|
events_waits_history_long        | NO      |

|
global_instrumentation           | YES     |

|
thread_instrumentation           | YES     |

|
statements_digest                | YES     |

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

Setup_consumers设置形成从高到低的级别。形成依赖,如果高级别的设置了低级别才会有机会被检查。

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

HOST: NULL

23.9.2.3 setup_instruments表

Setup_consumers表列了所有记录点对象:

mysql> SELECT * FROM setup_instruments;

每个记录点被增加到源代码中,都会在这个表上有一行,即使记录点代码没有被指定。当一个记录点启动了或者执行了,记录点实例就会被创建会显示在*_instrances表。

修改setup_instruments行会马上影响监控。对于一些记录点,修改只会在下次启动才会生效。在指定时修改并不会生效。

| table_io_waits_summary_by_index_usage |#
按照每个索引进行统计的表I/O等待事件

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

23.9.2.4 setup_objects表

Setup_objects表控制了哪些对象的性能框架会被监控。这个对象默认为100行可以通过修改变量来控制,performance_schema_setup_objects_size。

初始化的setup_objects如下:

mysql> SELECT * FROM setup_objects;

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

| OBJECT_TYPE | OBJECT_SCHEMA      | OBJECT_NAME | ENABLED | TIMED |

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

| EVENT       | mysql              | %           | NO      | NO    |

| EVENT       | performance_schema | %           | NO      | NO    |

| EVENT       | information_schema | %           | NO      | NO    |

| EVENT       | %                  | %           | YES     | YES   |

| FUNCTION    | mysql              | %           | NO      | NO    |

| FUNCTION    | performance_schema | %           | NO      | NO    |

| FUNCTION    | information_schema | %           | NO      | NO    |

| FUNCTION    | %                  | %           | YES     | YES   |

| PROCEDURE   | mysql              | %           | NO      | NO    |

| PROCEDURE   | performance_schema | %           | NO      | NO    |

| PROCEDURE   | information_schema | %           | NO      | NO    |

| PROCEDURE   | %                  | %           | YES     | YES   |

| TABLE       | mysql              | %           | NO      | NO    |

| TABLE       | performance_schema | %           | NO      | NO    |

| TABLE       | information_schema | %           | NO      | NO    |

| TABLE       | %                  | %           | YES     | YES   |

| TRIGGER     | mysql              | %           | NO      | NO    |

| TRIGGER     | performance_schema | %           | NO      | NO    |

| TRIGGER     | information_schema | %           | NO      | NO    |

| TRIGGER     | %                  | %           | YES     | YES   |

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

修改setup_objects表会马上影响监控。

对于setup_objects,object_type表示监控了哪些对象类型。如果没有匹配的object_schema,object_name。那么就不会有对象没监控。

| table_io_waits_summary_by_table |#
按照每个表进行统计的表I/O等待事件

COUNT_STAR: 0

23.9.2.5 setup_timers表

Setup_times表如下:

mysql> SELECT * FROM setup_timers;

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

| NAME        | TIMER_NAME  |

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

| idle        | MICROSECOND |

| wait        | CYCLE       |

| stage       | NANOSECOND  |

| statement   | NANOSECOND  |

| transaction | NANOSECOND  |

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

Timer_name是,performance_timers中的一行。表示某个事件类型使用了什么计时器

| table_lock_waits_summary_by_table |#
按照每个表进行统计的表锁等待事件

SUM _TIMER_WAIT: 0

23.9.3 性能框架实例表

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

MIN _TIMER_WAIT: 0

23.9.3.1 cond_instances表

Cond_instance表列出了所有性能框架可以查看的条件。条件是同步机制,用来通知一个指定的事件已经产生完毕。所以一个线程等待这个条件的会马上恢复工作。

当一个线程等待的东西已经变化,条件名值说明线程在等待条件名。

3rows inset ( 0. 00sec)

AVG _TIMER_WAIT: 0

23.9.3.2 file_instances表

当指定文件io记录点的时候,File_instances表列出了所有性能框架能看到的所有文件。如果文件在disk但是没有被打开不会出现在file_instrances中。当文件在次磁盘中被删除,那么file_instances中也会删除。

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

MAX _TIMER_WAIT: 0

23.9.3.3 mutex_instances表

Mutex_instances显示了所有可以被性能框架查看到的信号量。信号量是同步机制用来保护资源。当2个线程运行需要放问相同的资源,2个线程会互相争用,一个线程获取了mutex上的锁,那么另外一个只能等待上一个完成。

当任务执行获取信号量,称为临界区域,区域内执行都是顺序的,可能有潜在瓶颈问题。

表中有3个字段:

Name:记录点的名字

OBJECT_INSTANCE_BEGIN:被记录的信号量在内存中的地址。

LOCKED_BY_THREAD_ID:拥有mutex的线程id,否则为null。

对于每个记录的信号量,性能框架提供一下信息:

·        
Setup_instruments表列出了记录点名,以wait/synch/mutex/为前缀。

·         当有代码创建了信号量,那么就有一行被加入到mutex_instrances表中,OBJECT_INSTANCE_BEGIN列是mutex的唯一列。

·         当一个线程视图锁定信号量,events_waits_current表为线程显示一行,说明在等待信号量,通过object_instance_begin。

·         当线程成功锁定了一个信号量:

§ 
Events_waits_current,显示等待信号量就会完成

§  完成的事件会被添加到历史表中

§ 
Mutex_instances显示信号量现在属于一个thread

·         当thread unlock一个信号量,mutex_instances显示信号量现在没有owner,thread_id为null。

·         当信号量对象被销毁,对应的行也会被删除。

查以下2个表,可以诊断瓶颈或者死锁:

§ 
Events_waits_current,查看线程等待的信号量。

§ 
Mutex_instrances,查看其它线程的所有的信号量。

# table_io_waits_summary_by_index_usage表

1 row in set (0.00 sec)

23.9.3.4 Rwlock_instances表

Rwlock_instances表列出了所有rwlock的实例。Rwlock是同步机制用来强制在一定规则下,在给定的事件里面能访问一些资源。这些资源被rwlock保护。访问要不是共享方式要不是排他方式,如果允许非一致性访问,还可以共享排他方式访问。Sxlock只有在,mysql 5.7之后才能被使用,用来优化并发性。

根据访问的需求,所的请求要不是,共享,排他,共享排他或者不授权,等待其他线程完成。

表列如下:

·          
NAME:记录点名相关的lock

·          
OBJECT_INSTANCE_BEGIN:被记录的锁在内存中的地址。

·          
WRITE_LOCKED_BY_THREAD_ID:当一个线程有一个rwlock,排他模式,WRITE_LOCKED_BY_THREAD_ID,就是锁定线程的thread_id。

·          
READ_LOCKED_BY_COUNT:当线程当前有一个rwlock共享模式,那么read_locked_by_count增加1。只是个计数,所以找不到那个线程拥有了读锁,但是可以用来查看是否有读锁,有多少读是活动的。

通过执行查询一下表,何以知道瓶颈和死锁:

·          
Events_waits_current,查看等待哪些rwlock

·          
Rwlock_instrances,查看其它线程是否拥有这个锁。

只能知道那个线程有了write lock但是不知道哪个线程有read lock。

admin@localhost : performance _schema 01:55:49> select * from
table_io _waits_summary _by_index _usage where
SUM_TIMER_WAIT!=0G;

# events_waits_summary_by_host_by_event_name表

23.9.3.5 socket_instance表

Socket_instancees表提供了一个实时的连接活动快照。每个tcp/ip连接有一行,或者每个unix socket file连接有一行。

mysql>
SELECT
* FROM socket_instancesG

***************************

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

          
EVENT_NAME: wait/io/socket/sql/server_unix_socket

OBJECT_INSTANCE_BEGIN:
4316619408

           
THREAD_ID: 1

   
        SOCKET_ID: 16

                  
IP:

                
PORT: 0

               
STATE: ACTIVE

***************************

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

          
EVENT_NAME: wait/io/socket/sql/client_connection

OBJECT_INSTANCE_BEGIN:
4316644608

           
THREAD_ID: 21

           
SOCKET_ID: 39

                  
IP: 127.0.0.1

                
PORT: 55233

               
STATE: ACTIVE

***************************

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

          
EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

OBJECT_INSTANCE_BEGIN:
4316699040

           
THREAD_ID: 1

           
SOCKET_ID: 14

                  
IP: 0.0.0.0

                
PORT: 50603

               
STATE: ACTIVE

socket记录点名字格式,wait/io/socket/sql/socket_type:

1.服务有一个监听socket,记录点那么socket_type的值为server_tcpip_socket或者server_unix_socket``。

2.      当有一个监听socket发现一个连接,那么服务会转化到一个新的socket来管理,server_type类型为client_connection。

3.      当一个连接中断,那么行会在socket_instances中删除。

Socket_instances表类如下:

·          
EVENT_NAME: wait/io/socket/*,具体的名字来至于setup_instruments表

·          
OBJECT_INSTANCE_BEGIN:socket的唯一标记,值为对象在内存中的值。

·          
THREAD_ID:内部线程表示。每个socket由线程管理,所以每个socket被映射到一个线程。

·          
SOCKET_ID:socket内部的分配的文件句柄

·           IP:客户端ip地址

·          
PORT:客户端端口地址

·          
STATE:socket状态要不是idle要不是active。如果线程等待client的请求,那么状态就是idle。当socket变成idle,表中的STATE也会变成IDLE,socket的记录点中断。当请求出现idle中断,变成ACTIVE。Socket的记录点timing恢复。

IP:PORT组合来表示一个有效的连接。组合值被用于events_waits_xxx表的object_name,来标记连接来至于哪里:

·           来至于unix域监听socket,端口是0,ip为‘’

·           对于通过unix域监听的socket,端口是0,ip为‘’

·           对于tcp/ip的监听,端口是服务的端口,默认为3306,ip为0.0.0.0

·           对于通过tcp/ip连接的客户端接口,端口不为0,ip是客户端的ip。

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

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

23.9.4 性能框架事件等待表

事件等待表有3个:

·          
Events_waits_current:当前事件等待表

·          
Events_waits_history:历史等待历史表,最近的等待事件表

·          
Events_waits_history_long:很多事件等待历史的表。

等待历史配置

为了收集等待事件,启动相应的记录点和消费者。

mysql>
SELECT
* FROM setup_instruments

   
-> WHERE
NAME LIKE ‘wait/io/file/innodb%’;

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

|
NAME                                 | ENABLED | TIMED |

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

|
wait/io/file/innodb/innodb_data_file | YES     | YES   |

|
wait/io/file/innodb/innodb_log_file  | YES     | YES   |

|
wait/io/file/innodb/innodb_temp_file | YES     | YES   |

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

mysql>
SELECT
* FROM setup_instruments WHERE

   
-> NAME
LIKE ‘wait/io/socket/%’;

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

|
NAME                                   | ENABLED | TIMED |

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

|
wait/io/socket/sql/server_tcpip_socket | NO      | NO    |

|
wait/io/socket/sql/server_unix_socket  | NO      | NO    |

|
wait/io/socket/sql/client_connection   | NO      | NO    |

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

修改enabled和timing列:

mysql>
UPDATE
setup_instruments SET ENABLED = ‘YES’, TIMED = ‘YES’

   
-> WHERE
NAME LIKE ‘wait/io/socket/sql/%’;

Setup_consumers包含消费者对应到刚刚的事件表。这些消费者用来过滤等待事件的收集,默认被禁用:

mysql>
SELECT
* FROM setup_consumers WHERE NAME LIKE ‘%waits%’;

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

|
NAME                      | ENABLED |

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

|
events_waits_current      | NO      |

|
events_waits_history      | NO      |

|
events_waits_history_long | NO      |

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

启动所有的等待事件:

mysql>
UPDATE
setup_consumers SET ENABLED = ‘YES’

   
-> WHERE
NAME LIKE ‘%waits%’;

Setup_timers表包含了一行name为wait,表示等待事件的定时的单位,默认是cycle:

mysql>
SELECT
* FROM setup_timers WHERE NAME = ‘wait’;

+——+————+

|
NAME | TIMER_NAME |

+——+————+

|
wait | CYCLE      |

+——+————+

修改定时单位时间:

mysql>
UPDATE
setup_timers SET TIMER_NAME = ‘NANOSECOND’

   
-> WHERE
NAME = ‘wait’;

OBJECT_TYPE: TABLE

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

23.9.4.1 events_waits_current表

Events_waits_current表包含了当前的等待时间,每个thread都有一行显示当前thread的等待时间。Events_waits_current表可以使用truncate table。

Events_waits_current表列:

·        
THREAD_ID,EVENT_ID
线程相关的事件和线程当前事件号。这2个字段形成主键来标示一行。

·        
END_EVENT_ID
当事件启动,这个列为null,如果时间结束分配一个事件号。

·        
EVENT_NAME
生成事件的记录点名。

·         SOURCE
源代码文件名包含产生事件的记录点代码位置。可以帮助用来检查源代码。

·        
TIMER_START,TIMER_END,TIMER_WAIT
事件的timing信息。时间单位为皮秒。TIMER_START,TIMER_END表示事件的开始和结束。TIMER_WAIT是事件的持续时间。如果事件没有完成TIMER_END,TIMER_WAIT为null。如果记录点的timed=no那么这3个列都是null。

·         SPINS
对于信号量,是只自旋次数。如果为null,表示代码不使用自旋或者自旋没有被记录。

·        
OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE_OBJECT_INSTANCE_BEGIN
这些列表示对象被启动的位置,根据对象类型不同意义不同:
对于同步对象:(cond,mutex,rwlock)

§ 
OBJECT_SCHEMA,OBJECT_NAME,OBJECT_TYPE为null

§ 
OBJECT_INSTANCE_BEGIN为同步对象在内存中的地址。

对于文件io对象

§ 
OBJECT_SCHEMA为null

§  OBJECT_NAME为文件名

§  OBJECT_TYPE为file

§ 
OBJECT_INSTANCE_BEGIN为内存地址

对于socket对象

§  OBJECT_NAME为IP:PORT

§ 
OBJECT_INSTANCE_BEGIN为内存地址

对于表io对象

§ 
OBJECT_SCHEMA是表所在schema的名字

§  OBJECT_NAME表名

§  OBJECT_TYPE为table或者temporary table

§ 
OBJECT_INSTANCE_BEGIN是内存地址

OBJECT_INSTANCE_BEGIN本身是没有意义的,除非不同的值表示不同的对象。OBJECT_INSTANCE_BEGIN可以用来调试。比如group by这个字段查看是否有1000个信号量,造成一点瓶颈。

·        
INDEX_NAME
使用的index名字,primary表示表的主键索引,null表示没有索引

·        
NESTING_EVENT_ID
event_id表示那个event被嵌套

·        
NESTING_EVENT_TYPE
嵌套的事件培训,可能是以下一种,TRANSACTION,STATEMENT,STAGE,WAIT

·        
OPERATION
执行操作的类型,lock,read,write中一个。

·        
NUMBER_OF_BYTES
读写操作的字节个数。对于表io等待,MySQL 5.7.5之前值为null,之后为行数。如果值大于1,是批量io操作。MySQL执行join是nested-loop机制。性能框架可以提供行数和每个表执行join准确的时间。假设一个join查询,执行如下:

SELECT
… FROM t1 JOIN t2 ON … JOIN t3 ON …

在join操作的时候表的表行的增加减少(扇出)。如果t3的扇出大于1,那么大多数行获取操作就来自于这个表。假设t1 10行,t2 20行对应到t1一行,t3 30行对应t2 1行。那么一共会有被记录的操作是:

10 +
(10 * 20) + (10 * 20 * 30) = 6210

为了减少被记录操作,可以通过每次扫描实现聚合的方式(聚合t1,t2的唯一值)。记录点计数减少为:

10 +
(10 * 20) + (10 * 20) = 410

对于上面的情况使用环境:

§  查询访问的表基本上都是inner join的

§  查询执行不需要表内的单个记录

§  查询执行不需要评估子查询访问了表。

·         FLAGS
保留

OBJECT_SCHEMA: xiaoboluo

HOST: NULL

23.9.4.2 Events_waits_history表

Events_waits_history表每个线程包含了最近N条数据。表结构和events_waits_current一行,也可以被truncate table,N是服务启动自动设置的,也可以从参数设置:
performance_schema_events_waits_history_size。

OBJECT_NAME: test

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

23.9.4.3 events_waits_history_long 表

Events_waits_history_long表每个线程包含了最近N条数据。表结构和events_waits_current一行,也可以被truncate table,N是服务启动自动设置的,也可以从参数设置:
performance_schema_events_waits_history_long_size。

INDEX_NAME: PRIMARY

COUNT_STAR: 0

23.9.5 性能框架Stage事件表

性能框架stage记录,是语句执行的阶段,比如解析语句,打开表或者执行filesort操作。Stage关联到的了show
processlist中的线程状态。

因为事件等级,等待事件穿插在stage事件,stage事件穿插在语句事件,事务事件。

Stage事件配置

启动stage事件的收集,启动相应的记录点和消费者。

Setup_instruments表包含以stage开头的记录点名。这些记录点除了语句处理的信息,默认是禁用的:

mysql>
SELECT
* FROM setup_instruments WHERE NAME RLIKE
‘stage/sql/[a-c]’;

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

|
NAME                                               | ENABLED | TIMED
|

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

|
stage/sql/After create                             | NO      | NO   
|

|
stage/sql/allocating local table                   | NO      | NO   
|

|
stage/sql/altering table                           | NO      | NO   
|

|
stage/sql/committing alter table to storage engine | NO      | NO   
|

|
stage/sql/Changing master                          | NO      | NO   
|

|
stage/sql/Checking master version                  | NO      | NO   
|

|
stage/sql/checking permissions                     | NO      | NO   
|

|
stage/sql/checking privileges on cached query      | NO      | NO   
|

|
stage/sql/checking query cache for query           | NO      | NO   
|

|
stage/sql/cleaning up                              | NO      | NO   
|

|
stage/sql/closing tables                           | NO      | NO   
|

|
stage/sql/Connecting to master                     | NO      | NO   
|

|
stage/sql/converting HEAP to MyISAM                | NO      | NO   
|

|
stage/sql/Copying to group table                   | NO      | NO   
|

|
stage/sql/Copying to tmp table                     | NO      | NO   
|

|
stage/sql/copy to tmp table                        | NO      | NO   
|

|
stage/sql/Creating sort index                      | NO      | NO   
|

|
stage/sql/creating table                           | NO      | NO   
|

|
stage/sql/Creating tmp table                       | NO      | NO   
|

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

修改stage事件,修改enabled和timing列:

mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'

    -> WHERE NAME = 'stage/sql/altering table';

Setup_consumers表包含消费者只关联的事件表名。消费者可能用来过滤收集器stage事件。Stage消费者默认禁用:

mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%stages%';

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

| NAME                       | ENABLED |

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

| events_stages_current      | NO      |

| events_stages_history      | NO      |

| events_stages_history_long | NO      |

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

启动所有的stage事件:

mysql> UPDATE setup_consumers SET ENABLED = 'YES'

    -> WHERE NAME LIKE '%stages%';

Setup_timers包含name=‘stage’,说明stage事件timing:

mysql> SELECT * FROM setup_timers WHERE NAME = 'stage';

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

| NAME  | TIMER_NAME |

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

| stage | NANOSECOND |

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

修改timing值:

mysql>
UPDATE
setup_timers SET TIMER_NAME = ‘MICROSECOND’

   
-> WHERE
NAME = ‘stage’;

Stage事件进程信息

MySQL 5.7.5,性能架构stage事件表包含2列,每行提供stage进程标示:

·          
WORK_COMPLETED:stage工作单元完成个数。

·          
WORK_ESTIMATED:预期的stage工作单元完成个数。

如果没有进度信息,每列都是null。性能框架提供一个容器来存放这些进度数据:

·           工作单元,是一个量,随着执行时间的增加变大。

·          
WORK_COMPLETED,一个或者多个单元增加一次,依赖于被记录代码

·          
WORK_ESTIMATED,可以在stage司改,根据,被记录代码。

对于stage事件的进度的记录可以实现以下任何行为:

·           没有进度记录点
这个是最常出现的,因为没有进度数据被提供,WORK_COMPLETED和WORKESTIMATED都为bull

·           没有被绑定记录点
只有WORK_COMPLETED列有意义,WORK_ESTIMATED列没有值,显示为0。
打开events_stages_current表监控回话,监控程序可以报告有多少work已经被执行,但是不知道什么时候可以结束,因为记录点没有提供。

·           绑定进度记录点
WORK_COMPLETED和WORK_ESTIMATED列都是有意义的。
进度标识符的类型适合于已经定义了完成临界的操作,比如表复制记录点。通过查询events_stages_current表来监控会话,监控程序可以监控所有完成比例的stage,通过计算WORK_COMPLETED / WORK_ESTIMATED的比率。

stage/sql/copy to tmp table演示,进度标识符如何工作。在执行alter table语句,这个记录点就很有用,并且会执行很长一段时间。

COUNT_STAR: 1

SUM _TIMER_WAIT: 0

23.9.5.1 events_stages_current表

Events_stages_current表包含当前stage事件,每行一个线程线程当前状态监控到的stage事件。

Events_stages_current表可以truncate
table。

表events_stages_current是events_stages_history和events_stages_history_long的基础。

Events_Stages_current列:

·        
THREAD_ID,EVENT_ID
线程相关的事件和线程当前事件号。这2个字段形成主键来标示一行。

·        
END_EVENT_ID
当事件启动,这个列为null,如果时间结束分配一个事件号。

·        
EVENT_NAME
生成事件的记录点名。

·         SOURCE
源代码文件名包含产生事件的记录点代码位置。可以帮助用来检查源代码。

·        
TIMER_START,TIMER_END,TIMER_WAIT
事件的timing信息。时间单位为皮秒。TIMER_START,TIMER_END表示事件的开始和结束。TIMER_WAIT是事件的持续时间。如果事件没有完成TIMER_END,TIMER_WAIT为null。如果记录点的timed=no那么这3个列都是null。

·        
WORK_COMPLETED,WORK_ESTIMATED
这些列提供了stage进度信息,对于记录点已经用来生成这些信息。WORK_COMPLETED表示有多少工作单元已经被完成,WORK_ESTIMATED表示有多少工作单元预计的stage。

·        
NESTING_EVENT_ID
EVENT_ID nested生成的事件。嵌套的event的stage事件通常是语句事件。

·        
NESTING_EVENT_TYPE
嵌套事件类型,TRANSACTION,STATEMENT,STAGE,WAIT其中一个。

SUM _TIMER_WAIT: 56688392

MIN _TIMER_WAIT: 0

23.9.5.2 events_stage_history表

Events_stages_history为每个线程保留了N个记录,具体可以通过配置参数修改:

performance_schema_events_stages_history_size

MIN _TIMER_WAIT: 56688392

AVG _TIMER_WAIT: 0

23.9.5.3 events_stage_history_long表

Events_stages_history_long为每个线程保留了N个记录,具体可以通过配置参数修改:

performance_schema_events_stages_history_long_size

AVG _TIMER_WAIT: 56688392

MAX _TIMER_WAIT: 0

23.9.6 性能框架语句事件表

性能框架记录点语句执行。语句事件发生在高级别的事件,等待事件嵌套在stage事件中,stage事件嵌套在语句事件中,语句事件嵌套在事务事件中。

语句事件配置

Setup_instruments表包含记录点,以statement前缀的记录点。这些记录点的默认值可以使用语句:

mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'statement/%';

可以通过以下语句修改:

mysql> UPDATE setup_instruments SET ENABLED = 'NO'

    -> WHERE NAME LIKE 'statement/com/%';

查看和修改timer:

mysql>
SELECT
* FROM setup_timers WHERE NAME = ‘statement’;

+———–+————+

|
NAME      | TIMER_NAME |

+———–+————+

|
statement | NANOSECOND |

+———–+————+

修改timer:

mysql>
UPDATE
setup_timers SET TIMER_NAME = ‘MICROSECOND’

   
-> WHERE
NAME = ‘statement’;

 

语句监视

语句监视开始于被请求的活动到所有活动停止。也就是服务受到客户端的第一个包,到完成返回响应。在MySQL
5.7.2之前,语句只会是高级别的,比如在存储过程或者子查询不会被分离出来。

最终记录点名和服务命令和sql语句有关:

·           关联到COM_xxx定义在mysql_com.h头文件和在sql/sql_parse.cc中处理,比如COM_PING和COM_QUIT,那么记录点名以statement/com开头,比如statement/com/ping和statement/com/ping。

·           SQL语句是用文本表示的。那么相关的命令行以statement/sql开头,比如statement/sql/delete和statement/sql/select。

一些记录点名表示特殊的错误处理:

·          
Statement/com/error,记录了服务收集到的未绑定的信息。无法判断从客户端发送到服务端的命令。

·          
Statement/sql/error,记录了sql语句分析错误。用来诊断查询发送到客户端的异常。一个查询分析错误和查询执行错误不同

请求可以通过以下渠道获得:

·           一个命令或者语句从客户端获取并发送

·           在replication slave,语句字符串从relay log读取。

·           从event scheduler获取事件。

请求的详细原来是不知道的,并且性能框架从请求的顺序获取特定的记录点名。

从客户端收集的请求:

1.        当服务发现一个新的包在socket级别,一个新的的语句以抽象的记录点名statement/abstract/new_packet开始。

2.        当服务读取包序号,获取接受的请求类型,性能框架获取记录点名。比如,请求是COM_PING包,那么记录点名会变成statement/com/ping。如果请求是COM_QUERY包,知道是一个sql语句,但是不知道具体的类型。这个时候会给一个抽象的记录点名statement/abstract/query。

3.        如果请求的语句,文本已经读入到分析器。分析之后,那么准确的语句类型已经知道了,如果请求是一个插入语句,性能框架会重新定位记录点名statement/abstract/Query
to statement/sql/insert。

 

对于从复制的relay log上读取语句:

1.        语句在relay log中是以文本存储的。没有网络协议,所以statement/abstract
/new_packet不会被使用,而是使用statement/abstract/realy_log。

2.        当语句被解析,准确的语句类型被得知。比如insert语句,那么性能框架会重新查找记录点名,statement/abstract/Query
to statement/sql/insert。

上面介绍的,只是基于语句的复制,对于基于行的复制,订阅表行处理可以被记录,但是relay
log中的行事件描述语句的并不会出现。

 

对于从事件调度器来的请求:

事件执行的记录点名为statement/scheduler/event。

事件体重的事件执行记录点名使用statement/sql/*,不适用其他抽象记录点名。事件是一个存储过程,并且存储过程是预编译在内存中的。那么在执行时就不会有解析,但是类型在执行时就知道了。

在事件体内的语句都是子句。比如一个事件执行了一个insert语句,执行的事件是上级。记录点使用statement/scheduler/event,并且insert是下级,使用statement/sql/insert记录点。

这样不单单是要启动statement/sql/*记录点,还要启动statement/abstract/*记录点。

在之前的5.7版本的,抽象记录点名用其他记录点代替的:

·          
Statement/abstract/new_packet之前为statement/com/

·          
Statement/abstract/query之前为statement/com/Query

·          
Statement/abstract/relay_log之前为statement/rpl/relay_log

MAX _TIMER_WAIT: 56688392

1 row in set (0.00 sec)

23.9.7 性能框架事务表

性能框架事务记录点。在事件级别,等待事件嵌套stage事件,stage事件嵌套语句事件,语句事件嵌套事务事件。

 

事务事件配置

Setup_instruments包含的transaction的记录点:

mysql>
SELECT
* FROM setup_instruments WHERE NAME = ‘transaction’;

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

|
NAME        | ENABLED | TIMED |

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

|
transaction | NO      | NO    |

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

启动收集事务事件:

mysql>
UPDATE
setup_instruments SET ENABLED = ‘YES’, TIMED = ‘YES’

   
-> WHERE
NAME = ‘transaction’;

Setup_consumers表包含transaction的消费者:

mysql>
SELECT
* FROM setup_consumers WHERE NAME LIKE ‘%transactions%’;

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

|
NAME                             | ENABLED |

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

|
events_transactions_current      | NO      |

|
events_transactions_history      | NO      |

|
events_transactions_history_long | NO      |

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

启动消费者:

mysql>
UPDATE
setup_consumers SET ENABLED = ‘YES’

   
-> WHERE
NAME LIKE ‘%transactions%’;

设置相关记录点:

mysql>
SELECT
* FROM setup_timers WHERE NAME = ‘transaction’;

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

|
NAME        | TIMER_NAME |

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

|
transaction | NANOSECOND |

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

修改timer_name的值:

mysql>
UPDATE
setup_timers SET TIMER_NAME = ‘MICROSECOND’

   
-> WHERE
NAME = ‘transaction’;

 

事务绑定

在MySQL Server,使用以下语句显示启动事务:

START
TRANSACTION | BEGIN | XA START | XA BEGIN

事务也可以隐式启动,当autocommit系统变量启动。当autocommit禁用,在启动新事务钱要显示的结束上面一个事务。

COMMIT
| ROLLBACK | XA COMMIT | XA ROLLBACK

执行DDL语句,事务会隐式提交

性能框架定义的事务绑定和服务的很相似。事务的启动和解释也和服务的事务状态匹配:

·           对于显示启动的事务,事务events在start transaction后启动。

·           对于隐式启动的事务,事务事件在第一个语句执行的时候启动。

·           对于任何事务,当执行commit,rollback事务结束。

微妙的不同点:

·           性能框架中的事务事件,没有完全包含语句事件比如START
TRANSACTION,COMMIT,ROLLBACK语句。

·           语句如果运行在非实物引擎,那么连接的事务状态不会影响。

 

事务记录点

3个定义的事务属性:

·           访问模式(read only,read write)

·           隔离级别

·           隐式或者显示

为了减少事务记录点并且保证收集事务数据是完成的,有意义的结果,所有事务都有访问模式,隔离级别,自动提交模式。

事务事件表使用3列来ACCESS_MODE,ISOLATION_LEVEL,AUTOCOMMIT记录。

事务记录点消费可以有很多种方式减少,比如根据用户,账号,host,thread启动或者禁用事务减了点。

 

线程和嵌套事件

事务事件的上级事件是初始化事务的事件。对于显示事务启动,包含START_TRANSACTION和commit and china,如果是隐式事务,第一个语句启动事务。

显示的结束事务,COMMIT,ROLLBACK,或者DDL语句,隐式的提交事务。

 

事务和存储过程

事务和存储过程事件关联如下:

·           存储过程
存储过程操作独立的事务,一个存储过程可以启动一个事务,并且一个事务可以在存储过程中启动和结束。如果在一个事务中调用,一个存储过程可以语句强制提交事务并且启动一个新的事务。

·           存储函数
存储函数可以限制显示或者隐式的事务提交和回滚。

·           触发器
触发器活动是语句的活动访问相关的表,所以触发器事件的上级事件激活它。

·           调度事件
事件体的语句调度事件发生一个新连接。

 

事务和savepoint

Savepoint语句以独立的语句事件被记录。语句事件包括SAVEPOINT,ROLLBACK
TO SAVEPOINT和RELEASE SAVEPOINT语句。

 

事务和错误 事务中的错误和警告被记录在语句事件中,但是不在相关的事务事件。

COUNT_READ: 1

# events_waits_summary_by_instance表

23.9.8 性能框架连接表

性能框架提供了连接的统计信息。当客户端连接,在一个特定的用户名和host下。性能框架为每个账号跟踪连接。

·        
Accounts:每个客户端账号的连接统计信息。

·         Hosts:每个客户端hostname 的连接统计信息。

·         Users:每个客户端用户名的连接统计信息。

账号这里的意思是用户加上host。连接表有CURRENT_CONNECTIONS和TOTAL_CONNECTIONS列跟踪所有的连接。Accounts表有USER和HOST列跟踪用户和host。Users和hosts表有USER和HOST列,跟踪用户或者host。

假设客户端名user1,user2从hosta,hostb连接过来。性能框架跟踪连接入选:

·        
Accounts会有4条记录,user1/hosta,user1/hostb,user2/hosta,user2/host2.

·         Users表有2条记录,user1,user2

·         Host表有2条记录,hosta,hostb

当客户端连接,连接表中如果不存在这样的用户或者host,那么就增加一行否则就修改CURRENT_CONNECTIONS和TOTAL_CONNECTIONS列。

当客户端断开连接,性能框架减少current_connecitons列。

性能框架也计数内部线程和用户会话线程验证错误。对应的user和host为null。

每个连接表都可以truncate:

·         行如果是CURRENT_CONNECTIONS=0的就删除

·         如果>0,TOTAL_CONNECTIONS设置为CURRENT_CONNECTIONS。

·         连接合计表依赖于连接表的值会被设为0.

SUM _TIMER_READ: 56688392

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

23.9.9 性能框架连接属性表

具体看:

MIN _TIMER_READ: 56688392

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

23.9.10 性能框架用户变量表

具体看:

AVG _TIMER_READ: 56688392

EVENT_NAME: wait/synch/mutex/mysys/THR_LOCK_heap

23.9.11 性能框架复制表

MySQL 5.7.2,性能框架提供了关于复制信息的表。和show slave
status的信息类似:

·         Show slave
status输出可以阅读进行检查,但是不能用来编程使用。

·         查询结果可以保存到表中,用于分析,设置变量,或者在存储过程上使用。

·         复制表提供了更好的诊断信息,对于多线程slave操作,show slave status使用last_SQL_Errorno和last_sql_error字段报告所有的协调器和工作线程的错误。所以只有最近的错误才能可见。复制表会为每个线程上的错误保存信息不会丢失。

·         每个工作线程的最新的事务在在复制表是可见的。但是show_slave_status。不可见。

·         开发熟悉的性能框架接口可以扩展复制表提供更多的信息。

复制表描述

性能框架提供一下和复制有关的表:

·         关于Slave连接到master的连接信息表:

§ 
Replication_connection_configuration:配置连接到master的参数。

§ 
Replication_connection_status:当前连接到master的状态。

·         关于slave事务应用的表

§ 
replication_applier_configuration:slave中事务应用的配置信息。

§ 
replication_applier_status:当前事务应用的状态。

·         关于指定线程应用从master获取事务并执行的信息:

§ 
Replication_applier_status_by_coordinator:applier线程状态,之前叫replication_execute_status_by_coordinator。对于有多个work thread的复制有多个work thread和一个协调线程,对于单线程的这个表为空。

§ 
Replication_applier_status_by_worker:工作线程应用状态。同上单线程复制表为空。

·         包含复制组成员信息的表:

§ 
Replication_group_members:提供网络和组成员状态。

§ 
Replication_group_member_status:提供组成员的统计信息和参与的事务。

复制表生命周期

性能框架在以下状态下写入复制表:

·           在执行change master to之前表为空。

·           在执行change master to之后。配置阐述可以在表上发现。如果这个时候没有活动的slave
线程,那么thread_id列为null,serivce_state的状态为off。

·           Start
slave之后,没有thread_id字段不为空。线程为空闲或者活动service_status状态为on。线程连接到master
server,如果连接建立有个connecting值。

·           Stop
slave之后,thread_id为null,并且service_State列值为off。

·           Stop
slave或者thread碰到错误,表信息会被保留。

·          
Replication_applier_Status_by_worker表只有当slave操作在多线程模式下为非空。如果slave_parallel_workers变量大于0,那么start
slave之后,行数和线程个数一样多。

SHOW SLAVE STATUS不再复制表中的信息

Show slave status的信息和复制表中的信息不同,因为这些表主要是面向GTID的复制。不是基于文件名和位置:

·           以下字段关于文件名和位置的没有保存:

Master_Log_File

Read_Master_Log_Pos

Relay_Log_File

Relay_Log_Pos

Relay_Master_Log_File

Exec_Master_Log_Pos

Until_Condition

Until_Log_File

Until_Log_Pos

·          
Master_info_file字段没有保存。参照master.info文件。

·           以下字段基于server_id,不是server_uuid,没有被保存:

Master_Server_Id

Replicate_Ignore_Server_Ids

·          
Skip_counter列基于事件个数,不是gtid没有被保存。

·           错误列是last_sql_errno,last_sql_error的别名,因此不被保存

Last_Errno

Last_Error

在性能框架中,replication_applier_status_by_coodinator和表replication _applier_status_by_worker中的last_error_number和last_error_message列保存了错误信息。

·           命令行过滤操作的信息不被保存:

Replicate_Do_DB

Replicate_Ignore_DB

Replicate_Do_Table

Replicate_Ignore_Table

Replicate_Wild_Do_Table

Replicate_Wild_Ignore_Table

·          
Slave_io_State和slave_sql_running_state列没有保存。如果需要可以通过thread_id关联上perocesslist表获取表中的status值。

·          
Executed_gtid_set字段可以显示大量的文字。和性能框架表中显示已经被slave应用的事务的GTID。已经被执行的GTID可以通过gtid_executed系统变量获取。

·          
Seconds_behind_master和relay_log_spae用来将要被决定的状态不保留。

状态变量移动到了复制表

从mysql 5.7.5,以下状态被移动到了性能框架复制表:

Slave_retried_transactions

Slave_last_heartbeat

Slave_received_heartbeats

Slave_heartbeat_period

Slave_running

这些变量用于单源复制,因为只能汇报默认源复制。当有多个复制源,可以使用性能复制表,汇报每个复制渠道的状态。

多源复制

性能框架表的第一列是channel_name.可以看到每个复制源。

MAX _TIMER_READ: 56688392

OBJECT _INSTANCE_BEGIN: 32492032

23.9.11.1 replication_connection_configure表

表显示了连接到slave服务的连接配置。参数被保存在表中,在change
master执行的时候会被修改。

replication_connection_configuration表包含以下列:

·          
CHANNEL_NAME:复制源名。

·          
HOST:master的host名。

·          
PORT:master的端口

·          
USER:连接用户

·          
NETWORK_INTERFACE:slave绑定的network接口。

·          
AUTO_POSITION:如果自定定位被使用了就是1,否则是0

·          
SSL_ALLOWED, SSL_CA_FILE, SSL_CA_PATH,
SSL_CERTIFICATE, SSL_CIPHER, SSL_KEY,
SSL_VERIFY_SERVER_CERTIFICATE, SSL_CRL_FILE, SSL_CRL_PATH
这些列显示了slave连接到master的SSL的参数SSL_ALLOWED的值如下:

§   Yes,如果SSL连接到master被允许。

§   No,如果SSL连接到master不被允许。

§   Ignored,如果SSL被允许,但是slave不支持SSL。

Change master to选项还有其他ssl选项:MASTER_SSL_CA, MASTER_SSL_CAPATH,
MASTER_SSL_CERT, MASTER_SSL_CIPHER, MASTER_SSL_CRL,
MASTER_SSL_CRLPATH, MASTER_SSL_KEY,
MASTER_SSL_VERIFY_SERVER_CERT。

·          
CONNECTION_RETRY_INTERVAL:重试的秒数。

·          
CONNECTION_RETRY_COUNT:失误连接之后重试的次数。

·          
HEARTBEAT_INTERVAL:复制心跳间隔。

……

COUNT_STAR: 0

23.9.11.2 replication_connection_status

表保存了io线程的状态,io线程连接到master服务获取binary log信息。

Replication_connection_status相关列:

·          
CHANNEL_NAME:来源名。

·          
GOURP_NAME:保留

·          
SOURCE_UUID:master的server_uuid

·          
THREAD_ID:io 线程id

·          
SERVICE_STATE:服务状态

·          
RECEIVED_TRANSACTION_SET:GTID集合反应已经被slave收到的GTID。

·          
LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE:错误好和错误信息。

·          
LAST_ERROR_TIMESTAMP:错误的事件格式为YYMMDD HH:MM:SS。

·          
LAST_HEARTBEAT_TIMESTAMP:最近一次心跳事件的事件。

·          
COUNT_RECEIVED_HEARTBEATS:收到的心跳次数。

1 row in set (0.00 sec)

SUM _TIMER_WAIT: 0

23.9.11.3 replication_applier_configure

这个表显示了影响事务应用的配置参数。参数保存在表可以通过change
master to修改。

Replication_applier_configure表有以下列:

·          
CHANNEL_NAME:复制来源名。

·          
DIESIRED_DELAY:master到slave的延迟。

# table_io_waits_summary_by_table表

MIN _TIMER_WAIT: 0

23.9.11.4 replication_applier_status

表保存了slave通常事务执行的状态。

replication_aplier_status列名:

·          
CHANNEL_NAME:复制来源名。

·          
SERVICE_STATE:显示on表示复制渠道活动或者空闲,如果为off表示应用线程没有活动。

·          
REMAINING_DELAY:如果slave等待DESIRED_DELAY直到master应用事件。列显示剩下的秒数。

·          
COUNT_TRANSACTIONS_RETRIES:显示了sql thread应用事务错误,导致重试的次数。

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

AVG _TIMER_WAIT: 0

23.9.11.5 replication_applier_status_by_coordinator

对于多线程的slave,slave使用多个工作线程和一个协调线程,协调线程用来管理工作线程,表显示了协调线程的状态。如果是单线程slave,表为空。

Replication_applier_status_by_coordinator列:

·          
CHANNEL_NAME:复制来源名。

·          
THREAD_ID:SQL/协调线程id。

·          
LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE:最后一次错误号和错误信息。

·          
LAST_ERROR_TIMESTRAMP:时间戳格式为YYMMDD HH:MM:SS。

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

MAX _TIMER_WAIT: 0

23.9.11.6 replication_applier_statys_by_worker

对于多线程的slave,slave使用多个工作线程和一个协调线程,协调线程用来管理工作线程,表显示了协调线程的状态。如果是单线程slave,表为空。

Replication_applier_status_by_worker:

·          
CHANNEL_NAME:复制来源名。

·          
WORKER_ID:worker标识符。Stop
slave之后线程id会变成null,workerid会保留。

·          
THREAD_ID:线程id

·          
SERVICE_STATE:on,表示活动或者空闲,off表示不存在。

·           表示worker发现的最新的事务,如果gtid_mode=off列的值为ANONYMOUS。如果为on:

§   如果没有事务被执行,那么就是空。

§   当有一个事务被执行了列设置成gtid_next。

§   GTID会被保留,知道下一个事务运行完成。

§   当下一个GTID被其他线程获取,从gtid_next上获得。

·          
LAST_ERROR_NUMBER,LAST_ERROR_MESSAGE:最后一次错误号和错误信息。

·          
LAST_ERROR_TIMESTRAMP:时间戳格式为YYMMDD HH:MM:SS。

OBJECT_TYPE: TABLE

1 row in set (0.00 sec)

23.9.11.7 replication_group_members

表保存了网络和复制成员组的状态信息。Replication_group_members列:

·          
CHANNEL_NAME:复制来源名。

·          
MEMBER_ID:member标示,和uuid一样。

·          
MEMBER_HOST:host地址或者主机名。

·          
MEMBER_PORT:端口。

·          
MEMBER_STATE:

§   OFFLINE:group replication插件已经安装但是没有启动。

§   RECOVERING:服务已经加入到一个group,正在获取数据。

§   ONLINE:成员在全功能状态。

OBJECT_SCHEMA: xiaoboluo

# events_waits_summary_by_thread_by_event_name表

23.9.11.8 replication_group_member_status

表保存了replication group成员的状态,replication_group_member_status:

·          
CHANNEL_NAME:复制来源名。

·          
VIEW_ID:该group的当前的view标示符。

·          
MEMBER_ID:member标示,和uuid一样。

·          
COUNT_TRANSACTIONS_IN_QUEUE:pending事务的个数。

·          
COUNT_TRANSACTIONS_CHECKED:已经被成员认证的事务个数。

·          
COUNT_CONFLICTS_DETECTED:冲突发现个数。

·          
COUNT_TRANSACTIONS_VALIDATING:事务可以执行检查,但是没有被回收的个数。

·          
TRANSACTIONS_COMMITTED_ALL_MEMBERS:固化的group事务集合。

·          
LAST_CONFLICT_FREE_TRANSACTION:最后一个没有冲突的被认证的事务。

OBJECT_NAME: test

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

23.9.12 性能框架锁相关表

COUNT_STAR: 1

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

23.9.12.1 metadata_locks

性能框架把元数据锁通过metadata_locks显示。显示一下信息:

·         锁已经被分配

·         锁被请求但是没有被分配。

·         锁请求但是被死锁kill或者锁等待超时而被取消。

这些信息可以了解元数据锁和会话之间的关系。可以查看等待的锁,也可以查看已经获取的锁。

Metadata_locks表只读,不能写入。默认是自动大小的,也可以通过启动参数配置大小:performance_schema_max_metadata_locks。

表默认是被禁用的,拖过设置setup_instruments的/locl/metadata/sql/mdl来启动。

性能框架维护内容,使用lock_status表示锁的状态:

·         当元数据锁被请求并且马上获取,行的状态的是GRANTED。

·         当元数据锁被请求但是没有马上获得,行的状态为pending。

·         当之前请求的元数据锁获取了,行的状态改为granted。

·         当元数据锁被释放,行被删除。

·         当pending的锁请求被死锁发现器取消,状态改为victim。

·         当pending的锁超时,状态变为pending to timeout。

·         当分配的锁或者pending的锁被kill,状态变为killed。

·         当VICTIM,TIMEOUT,KILLED被通知之后行会被删除。

·        
PRE_ACQUIRE_NOTIFY,POST_RELEASE_NOTIFY状态,当获取锁或者释放锁时,lock子系统通知所在的存储引擎的状态。

Metadata_locks列:

·        
OBJECT_TYPE:可以是这些值的其中一个. GLOBAL, SCHEMA, TABLE,
FUNCTION, PROCEDURE, TRIGGER (currently unused), EVENT, COMMIT, USER
LEVEL LOCK, TABLESPACE, LOCKING SERVICE。
如果值为USER LEVEL LOCK表示从get_lock()获取锁,如果是LOCKING SERVICE表示使用lock service获取说。

·        
OBJECT_SCHEMA:对象所在的schema

·        
OBJECT_NAME:对象名

·        
OBJECT_INSTANCE_BEGIN:记录点对象在内存中的地址。

·        
LOCK_TYPE:锁的类型,INTENTION_EXCLUSIVE, SHARED,
SHARED_HIGH_PRIO, SHARED_READ, SHARED_WRITE, SHARED_UPGRADABLE,
SHARED_NO_WRITE, SHARED_NO_READ_WRITE, or EXCLUSIVE.

·        
LOCK_DURATION:lock持续的期限。可以是这些值STATEMENT, TRANSACTION,
EXPLICIT. STATEMENT 和TRANSACTION从语句或者事务的开始直到语句或者事务的结束。

·        
LOCK_STATUS:锁的状态,PENDING,
GRANTED, VICTIM, TIMEOUT, KILLED, PRE_ACQUIRE_NOTIFY,
POST_RELEASE_NOTIFY.

·        
SOUCE:源代码文件中的文件名和位置。

·        
OWNER_THREAD_ID:请求元数据的线程。

·        
OWNER_EVENT_ID:请求锁的事件id。

…………

THREAD_ID: 1

23.9.12.2 table_handles

通过表table_handles返回表锁信息。Table_handle显示了每个打开表的handle的锁信息。那个表被打开了,如何被锁定的,是哪个线程锁的。

Table_handles是只读表,不能修改,表列如下:

·        
OBJECT_TYPE:被table handle打开的表。

·        
OBJECT_SCHEMA:表所在的schema。

·        
OBJECT_NAME:记录点对象名。

·        
OBJECT_INSTANCE_BEGIN:记录点对象在内存中的地址。

·        
OWNER_THREAD_ID:请求元数据的线程。

·        
OWNER_EVENT_ID:请求锁的事件id。

·        
INTERNAL_LOCK:SQL级别使用的表锁。值如下: READ, READ WITH SHARED
LOCKS, READ HIGH PRIORITY, READ NO INSERT, WRITE ALLOW WRITE, WRITE
CONCURRENT INSERT, WRITE LOW PRIORITY, WRITE。

·        
EXTERNAL_LOCK:存储引擎级别使用的表锁,READ EXTERNAL ,WRITE
EXTERNAL

 

1 row in set (0.00 sec)

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

23.9.13 性能框架系统变量表

MySQL维护了很多系统变量,系统变量在这些表是可用的:

·          
Global_variables:全局系统变量。如果应用程序只要全局值可以使用这个表。

·          
Session_variables:当前会话的系统变量。还有没有session变量部分的global变量

·          
Variables_by_thread:每个会话的系统变量。

这些会话级别的变量只包含了活动会话的变量。这些表不支持truncate
table。

Global_variablees和session_variables表有这些列:

·          
VARIABLES_NAME:变量名

·          
VARIABLES_VALUE:变量的值。

Variables_by_thread的列:

·          
Thread_id:线程id

·          
VARIABLES_NAME:变量名

·          
VARIABLES_VALUE:变量的值。

Variables_by_thread表包含了后台线程的系统变量信息。如果不是所有的线程记录,那么表内有些行会小时。这个时候Performance_schema_thread_instance_lost状态变量大于0 。

# table_lock_waits_summary_by_table表

COUNT_STAR: 0

23.9.14 性能框架系统状态变量表

和系统变量表类似,具体看:

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

SUM _TIMER_WAIT: 0

23.9.15 性能框架统计表

等待事件统计表:

·          
Events_waits_summary_global_by_event_name:等待事件根据每个事件进行合计。

·          
Events_waits_summary_by_instance:等待事件根据每个instance进行统计。

·          
Events_waits_summary_by_thread_by_event_name:根据线程和事件名合计的表。

Stage统计表:

·          
Events_stages_summary_by_thread_by_event_name:stage等待和线程id统计的表。

·          
Events_stages_summary_global_by_eevnt_name:stage等待中每个事件名的统计表。

语句统计表:

·          
Events_statements_summary_by_digest:每个schema和digest后的统计表。

·          
Events_statements_summary_by_thread_by_event_name:语句事件名和线程的统计表。

·          
Events_statements_summary_global_by_event_name:每个语句事件名的统计表。

·          
Events_statements_summary_by_program:每个存储程序的统计(存储过程和存储函数)。

·          
Prepared_statements_instances:预备的语句实例和统计信息。

事务统计表:

·          
Events_transactions_summary_by_account_by_event_name:每个账号发起的事件统计。

·          
Events_transactions_summary_by_host_by_event_name:每个host发起的事务事件统计。

·          
Events_transactions_summary_by_thread_by_event_name:每个线程发起的事务事件统计。

·          
Events_transactions_summary_by_user_by_event_name:每个用户发起的事务事件统计。

·          
Events_transactions_summary_global_by_event_name:事务事件名统计。

对象等待统计:

·          
Objects_summary_global_by_type:对象合计。

文件IO统计:

·          
File_summary_by_event_name:合计所有文件io事件名。

·          
File_summary_by_instance:每个文件实例的合计。

表IO和锁等待统计:

·          
Table_io_waits_summary_by_index_usage:每个所有的表io等待。

·          
Table_io_waits_summary_by_table:每个表的io等待。

·          
Table_io_waits_summary_by_table:每个表的锁等待。

连接统计:

·          
Events_waits_summary_by_account_by_event_name:每个账号发起的等待事件统计。

·          
Events_waits_summary_by_user_by_event_name:每个用户发起的等待事件统计。

·          
Events_waits_summary_by_host_by_event_name:每个host发起的等待事件合计。

·          
Events_stages_summary_by_account_by_event_name:每个账号stage事件统计。

·          
Events_stages_summary_by_user_by_event_nam:每个用户发起的stage事件统计。

·          
Events_stages_summary_by_ host_by_event_name:每个host发起的stage事件合计。

·          
Events_statements_summary_by_digest:每个schema下的所有digest。

·          
Events_statements_summary_account_by_event_name:每个账号发起的语句事件。

·          
Events_statements_summary_by_user_by_event_name:每个用户发起的语句事件。

·          
Events_statements_summary_host_by_event_name:每个host发起的语句事件。

Socket统计:

·          
Socket_summary_by_instance:每个实例的socket等待和io合计。

·          
Socket_summary_by_event_name:socket等待和io合计。

内存统计:

·          
Memory_summary_global_by_event_name:内存操作事件合计。

·          
Memory_summary_by_thead_by_event_name:每个线程内存操作合计。

·          
Memory_summary_by_account_by_event_name:每个账号内存操作合计。

·          
Memory_summary_by_user_by_event_name:每个用户内存操作合计。

·          
Memory_summary_by_host_by_event_name:每个host内存操作合计。

状态变量统计:

·          
Status_by_account:状态变量账号合计。

·          
Status_by_host:状态变量host合计

·          
Status_by_user:状态变量用户合计

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

MIN _TIMER_WAIT: 0

23.9.16 性能框架其他表

除了上面你的表还有3个表:

·          
Host_cache:内部host cache信息。

·          
Performance_timers:事件可用定时器。

·          
Threads:服务的线程表。

OBJECT_TYPE: TABLE

AVG _TIMER_WAIT: 0

23.10 性能框架选项和变量

具体看:

OBJECT_SCHEMA: xiaoboluo

MAX _TIMER_WAIT: 0

23.11 性能框架命令选项

具体看:

 

OBJECT_NAME: test

1 row in set (0.00 sec)

23.12 性能框架系统变量

具体看:

…………

# events_waits_summary_by_user_by_event_name表

23.13 性能框架状态变量

具体看:

COUNT_READ_NORMAL: 0

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

23.14 性能框架内存分配模型

在mysql 5.7.6之前,性能框架使用以下内存分配模型:

·         所有的内存在启动时分配。

·         服务操作的时候不分配内存。

·         服务操作的时候不释放内存。

·         在服务关闭的时候释放内存。

使用这个模型,性能框架会分配大量的内存,除非显示的配置。Mysql
5.7.6之后的分配模型:

·         可以在服务启动的时候分配。

·         可以在服务操作的时候额外分配。

·         在服务操作的时候不释放。

·         在服务关闭的时候释放内存。

这样可以根据负荷来调整内存使用,不是现实配置。

有一些性能框架配置参数是自动分配,也可以手动分配:

performance_schema_accounts_size
performance_schema_hosts_size
performance_schema_max_cond_instances
performance_schema_max_file_instances
performance_schema_max_index_stat
performance_schema_max_metadata_locks
performance_schema_max_mutex_instances
performance_schema_max_prepared_statements_instances
performance_schema_max_program_instances
performance_schema_max_rwlock_instances
performance_schema_max_socket_instances
performance_schema_max_table_handles
performance_schema_max_table_instances
performance_schema_max_table_lock_stat
performance_schema_max_thread_instances
performance_schema_users_size

对于自动配置的参数,配置基本如下:

·         如果为-1,默认,参数是自动配置的。

§  初始对应的内部buffer为空,没有内存。

§  当性能框架开始收集数据,没存被分配到想要的buffer。buffer大小没有上限,随着负荷上升上涨。

·         如果设置为0:

§  初始内部buffer为空,也不会分配内存。

·         如果设置的N>0:

§  对象的内部buffer为空,并且不分配内存。

§  当数据开始收集,内存开始分配,直到设置的大小。

§  一旦buffer大小到达N,内存就不再分配。性能框架收集的数据会丢失,对应的状态变量的lost
instance会增加。

为了查看性能框架使用了多少内存,检查记录点。性能框架收集了每个buffer的内存使用信息。这样可以跟踪每个buffer的内存使用情况。记录点,memory/performance
_schema/。因为这些buffer是全局的,所以只在memory_summary_global_by_event_
name上显示。查询如下:

SELECT
* FROM memory_summary_global_by_event_name WHERE EVENT_NAME LIKE
‘memory/performance_schema/%’;

SUM_TIMER_READ_NORMAL: 0

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

23.15 性能框架和

具体看:

MIN_TIMER_READ_NORMAL: 0

USER: NULL

23.16 使用性能框架诊断

性能框架可以让dba来做一些性能调整,比如一个重复出现的性能问题:

1.运行用例

2.使用性能框架表,分析根本的性能问题。分析严重依赖于post过滤。

3.问题区域已经划出,禁用对应的记录点。比如如果分析出和文件io不相关,禁用io的记录点。

4.重复 步骤1-3,这样可以减少干扰找出真正的问题。

5.明确了性能瓶颈的原因:

§  调整服务参数

§  调整查询。

§  调整数据库结构

§  调整代码。

6.重复步骤1,查看对性能的影响。

在性能调优的时候,mutex_instances.locked_by_thread_id,rwlock_instances.
write_locked_by_thread_id列十分重要。比如:

1.线程1,在等待一个信号量。

2.可以使用以下语句查看等待的信号量:

SELECT
* FROM events_waits_current WHERE THREAD_ID = thread_1;

3.然后查看那个线程持有着这个信号量:

SELECT
* FROM mutex_instances WHERE OBJECT_INSTANCE_BEGIN = mutex_A;

4.查看线程2在做什么:

SELECT
* FROM events_waits_current WHERE THREAD_ID = thread_2;

AVG_TIMER_READ_NORMAL: 0

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

23.17 迁移到性能框架系统和状态变量表

Information_schema有表包含了系统和状态变量信息,MySQL 5.7.6之后,性能框架也包含了系统变量和状态变量信息。性能框架的表会取代information_schema上的表。

在mysql 5.6查看状态变量和系统变量来自于:

SHOW
VARIABLES
SHOW STATUS

 

INFORMATION_SCHEMA.GLOBAL_VARIABLES
INFORMATION_SCHEMA.SESSION_VARIABLES

INFORMATION_SCHEMA.GLOBAL_STATUS
INFORMATION_SCHEMA.SESSION_STATUS

Mysql 5.7.6,性能框架也包含了系统变量和状态变量:

performance_schema.global_variables
performance_schema.session_variables
performance_schema.variables_by_thread

performance_schema.global_status
performance_schema.session_status
performance_schema.status_by_thread
performance_schema.status_by_account
performance_schema.status_by_host
performance_schema.status_by_user

MySQL 5.7.6增加了show_compatibility_56系统变量,如果为on:

·         当从information_schema中输出,会出现警告。

·         在mysql 5.7.6,使用show的where语句就会警告。MySQL 5.7.8之后就不会。

当变量为off,不启动兼容模式:

·         搜索information_schema表会报错。

·         Show语句输出的数据来至于性能框架表。

·         这些slave_XXX的状态变量不可用:

Slave_heartbeat_period
Slave_last_heartbeat
Slave_received_heartbeats
Slave_retried_transactions
Slave_running

       应该从性能框架的复制相关的表中获取数据。

 

迁移和权限

访问性能框架中的系统变量和状态变量需要select权限。如果show_compatibility_56为off,那么show
variables和show status也需要select权限,如果兼容性关闭,这些语句输出来至于性能框架的global_variables,session_variables,global_status,
session_status表。

在mysql 5.7.9,这些表在性能矿建中访问不需要select权限。对应的show variables和show status也不需要权限。

之后的发布,information_schema变量表和show_compatibility_56会被删除,show输出基于性能框架表。

 

 

MAX_TIMER_READ_NORMAL: 0

COUNT_STAR: 0

COUNT _READ_WITH _SHARED_LOCKS: 0

SUM _TIMER_WAIT: 0

SUM _TIMER_READ _WITH_SHARED_LOCKS: 0

MIN _TIMER_WAIT: 0

MIN _TIMER_READ _WITH_SHARED_LOCKS: 0

AVG _TIMER_WAIT: 0

AVG _TIMER_READ _WITH_SHARED_LOCKS: 0

MAX _TIMER_WAIT: 0

MAX _TIMER_READ _WITH_SHARED_LOCKS: 0

1 row in set (0.00 sec)

……

# events_waits_summary_global_by_event_name表

1 row in set (0.00 sec)

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

从上面表中的记录信息我们可以看到,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等待时间,这些表的分组和统计列含义请大家自行举一反三,这里不再赘述,下面针对这三张表做一些必要的说明:

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

table_io_waits_summary_by_table表:

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

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

必威,COUNT_STAR: 0

table_io_waits_summary_by_index_usage表:

SUM _TIMER_WAIT: 0

按照与table_io_waits_summary_by_table的分组列+INDEX_NAME列进行分组,INDEX_NAME有如下几种

MIN _TIMER_WAIT: 0

·如果使用到了索引,则这里显示索引的名字,如果为PRIMARY,则表示表I/O使用到了主键索引

AVG _TIMER_WAIT: 0

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

MAX _TIMER_WAIT: 0

·如果是插入操作,则无法使用到索引,此时的统计值是按照INDEX_NAME =
NULL计算的

1 row in set (0.00 sec)

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

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

table_lock_waits_summary_by_table表:

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

该表的分组列与table_io_waits_summary_by_table表相同

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

该表包含有关内部和外部锁的信息:

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

·内部锁对应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。但在该表的定义上并没有看到该字段)

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

·外部锁对应存储引擎层中的锁。通过调用handler::external_lock()函数来实现。(官方手册上说有一个OPERATION列来区分锁类型,该列有效值为:read
external、write external。但在该表的定义上并没有看到该字段)

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

该表允许使用TRUNCATE TABLE语句。只将统计列重置为零,而不是删除行。

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

3.文件I/O事件统计

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

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

所有表的统计列(数值型)都为如下几个:

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

COUNT_STAR:事件被执行的数量。此值包括所有事件的执行次数,需要启用等待事件的instruments

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

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

| Tables_in_performance_schema (%file_summary%) |

MIN_TIMER_WAIT:给定计时事件的最小等待时间

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

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

| file_summary_by_event_name |

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

| file_summary_by_instance |

PS:等待事件统计表允许使用TRUNCATE
TABLE语句。

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

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

2rows inset ( 0. 00sec)

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

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

对于按照帐户、主机、用户聚合的统计表,truncate语句会删除已开端连接的帐户,主机或用户对应的行,并将其他有连接的行的统计列值重置为零(实测跟未按照帐号、主机、用户聚合的统计表一样,只会被重置不会被删除)。

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

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

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

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

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

| 阶段事件统计表

# file_summary_by_event_name表

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;

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

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

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

EVENT_NAME: wait/io/file/innodb/innodb_data_file

| Tables_in_performance_schema (%events_stages_summary%) |

COUNT_STAR: 802

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

SUM_TIMER_WAIT: 412754363625

| events_stages_summary_by_account_by_event_name |

MIN_TIMER_WAIT: 0

| events_stages_summary_by_host_by_event_name |

AVG_TIMER_WAIT: 514656000

| events_stages_summary_by_thread_by_event_name |

MAX_TIMER_WAIT: 9498247500

| events_stages_summary_by_user_by_event_name |

COUNT_READ: 577

| events_stages_summary_global_by_event_name |

SUM_TIMER_READ: 305970952875

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

MIN_TIMER_READ: 15213375

5rows inset ( 0. 00sec)

AVG_TIMER_READ: 530278875

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

MAX_TIMER_READ: 9498247500

# events_stages_summary_by_account_by_event_name表

SUM _NUMBER_OF _BYTES_READ: 11567104

root@localhost : performance _schema 11:21:04> select * from
events_stages _summary_by _account_by _event_name where USER is
not null limit 1G

……

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

1 row in set (0.00 sec)

USER: root

# file_summary_by_instance表

HOST: localhost

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;

EVENT_NAME: stage/sql/After create

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

COUNT_STAR: 0

FILE_NAME: /data/mysqldata1/innodb_ts/ibdata1

SUM _TIMER_WAIT: 0

EVENT_NAME: wait/io/file/innodb/innodb_data_file

MIN _TIMER_WAIT: 0

OBJECT _INSTANCE_BEGIN: 139882156936704

AVG _TIMER_WAIT: 0

COUNT_STAR: 33

MAX _TIMER_WAIT: 0

…………

1 row in set (0.01 sec)

1 row in set (0.00 sec)

# events_stages_summary_by_host_by_event_name表

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

root@localhost : performance _schema 11:29:27> select * from
events_stages _summary_by _host_by _event_name where HOST is not
null limit 1G

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

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

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

HOST: localhost

*
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字段,用于记录具体的磁盘文件相关信息。

EVENT_NAME: stage/sql/After create

·每个文件I/O事件统计表有如下统计字段:

COUNT_STAR: 0

*
COUNT_STAR,SUM_TIMER_WAIT,MIN_TIMER_WAIT,AVG_TIMER_WAIT,MAX_TIMER_WAIT:这些列统计所有I/O操作数量和操作时间

SUM _TIMER_WAIT: 0

*
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操作的数据字节数

MIN _TIMER_WAIT: 0

*
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操作的数据字节数

AVG _TIMER_WAIT: 0

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

MAX _TIMER_WAIT: 0

文件I/O事件统计表允许使用TRUNCATE
TABLE语句。但只将统计列重置为零,而不是删除行。

1 row in set (0.00 sec)

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

# events_stages_summary_by_thread_by_event_name表

4.套接字事件统计

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

套接字事件统计了套接字的读写调用次数和发送接收字节计数信息,socket事件instruments默认关闭,在setup_consumers表中无具体的对应配置,包含如下两张表:

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

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

THREAD_ID: 1

·socket_summary_by_event_name:针对每个socket I/O
instruments,这些socket操作相关的操作次数、时间和发送接收字节信息由wait/io/socket/*
instruments产生(这里的socket是指的当前活跃的连接创建的socket实例)

EVENT_NAME: stage/sql/After create

可通过如下语句查看:

COUNT_STAR: 0

admin@localhost : performance_schema 06:53:42> show tables like
‘%socket%summary%’;

SUM _TIMER_WAIT: 0

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

MIN _TIMER_WAIT: 0

| Tables_in_performance_schema (%socket%summary%) |

AVG _TIMER_WAIT: 0

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

MAX _TIMER_WAIT: 0

| socket_summary_by_event_name |

1 row in set (0.01 sec)

| socket_summary_by_instance |

# events_stages_summary_by_user_by_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

2rows inset ( 0. 00sec)

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

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

USER: root

# socket_summary_by_event_name表

EVENT_NAME: stage/sql/After create

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

COUNT_STAR: 0

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

SUM _TIMER_WAIT: 0

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

MIN _TIMER_WAIT: 0

COUNT_STAR: 2560

AVG _TIMER_WAIT: 0

SUM_TIMER_WAIT: 62379854922

MAX _TIMER_WAIT: 0

MIN_TIMER_WAIT: 1905016

1 row in set (0.00 sec)

AVG_TIMER_WAIT: 24366870

# events_stages_summary_global_by_event_name表

MAX_TIMER_WAIT: 18446696808701862260

root@localhost : performance _schema 11:43:03> select * from
events_stages _summary_global _by_event_name limit 1G

COUNT_READ: 0

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

SUM_TIMER_READ: 0

EVENT_NAME: stage/sql/After create

MIN_TIMER_READ: 0

COUNT_STAR: 0

AVG_TIMER_READ: 0

SUM _TIMER_WAIT: 0

MAX_TIMER_READ: 0

MIN _TIMER_WAIT: 0

SUM _NUMBER_OF _BYTES_READ: 0

AVG _TIMER_WAIT: 0

……

MAX _TIMER_WAIT: 0

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

1 row in set (0.00 sec)

EVENT_NAME: wait/io/socket/sql/server_unix_socket

从上面表中的示例记录信息中,我们可以看到,同样与等待事件类似,按照用户、主机、用户+主机、线程等纬度进行分组与统计的列,这些列的含义与等待事件类似,这里不再赘述。

COUNT_STAR: 24

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

……

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

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

| 事务事件统计表

EVENT_NAME: wait/io/socket/sql/client_connection

performance_schema把事务事件统计表也按照与等待事件统计表类似的规则进行分类统计,事务事件instruments只有一个transaction,默认禁用,事务事件统计表有如下几张表:

COUNT_STAR: 213055844

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

……

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

3 rows in set (0.00 sec)

| Tables_in_performance_schema (%events_transactions_summary%) |

# socket_summary_by_instance表

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

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

| events_transactions_summary_by_account_by_event_name |

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

| events_transactions_summary_by_host_by_event_name |

EVENT_NAME: wait/io/socket/sql/server_tcpip_socket

| events_transactions_summary_by_thread_by_event_name |

OBJECT _INSTANCE_BEGIN: 2655350784

| events_transactions_summary_by_user_by_event_name |

……

| events_transactions_summary_global_by_event_name |

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

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

EVENT_NAME: wait/io/socket/sql/server_unix_socket

5rows inset ( 0. 00sec)

OBJECT _INSTANCE_BEGIN: 2655351104

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

……

# events_transactions_summary_by_account_by_event_name表

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

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

EVENT_NAME: wait/io/socket/sql/client_connection

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

OBJECT _INSTANCE_BEGIN: 2658003840

USER: root

……

HOST: localhost

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

EVENT_NAME: transaction

EVENT_NAME: wait/io/socket/sql/client_connection

COUNT_STAR: 7

OBJECT _INSTANCE_BEGIN: 2658004160

SUM _TIMER_WAIT: 8649707000

……

MIN _TIMER_WAIT: 57571000

4 rows in set (0.00 sec)

AVG _TIMER_WAIT: 1235672000

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

MAX _TIMER_WAIT: 2427645000

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

COUNT _READ_WRITE: 6

·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列进行分组

SUM _TIMER_READ_WRITE: 8592136000

每个套接字统计表都包含如下统计列:

MIN _TIMER_READ_WRITE: 87193000

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

AVG _TIMER_READ_WRITE: 1432022000

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

MAX _TIMER_READ_WRITE: 2427645000

·COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE,SUM_NUMBER_OF_BYTES_WRITE:这些列统计了所有发送操作(socket的SEND、SENDTO、SENDMSG类型操作,即以server为参照的socket写入数据的操作)相关的次数、时间、接收字节数等信息

COUNT _READ_ONLY: 1

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

SUM _TIMER_READ_ONLY: 57571000

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

MIN _TIMER_READ_ONLY: 57571000

PS:socket统计表不会统计空闲事件生成的等待事件信息,空闲事件的等待信息是记录在等待事件统计表中进行统计的。

AVG _TIMER_READ_ONLY: 57571000

5.prepare语句实例统计表

MAX _TIMER_READ_ONLY: 57571000

performance_schema提供了针对prepare语句的监控记录,并按照如下方法对表中的内容进行管理。

1 row in set (0.00 sec)

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

# events_transactions_summary_by_host_by_event_name表

·prepare语句执行:为已检测的prepare语句实例执行COM_STMT_EXECUTE或SQLCOM_PREPARE命令,同时会更新prepare_statements_instances表中对应的行信息。

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

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

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

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

HOST: localhost

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

EVENT_NAME: transaction

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

COUNT_STAR: 7

OBJECT _INSTANCE_BEGIN: 139968890586816

……

STATEMENT_ID: 1

1 row in set (0.00 sec)

STATEMENT_NAME: stmt

# events_transactions_summary_by_thread_by_event_name表

SQL_TEXT: SELECT 1

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

OWNER_THREAD_ID: 48

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

OWNER_EVENT_ID: 54

THREAD_ID: 46

OWNER_OBJECT_TYPE: NULL

EVENT_NAME: transaction

OWNER_OBJECT_SCHEMA: NULL

COUNT_STAR: 7

OWNER_OBJECT_NAME: NULL

……

TIMER_PREPARE: 896167000

1 row in set (0.00 sec)

COUNT_REPREPARE: 0

# events_transactions_summary_by_user_by_event_name表

COUNT_EXECUTE: 0

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

SUM_TIMER_EXECUTE: 0

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

MIN_TIMER_EXECUTE: 0

USER: root

AVG_TIMER_EXECUTE: 0

EVENT_NAME: transaction

MAX_TIMER_EXECUTE: 0

COUNT_STAR: 7

SUM_LOCK_TIME: 0

……

SUM_ERRORS: 0

1 row in set (0.00 sec)

SUM_WARNINGS: 0

# events_transactions_summary_global_by_event_name表

SUM_ROWS_AFFECTED: 0

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

SUM_ROWS_SENT: 0

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

……

EVENT_NAME: transaction

1 row in set (0.00 sec)

COUNT_STAR: 7

prepared_statements_instances表字段含义如下:

……

·OBJECT_INSTANCE_BEGIN:prepare语句事件的instruments
实例内存地址。

1 row in set (0.00 sec)

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

从上面表中的示例记录信息中,我们可以看到,同样与等待事件类似,按照用户、主机、用户+主机、线程等纬度进行分组与统计的列,这些列的含义与等待事件类似,这里不再赘述,但对于事务统计事件,针对读写事务和只读事务还单独做了统计(xx_READ_WRITE和xx_READ_ONLY列,只读事务需要设置只读事务变量transaction_read_only=on才会进行统计)。

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

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

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

事务聚合统计规则

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

*
事务事件的收集不考虑隔离级别,访问模式或自动提交模式

·OWNER_OBJECT_TYPE,OWNER_OBJECT_SCHEMA,OWNER_OBJECT_NAME:对于由客户端会话使用SQL语句直接创建的prepare语句,这些列值为NULL。对于由存储程序创建的prepare语句,这些列值显示相关存储程序的信息。如果用户在存储程序中忘记释放prepare语句,那么这些列可用于查找这些未释放的prepare对应的存储程序,使用语句查询:SELECT
OWNER_OBJECT_TYPE,OWNER_OBJECT_SCHEMA,OWNER_OBJECT_NAME,STATEMENT_NAME,SQL_TEXT
FROM performance_schema.prepared_statemments_instances WHERE
OWNER_OBJECT_TYPE IS NOT NULL;

*
读写事务通常比只读事务占用更多资源,因此事务统计表包含了用于读写和只读事务的单独统计列

·TIMER_PREPARE:执行prepare语句本身消耗的时间。

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

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

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

·COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE:执行prepare语句时的相关统计数据。

| 语句事件统计表

·SUM_xxx:其余的SUM_xxx开头的列与语句统计表中的信息相同,语句统计表后续章节会详细介绍。

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

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

events_statements_summary_by_account_by_event_name:按照每个帐户和语句事件名称进行统计

PS:什么是prepare语句?prepare语句实际上就是一个预编译语句,先把SQL语句进行编译,且可以设定参数占位符(例如:?符号),然后调用时通过用户变量传入具体的参数值(叫做变量绑定),如果一个语句需要多次执行而仅仅只是where条件不同,那么使用prepare语句可以大大减少硬解析的开销,prepare语句有三个步骤,预编译prepare语句,执行prepare语句,释放销毁prepare语句,prepare语句支持两种协议,前面已经提到过了,binary协议一般是提供给应用程序的mysql
c api接口方式访问,而文本协议提供给通过客户端连接到mysql
server的方式访问,下面以文本协议的方式访问进行演示说明:

events_statements_summary_by_digest:按照每个库级别对象和语句事件的原始语句文本统计值(md5
hash字符串)进行统计,该统计值是基于事件的原始语句文本进行精炼(原始语句转换为标准化语句),每行数据中的相关数值字段是具有相同统计值的统计结果。

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

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

·execute步骤:语法EXECUTE stmt_name[USING @var_name [,
@var_name] …],示例:execute stmt;
返回执行结果为1,此时在prepared_statements_instances表中的统计信息会进行更新;

events_statements_summary_by_program:按照每个存储程序(存储过程和函数,触发器和事件)的事件名称进行统计的Statement事件

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

events_statements_summary_by_thread_by_event_name:按照每个线程和事件名称进行统计的Statement事件

6.instance 统计表

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

instance表记录了哪些类型的对象被检测。这些表中记录了事件名称(提供收集功能的instruments名称)及其一些解释性的状态信息(例如:file_instances表中的FILE_NAME文件名称和OPEN_COUNT文件打开次数),instance表主要有如下几个:

events_statements_summary_global_by_event_name:按照每个事件名称进行统计的Statement事件

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

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

·file_instances:文件对象实例;

可通过如下语句查看语句事件统计表:

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

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

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

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

·socket_instances:活跃连接实例。

| Tables_in_performance_schema (%events_statements_summary%) |

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

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

mutex_instances.LOCKED_BY_THREAD_ID和rwlock_instances.WRITE_LOCKED_BY_THREAD_ID列对于排查性能瓶颈或死锁问题至关重要。

| events_statements_summary_by_account_by_event_name |

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

| events_statements_summary_by_digest |

下面对这些表分别进行说明。

| events_statements_summary_by_host_by_event_name |

(1)cond_instances表

| events_statements_summary_by_program |

cond_instances表列出了server执行condition instruments
时performance_schema所见的所有condition,condition表示在代码中特定事件发生时的同步信号机制,使得等待该条件的线程在该condition满足条件时可以恢复工作。

| events_statements_summary_by_thread_by_event_name |

·当一个线程正在等待某事发生时,condition
NAME列显示了线程正在等待什么condition(但该表中并没有其他列来显示对应哪个线程等信息),但是目前还没有直接的方法来判断某个线程或某些线程会导致condition发生改变。

| events_statements_summary_by_user_by_event_name |

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

| events_statements_summary_global_by_event_name |

admin@localhost : performance_schema 02:50:02> select * from
cond_instances limit 1;

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

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

7rows inset ( 0. 00sec)

| NAME |OBJECT_INSTANCE_BEGIN |

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

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

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

|wait/synch/cond/sql/COND_manager | 31903008 |

| Tables_in_performance_schema (%prepare%) |

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

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

1row inset ( 0. 00sec)

| prepared_statements_instances |

cond_instances表字段含义如下:

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

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

1row inset ( 0. 00sec)

· OBJECT_INSTANCE_BEGIN:instruments condition的内存地址;

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

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

# events_statements_summary_by_account_by_event_name表

(2)file_instances表

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

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

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

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

USER: root

admin@localhost : performance_schema 02:53:40> select * from
file_instances where OPEN_COUNT> 0limit 1;

HOST: localhost

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

EVENT_NAME: statement/sql/select

| FILE_NAME |EVENT_NAME | OPEN_COUNT |

COUNT_STAR: 53

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

SUM_TIMER_WAIT: 234614735000

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

MIN_TIMER_WAIT: 72775000

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

AVG_TIMER_WAIT: 4426693000

1row inset ( 0. 00sec)

MAX_TIMER_WAIT: 80968744000

file_instances表字段含义如下:

SUM_LOCK_TIME: 26026000000

·FILE_NAME:磁盘文件名称;

SUM_ERRORS: 2

·EVENT_NAME:与文件相关联的instruments名称;

SUM_WARNINGS: 0

OPEN_COUNT:文件当前已打开句柄的计数。如果文件打开然后关闭,则打开1次,但OPEN_COUNT列将加一然后减一,因为OPEN_COUNT列只统计当前已打开的文件句柄数,已关闭的文件句柄会从中减去。要列出server中当前打开的所有文件信息,可以使用where
WHERE OPEN_COUNT> 0子句进行查看。

SUM_ROWS_AFFECTED: 0

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

SUM_ROWS_SENT: 1635

(3)mutex_instances表

SUM_ROWS_EXAMINED: 39718

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

SUM _CREATED_TMP _DISK_TABLES: 3

当在server中同时执行的两个线程(例如,同时执行查询的两个用户会话)需要访问相同的资源(例如:文件、缓冲区或某些数据)时,这两个线程相互竞争,因此第一个成功获取到互斥体的查询将会阻塞其他会话的查询,直到成功获取到互斥体的会话执行完成并释放掉这个互斥体,其他会话的查询才能够被执行。

SUM _CREATED_TMP_TABLES: 10

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

SUM _SELECT_FULL_JOIN: 21

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

SUM _SELECT_FULL _RANGE_JOIN: 0

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

SUM_SELECT_RANGE: 0

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

SUM _SELECT_RANGE_CHECK: 0

| NAME |OBJECT_INSTANCE_BEGIN | LOCKED_BY_THREAD_ID |

SUM_SELECT_SCAN: 45

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

SUM _SORT_MERGE_PASSES: 0

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

SUM_SORT_RANGE: 0

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

SUM_SORT_ROWS: 170

1row inset ( 0. 00sec)

SUM_SORT_SCAN: 6

mutex_instances表字段含义如下:

SUM_NO_INDEX_USED: 42

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

SUM _NO_GOOD _INDEX_USED: 0

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

1 row in set (0.00 sec)

·LOCKED_BY_THREAD_ID:当一个线程当前持有一个互斥锁定时,LOCKED_BY_THREAD_ID列显示持有线程的THREAD_ID,如果没有被任何线程持有,则该列值为NULL。

# events_statements_summary_by_digest表

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

root@localhost : performance _schema 11:01:51> select * from
events_statements _summary_by_digest limit 1G

对于代码中的每个互斥体,performance_schema提供了以下信息:

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

·setup_instruments表列出了instruments名称,这些互斥体都带有wait/synch/mutex/前缀;

SCHEMA_NAME: NULL

·当server中一些代码创建了一个互斥量时,在mutex_instances表中会添加一行对应的互斥体信息(除非无法再创建mutex
instruments
instance就不会添加行)。OBJECT_INSTANCE_BEGIN列值是互斥体的唯一标识属性;

DIGEST: 4fb483fe710f27d1d06f83573c5ce11c

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

DIGEST_TEXT: SELECT @@`version_comment` LIMIT ?

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

COUNT_STAR: 3

*
events_waits_current表中可以查看到当前正在等待互斥体的线程时间信息(例如:TIMER_WAIT列表示已经等待的时间)

……

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

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

* mutex_instances表中的THREAD_ID列显示该互斥体现在被哪个线程持有。

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

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

1 row in set (0.00 sec)

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

# events_statements_summary_by_host_by_event_name表

通过对以下两个表执行查询,可以实现对应用程序的监控或DBA可以检测到涉及互斥体的线程之间的瓶颈或死锁信息(events_waits_current可以查看到当前正在等待互斥体的线程信息,mutex_instances可以查看到当前某个互斥体被哪个线程持有)。

root@localhost : performance _schema 11:02:15> select * from
events_statements _summary_by _host_by _event_name where
COUNT_STAR!=0 limit 1G

(4)rwlock_instances表

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

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

HOST: localhost

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

EVENT_NAME: statement/sql/select

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

COUNT_STAR: 55

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

……

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

1 row in set (0.00 sec)

| NAME |OBJECT_INSTANCE_BEGIN | WRITE_LOCKED_BY_THREAD_ID
|READ_LOCKED_BY_COUNT |

#
events_statements_summary_by_program表(需要调用了存储过程或函数之后才会有数据)

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

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

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

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

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

OBJECT_TYPE: PROCEDURE

1row inset ( 0. 00sec)

OBJECT_SCHEMA: sys

rwlock_instances表字段含义如下:

OBJECT_NAME: ps_setup_enable_consumer

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

COUNT_STAR: 1

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

…………

·WRITE_LOCKED_BY_THREAD_ID:当一个线程当前在独占(写入)模式下持有一个rwlock时,WRITE_LOCKED_BY_THREAD_ID列可以查看到持有该锁的线程THREAD_ID,如果没有被任何线程持有则该列为NULL;

1 row in set (0.00 sec)

·READ_LOCKED_BY_COUNT:当一个线程在共享(读)模式下持有一个rwlock时,READ_LOCKED_BY_COUNT列值增加1,所以该列只是一个计数器,不能直接用于查找是哪个线程持有该rwlock,但它可以用来查看是否存在一个关于rwlock的读争用以及查看当前有多少个读模式线程处于活跃状态。

# events_statements_summary_by_thread_by_event_name表

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

root@localhost : performance _schema 11:03:19> select * from
events_statements _summary_by _thread_by _event_name where
COUNT_STAR!=0 limit 1G

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

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

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

THREAD_ID: 47

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

EVENT_NAME: statement/sql/select

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

COUNT_STAR: 11

(5) socket_instances表

……

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

1 row in set (0.01 sec)

套接字instruments具有wait/io/socket/sql/socket_type形式的名称,如下:

# events_statements_summary_by_user_by_event_name表

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

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

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

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

·当连接终止时,在socket_instances表中对应的连接信息行被删除。

USER: root

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

EVENT_NAME: statement/sql/select

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

COUNT_STAR: 58

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

……

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

1 row in set (0.00 sec)

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

# events_statements_summary_global_by_event_name表

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

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

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

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

| wait/io/socket/sql/client_connection |110667840 | 45 |51|
::ffff:10.10.20.15 |56842| ACTIVE |

EVENT_NAME: statement/sql/select

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

COUNT_STAR: 59

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

……

4rows inset ( 0. 00sec)

1 row in set (0.00 sec)

socket_instances表字段含义如下:

从上面表中的示例记录信息中,我们可以看到,同样与等待事件类似,按照用户、主机、用户+主机、线程等纬度进行分组与统计的列,分组和部分时间统计列与等待事件类似,这里不再赘述,但对于语句统计事件,有针对语句对象的额外的统计列,如下:

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

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

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

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

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

*
FIRST_SEEN,LAST_SEEN:显示某给定语句第一次插入
events_statements_summary_by_digest表和最后一次更新该表的时间戳

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

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

·IP:客户端IP地址。该值可以是IPv4或IPv6地址,也可以是空串,表示这是一个Unix套接字文件连接;

*
COUNT_STATEMENTS,SUM_STATEMENTS_WAIT,MIN_STATEMENTS_WAIT,AVG_STATEMENTS_WAIT,MAX_STATEMENTS_WAIT:关于存储程序执行期间调用的嵌套语句的统计信息

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

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

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

*
COUNT_EXECUTE,SUM_TIMER_EXECUTE,MIN_TIMER_EXECUTE,AVG_TIMER_EXECUTE,MAX_TIMER_EXECUTE:执行prepare语句对象的统计信息

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

PS1:

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

关于events_statements_summary_by_digest表

·对于Unix
domain套接字(server_unix_socket)的server端监听器,端口为0,IP为空串;

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

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

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

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

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

·对于通过TCP/IP
套接字(client_connection)的客户端连接,端口是server随机分配的,但不会为0值.
IP是源主机的IP(127.0.0.1或本地主机的:: 1)。

*
如果给定语句的统计信息行在events_statements_summary_by_digest表中没有已存在行,且events_statements_summary_by_digest表空间限制已满的情况下,则该语句的统计信息将添加到DIGEST
列值为
NULL的特殊“catch-all”行,如果该特殊行不存在则新插入一行,FIRST_SEEN和LAST_SEEN列为当前时间。如果该特殊行已存在则更新该行的信息,LAST_SEEN为当前时间

7.锁对象记录表

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

performance_schema通过如下表来记录相关的锁信息:

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

·metadata_locks:元数据锁的持有和请求记录;

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

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

当某给定对象在server中首次被使用时(即使用call语句调用了存储过程或自定义存储函数时),将在events_statements_summary_by_program表中添加一行统计信息;

(1)metadata_locks表

当某给定对象被删除时,该对象在events_statements_summary_by_program表中的统计信息行将被删除;

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

当某给定对象被执行时,其对应的统计信息将记录在events_statements_summary_by_program表中并进行统计。

·已授予的锁(显示哪些会话拥有当前元数据锁);

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

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

| 内存事件统计表

·已被死锁检测器检测到并被杀死的锁,或者锁请求超时正在等待锁请求会话被丢弃。

performance_schema把内存事件统计表也按照与等待事件统计表类似的规则进行分类统计。

这些信息使您能够了解会话之间的元数据锁依赖关系。不仅可以看到会话正在等待哪个锁,还可以看到当前持有该锁的会话ID。

performance_schema会记录内存使用情况并聚合内存使用统计信息,如:使用的内存类型(各种缓存,内部缓冲区等)和线程、帐号、用户、主机的相关操作间接执行的内存操作。performance_schema从使用的内存大小、相关操作数量、高低水位(内存一次操作的最大和最小的相关统计值)。

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

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

元数据锁instruments使用wait/lock/metadata/sql/mdl,默认未开启。

检测内存工作负载峰值、内存总体的工作负载稳定性、可能的内存泄漏等是至关重要的。

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

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

admin@localhost : performance _schema 04:55:42> select * from
metadata_locksG;

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

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

内存事件统计表有如下几张表:

OBJECT_TYPE: TABLE

admin@localhost : performance_schema 06:56:56> show tables like
‘%memory%summary%’;

OBJECT_SCHEMA: xiaoboluo

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

OBJECT_NAME: test

| Tables_in_performance_schema (%memory%summary%) |

OBJECT _INSTANCE_BEGIN: 140568048055488

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

LOCK_TYPE: SHARED_READ

| memory_summary_by_account_by_event_name |

LOCK_DURATION: TRANSACTION

| memory_summary_by_host_by_event_name |

LOCK_STATUS: GRANTED

| memory_summary_by_thread_by_event_name |

SOURCE: sql_parse.cc:6031

| memory_summary_by_user_by_event_name |

OWNER _THREAD_ID: 46

| memory_summary_global_by_event_name |

OWNER _EVENT_ID: 49

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

1 rows in set (0.00 sec)

5rows inset ( 0. 00sec)

metadata_locks表字段含义如下:

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

·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值表示使用锁服务获取的锁;

# 如果需要统计内存事件信息,需要开启内存事件采集器

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

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

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

Query OK, 377 rows affected (0.00 sec)

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

Rows matched: 377 Changed: 377 Warnings: 0

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

# memory_summary_by_account_by_event_name表

·LOCK_DURATION:来自元数据锁子系统中的锁定时间。有效值为:STATEMENT、TRANSACTION、EXPLICIT,STATEMENT和TRANSACTION值分别表示在语句或事务结束时会释放的锁。
EXPLICIT值表示可以在语句或事务结束时被会保留,需要显式释放的锁,例如:使用FLUSH
TABLES WITH READ LOCK获取的全局锁;

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

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

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

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

USER: NULL

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

HOST: NULL

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

EVENT_NAME: memory/innodb/fil0fil

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

COUNT_ALLOC: 103

·当请求立即获取元数据锁时,将插入状态为GRANTED的锁信息行;

COUNT_FREE: 103

·当请求元数据锁不能立即获得时,将插入状态为PENDING的锁信息行;

SUM _NUMBER_OF _BYTES_ALLOC: 3296

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

SUM _NUMBER_OF _BYTES_FREE: 3296

·释放元数据锁时,对应的锁信息行被删除;

LOW_COUNT_USED: 0

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

CURRENT_COUNT_USED: 0

·当待处理的锁请求超时,会返回错误信息(ER_LOCK_WAIT_TIMEOUT)给请求锁的会话,锁状态从PENDING更新为TIMEOUT;

HIGH_COUNT_USED: 1

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

LOW _NUMBER_OF _BYTES_USED: 0

·VICTIM,TIMEOUT和KILLED状态值停留时间很简短,当一个锁处于这个状态时,那么表示该锁行信息即将被删除(手动执行SQL可能因为时间原因查看不到,可以使用程序抓取);

CURRENT _NUMBER_OF _BYTES_USED: 0

·PRE_ACQUIRE_NOTIFY和POST_RELEASE_NOTIFY状态值停留事件都很简短,当一个锁处于这个状态时,那么表示元数据锁子系统正在通知相关的存储引擎该锁正在执行分配或释。这些状态值在5.7.11版本中新增。

HIGH _NUMBER_OF _BYTES_USED: 32

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

1 row in set (0.00 sec)

(2)table_handles表

# memory_summary_by_host_by_event_name表

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

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

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

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

对应的instruments为wait/io/table/sql/handler和wait/lock/table/sql/handler,默认开启。

HOST: NULL

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

EVENT_NAME: memory/innodb/fil0fil

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

COUNT_ALLOC: 158

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

……

| OBJECT_TYPE |OBJECT_SCHEMA | OBJECT_NAME |OBJECT_INSTANCE_BEGIN |
OWNER_THREAD_ID |OWNER_EVENT_ID | INTERNAL_LOCK |EXTERNAL_LOCK |

1 row in set (0.00 sec)

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

# memory_summary_by_thread_by_event_name表

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

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

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

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

1row inset ( 0. 00sec)

THREAD_ID: 37

table_handles表字段含义如下:

EVENT_NAME: memory/innodb/fil0fil

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

COUNT_ALLOC: 193

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

……

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

1 row in set (0.00 sec)

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

# memory_summary_by_user_by_event_name表

· OWNER_THREAD_ID:持有该handles锁的线程ID;

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

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

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

·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源文件;

USER: NULL

·EXTERNAL_LOCK:在存储引擎级别使用的表锁。有效值为:READ
EXTERNAL、WRITE EXTERNAL。

EVENT_NAME: memory/innodb/fil0fil

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

COUNT_ALLOC: 216

02

……

属性统计表

1 row in set (0.00 sec)

1. 连接信息统计表

# memory_summary_global_by_event_name表

当客户端连接到MySQL
server时,它的用户名和主机名都是特定的。performance_schema按照帐号、主机、用户名对这些连接的统计信息进行分类并保存到各个分类的连接信息表中,如下:

root@localhost : performance _schema 11:56:02> select * from
memory_summary _global_by _event_name where COUNT_ALLOC!=0 limit
1G

·accounts:按照user@host的形式来对每个客户端的连接进行统计;

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

·hosts:按照host名称对每个客户端连接进行统计;

EVENT_NAME: memory/performance_schema/mutex_instances

·users:按照用户名对每个客户端连接进行统计。

COUNT_ALLOC: 1

连接信息表accounts中的user和host字段含义与mysql系统数据库中的MySQL
grant表(user表)中的字段含义类似。

……

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

1 row in set (0.00 sec)

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

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

当客户端与server端建立连接时,performance_schema使用适合每个表的唯一标识值来确定每个连接表中如何进行记录。如果缺少对应标识值的行,则新添加一行。然后,performance_schema会增加该行中的CURRENT_CONNECTIONS和TOTAL_CONNECTIONS列值。

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

当客户端断开连接时,performance_schema将减少对应连接的行中的CURRENT_CONNECTIONS列,保留TOTAL_CONNECTIONS列值。

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

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

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

· 当行信息中CURRENT_CONNECTIONS
字段值为0时,执行truncate语句会删除这些行;

*
CURRENT_COUNT_USED:这是一个便捷列,等于COUNT_ALLOC – COUNT_FREE

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

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

·依赖于连接表中信息的summary表在对这些连接表执行truncate时会同时被隐式地执行truncate,performance_schema维护着按照accounts,hosts或users统计各种事件统计表。这些表在名称包括:_summary_by_account,_summary_by_host,*_summary_by_user

  • SUM_NUMBER_OF_BYTES_FREE

连接统计信息表允许使用TRUNCATE
TABLE。它会同时删除统计表中没有连接的帐户,主机或用户对应的行,重置有连接的帐户,主机或用户对应的行的并将其他行的CURRENT_CONNECTIONS和TOTAL_CONNECTIONS列值。

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

必威 3

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

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

内存统计表允许使用TRUNCATE
TABLE语句。使用truncate语句时有如下行为:

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

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

(1)accounts表

*
将COUNT_ALLOC和COUNT_FREE列重置,并重新开始计数(等于内存统计信息以重置后的数值作为基准数据)

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

*
SUM_NUMBER_OF_BYTES_ALLOC和SUM_NUMBER_OF_BYTES_FREE列重置与COUNT_ALLOC和COUNT_FREE列重置类似

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

*
LOW_COUNT_USED和HIGH_COUNT_USED将重置为CURRENT_COUNT_USED列值

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

*
LOW_NUMBER_OF_BYTES_USED和HIGH_NUMBER_OF_BYTES_USED将重置为CURRENT_NUMBER_OF_BYTES_USED列值

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

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

| USER |HOST | CURRENT_CONNECTIONS |TOTAL_CONNECTIONS |

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

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

内存行为监控设置:

|NULL | NULL |41| 45 |

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

| qfsys |10.10. 20.15| 1 |1|

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

|admin | localhost |1| 1 |

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

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

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

3rows inset ( 0. 00sec)

当server中的某线程执行了内存分配操作时,按照如下规则进行检测与聚合:

accounts表字段含义如下:

*
如果该线程在threads表中没有开启采集功能或者说在setup_instruments中对应的instruments没有开启,则该线程分配的内存块不会被监控

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

*
如果threads表中该线程的采集功能和setup_instruments表中相应的memory
instruments都启用了,则该线程分配的内存块会被监控

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

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

·CURRENT_CONNECTIONS:某帐号的当前连接数;

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

·TOTAL_CONNECTIONS:某帐号的总连接数(新增加一个连接累计一个,不会像当前连接数那样连接断开会减少)。

*
如果一个线程没有开启采集功能,但是内存相关的instruments启用了,则该内存释放的操作会被监控到,统计数据会发生改变,这也是前面提到的为啥反复在运行时修改memory
instruments可能导致统计数据为负数的原因

(2)users表

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

users表包含连接到MySQL
server的每个用户的连接信息,每个用户一行。该表将针对用户名作为唯一标识进行统计当前连接数和总连接数,server启动时,表的大小会自动调整。
要显式设置该表大小,可以在server启动之前设置系统变量performance_schema_users_size的值。该变量设置为0时表示禁用users统计信息。

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

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

* COUNT_ALLOC:增加1

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

* CURRENT_COUNT_USED:增加1

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

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

| USER |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |

* SUM_NUMBER_OF_BYTES_ALLOC:增加N

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

*
CURRENT_NUMBER_OF_BYTES_USED:增加N

| NULL |41| 45 |

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

| qfsys |1| 1 |

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

| admin |1| 1 |

* COUNT_FREE:增加1

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

* CURRENT_COUNT_USED:减少1

3rows inset ( 0. 00sec)

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

users表字段含义如下:

* SUM_NUMBER_OF_BYTES_FREE:增加N

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

* CURRENT_NUMBER_OF_BYTES_USED:减少N

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

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

·TOTAL_CONNECTIONS:某用户的总连接数。

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

(3)hosts表

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

hosts表包含客户端连接到MySQL
server的主机信息,一个主机名对应一行记录,该表针对主机作为唯一标识进行统计当前连接数和总连接数。server启动时,表的大小会自动调整。
要显式设置该表大小,可以在server启动之前设置系统变量performance_schema_hosts_size的值。如果该变量设置为0,则表示禁用hosts表统计信息。

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

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

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

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

| 温馨提示

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

性能事件统计表中的数据条目是不能删除的,只能把相应统计字段清零;

| HOST |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |

性能事件统计表中的某个instruments是否执行统计,依赖于在setup_instruments表中的配置项是否开启;

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

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

| NULL |41| 45 |

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

| 10.10.20.15 |1| 1 |

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

| localhost |1| 1 |

责任编辑:

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

3rows inset ( 0. 00sec)

hosts表字段含义如下:

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

·CURRENT_CONNECTIONS:某主机的当前连接数;

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

2. 连接属性统计表

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

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

·session_account_connect_attrs:记录当前会话及其相关联的其他会话的连接属性;

·session_connect_attrs:所有会话的连接属性。

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

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

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

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

* _client_version:客户端libmysql库版本

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

* _pid:客户端进程ID

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

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

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

* _client_license:连接器许可证类型

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

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

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

* _client_version:客户端库版本

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

* _pid:客户端进程ID

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

* _program_name:客户端程序名称

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

·PHP定义的属性依赖于编译的属性:

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

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

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

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

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

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

从客户端发送到服务器的连接属性数据量存在限制:客户端在连接之前客户端有一个自己的固定长度限制(不可配置)、在客户端连接server时服务端也有一个固定长度限制、以及在客户端连接server时的连接属性值在存入performance_schema中时也有一个可配置的长度限制。

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

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

·server只接受的连接属性数据的统计大小限制为64KB。如果客户端尝试发送超过64KB(正好是一个表所有字段定义长度的总限制长度)的属性数据,则server将拒绝该连接;

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

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

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

[Warning] Connection attributes oflength N were truncated

(1) session_account_connect_attrs表

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

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

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

admin@localhost : performance_schema 11:00:45> select * from
session_account_connect_attrs;

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

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

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

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

| 4 |_client_name | libmysql |1|

|4| _pid |3766| 2 |

| 4 |_client_version | 5.7.18 |3|

|4| _platform |x86_64 | 4 |

| 4 |program_name | mysql |5|

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

6 rows inset (0.00 sec)

session_account_connect_attrs表字段含义:

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

·ATTR_NAME:连接属性名称;

·ATTR_VALUE:连接属性值;

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

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

(2)session_connect_attrs表

表字段含义与session_account_connect_attrs表相同,但是该表是保存所有连接的连接属性表。

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

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

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

| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |

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

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

| 3 |_client_name | libmysql |1|

……

14 rows inset (0.01 sec)

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

– END –

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

责任编辑:

相关文章