MySQL的performance schema 用于监察和控制MySQL server在叁个极低端其余运营进度中的资源消耗、财富等待等气象，它抱有以下特征：
应用程序能够应用mysql_options（）和mysql_options4（）C API函数在连接时提供部分要传送到server的键值对三回九转属性。
MySQL Performance-Schema(二) 理论篇，performanceschema
MySQL Performance-Schema中一同饱含伍拾叁个表，主要分为几类：Setup表，Instance表，Wait 伊芙nt表，Stage 伊夫nt表Statement 伊夫nt表，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/THENVISION_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表记录了各类线程前段时间静观其变的十三个事件，而history_long表则记录了那二日具有线程爆发的壹仟0个事件，这里的10和一千0都以足以安插的。那多个表表结构同样，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发出的三15个人字符串。即使为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_STALAND：事件计数
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_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中累计满含54个表，主要分为几类：Setup表，Instance表，Wait 伊芙nt表，Stage Ev...
| Tables_in_performance_schema (%statement%) |
·PROCESSLIST_ID：会话的连年标记符，与show processlist结果中的ID字段同样；
| events_statements_history |
·若是应用到了目录，则这里呈现索引的名字，假设为PRubiconIMA奥迪Q3Y，则代表表I/O使用到了主键索引
......
·对于TCP/IP server套接字（server_tcpip_socket）的server端监听器，端口始终为主端口（举个例子3306），IP始终为0.0.0.0；
-----------------------------------------------
------------- --------------------- -------------------
--------------------------------------------------- ------------
大家先来拜访表中记录的总计音讯是什么样体统的。
罗小波·沃趣科技(science and technology)尖端数据库技艺专家
· COUNT_REPREPARE：该行新闻对应的prepare语句在里面被另行编写翻译的次数，重新编写翻译prepare语句之后，在此之前的相关总结消息就不可用了，因为这个计算音信是作为言语推行的一有的被集结到表中的，实际不是单独维护的。
OBJECT_INSTANCE_BEGIN: 955681576
·socket_summary_by_event_name：针对各种socket I/O instruments，这一个socket操作相关的操作次数、时间和发送接收字节消息由wait/io/socket/* instruments发生（这里的socket是指的当下活蹦乱跳的连年成立的socket实例）
1 row in set (0.02 sec)
OBJECT_NAME: test
| users |
·PRE_ACQUIRE_NOTIFY和POST_RELEASE_NOTIFY状态值停留事件都相当粗略，当二个锁处于那几个意况时，那么表示元数据锁子系统正在文告有关的存款和储蓄引擎该锁正在施行分配或释。这么些意况值在5.7.11本子中新扩大。
performance_schema被视为存款和储蓄引擎。设若该内燃机可用，则应当在INFORMATION_SCHEMA.ENGINES表或SHOW ENGINES语句的出口中都能够见到它的SUPPORT值为YES，如下：
......
| /data/mysqldata1/undo/undo001 |wait/io/file/innodb/innodb_data_file | 3 |
（2）table_handles表
TIMER_END: 1582395491787190144
PS：MySQL server使用两种缓存技能通过缓存从文件中读取的新闻来防止文件I/O操作。当然，若是内部存款和储蓄器远远不足时照旧内存竞争相当大时恐怕产生查询功能低下，今年你或者要求通过刷新缓存也许重启server来让其数额经过文件I/O再次来到并非通过缓存重回。
2.1反省当前数据库版本是不是支持
------------- --------------- ------------- ----------------------- ----------------- ---------------- --------------- ---------------
| Tables_in_performance_schema |
OBJECT_NAME: test
qogir_env@localhost : performance_schema 03:53:51> show tables like 'events_wait%';
*************************** 3. row ***************************
| events_waits_summary_by_host_by_event_name |
---------------------------------------- ----------------------- ----------- ----------- -------------------- ------- --------
------------------------------------------------
------------- --------------------- -------------------
5rows inset (0.00sec)
OBJECT_TYPE: TABLE
| wait/synch/mutex/mysys/THR_LOCK_open |187|
-----------------------------------------------
| memory_summary_by_host_by_event_name |
* mutex_instances表中的THREAD_ID列展现该互斥浮未来被哪些线程持有。
| accounts |
performance_schema还计算后台线程和不或者注脚用户的三翻五次，对于这一个连接计算行音信，USE凯雷德和HOST列值为NULL。
......
metadata_locks表不容许行使TRUNCATE TABLE语句。
------------------------------------------------------
| file_summary_by_instance |
-----------------------------------------
------------------------------------------------------- ----------------------- --------------------------- ----------------------
｜本文小结
·mutex_instances：wait sync相关的Mutex对象实例；
......
（3）mutex_instances表
------------------------------------------------------ -------------------------------------- ------------
原标题：数据库对象事件与品质计算 | performance_schema全方位介绍（五）
| events_stages_summary_by_user_by_event_name |
------------------------------------ -------------------------------------- ------------
----------- ---------- ------------------------------------------ ------------
·如若是插入操作，则不能够运用到目录，此时的计算值是鲁人持竿INDEX_NAME = NULL计算的
通过从INFORMATION_SCHEMA.tables表查询有怎么着performance_schema引擎的表：
OWNER_OBJECT_SCHEMA: NULL
mysqld运营之后，通过如下语句查看performance_schema是不是启用生效（值为ON表示performance_schema已开端化成功且能够采纳了。假设值为OFF表示在启用performance_schema时发出一些错误。能够查看错误日志举行排查）：
MAX _TIMER_WAIT: 121025235946125
2.3. performance_schema表的归类
01
- row ***************************
COUNT_READ: 577
| wait/io/file/sql/binlog_index |1385291934|
·ATTR_NAME：连接属性名称；
|Transactions | XA |Savepoints |
admin@localhost : performance_schema 09 :49:41> select * from hosts;
| /data/mysqldata1/undo/undo002 |wait/io/file/innodb/innodb_data_file | 3 |
admin@localhost : performance_schema 10:28:45> select * from rwlock_instances limit 1;
Database changed
·当在此以前诉求不可能即刻得到的锁在那之后被授予时，其锁新闻行状态更新为GRANTED；
|wait/synch/mutex/mysys/THR_LOCK::mutex | 89 |
* 已成功的等候事件将丰盛到events_waits_history和events_waits_history_long表中 ；
| events_transactions_history |
2. 连接属性计算表
数据库刚刚初叶化并运维时，并非全部instruments(事件访问项，在搜罗项的配备表中每一样都有一个按钮字段，或为YES，或为NO)和consumers(与征集项类似，也会有一个对应的事件类型保存表配置项，为YES就意味着对应的表保存品质数据，为NO就表示对应的表不保留质量数据)都启用了，所以私下认可不会采摘全数的风云，也许您供给检查评定的平地风波并从未展开，须求进行安装，能够使用如下三个语句展开对应的instruments和consumers（行计数大概会因MySQL版本而异），比如，大家以安插监测等待事件数量为例进行认证：
·setup_instruments表列出了instruments名称，那些互斥体都满含wait/synch/mutex/前缀；
------------------------------------------------------
instance表记录了哪些类型的靶子被检验。那些表中著录了事件名称（提供搜罗效用的instruments名称）及其一些解释性的景况新闻（比如：file_instances表中的FILE_NAME文件名称和OPEN_COUNT文件打开次数），instance表紧要有如下多少个：
| Variable_name |Value |
1row inset ( 0. 00sec)
qogir_env@localhost : performance_schema 02:41:41> SELECT * FROM INFORMATION_SCHEMA.ENGINES WHERE ENGINE ='PERFORMANCE_SCHEMA';
SUM_TIMER_READ: 305970952875
｜1、**什么是performance_schema**
*************************** 4. row ***************************
| ENGINE |SUPPORT | COMMENT |TRANSACTIONS | XA |SAVEPOINTS |
各样套接字总括表都包涵如下总计列：
| events_transactions_summary_by_host_by_event_name |
admin@localhost : performance_schema 09 :50:01> select * from users;
前段时间，是还是不是感觉上边的牵线内容太过平淡呢？假诺你这样想，那就对了，作者当下攻读的时候也是那般想的。但以往，对于如何是performance_schema这几个主题材料上，比起更早以前更清楚了呢？假若你还尚无筹算要废弃读书本文的话，那么，请随行大家起首步入到"边走边唱"环节呢！
·当连接终止时，在socket_instances表中对应的三番五次音讯行被删去。
布局好之后，大家就能够查阅server当前正在做什么样，可以由此查询events_waits_current表来获知，该表中各类线程只含有一行数据，用于展现各样线程的风尚监视事件（正在做的事体）：
(1) session_account_connect_attrs表
| /data/mysqldata1/mydata/mysql/innodb_table_stats.ibd |wait/io/file/innodb/innodb_data_file | 3 |
OBJECT_TYPE: TABLE
| memory_summary_by_account_by_event_name |
·COUNT_STAR，SUM_TIMER_WAIT，MIN_TIMER_WAIT，AVG_TIMER_WAIT，MAX_TIMER_WAIT：这个列总括全体socket读写操作的次数和时间音信
qogir_env@localhost : performance_schema 03:51:36> show tables like 'events_statement%';
·prepare步骤：语法PREPARE stmt_name FROM preparable_stmt，示例：PREPARE stmt FROM'SELECT 1'; 推行了该语句之后，在prepared_statements_instances表中就能够查询到三个prepare示例对象了；
8rows inset (0.00sec)
OBJECT_SCHEMA: xiaoboluo
| events_statements_summary_by_user_by_event_name |
·OBJECT_SCHEMA：该锁来自于哪个库级其余指标；
本文首先，大约介绍了怎样是performance_schema？它能做什么样？
MIN_TIMER_READ: 0
qogir_env@localhost : performance_schema 03:13:22> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
|4| _platform |x86_64 | 4 |
INDEX_NAME: NULL
------- ------------- --------------------- -------------------
| events_statements_current |
SUM_LOCK_TIME: 0
| setup_instruments |
1 row in set (0.00 sec)
qogir_env@localhost : performance_schema 04:23:52> SELECT * FROM events_waits_current limit 1G
4.套接字事件总计
| memory_summary_by_user_by_event_name |
MIN_TIMER_READ: 15213375
| events_waits_history_long |
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;
----------- ---------- ------------------------------------------ ------------
·rwlock_instances：wait sync相关的lock对象实例；
| setup_actors |
·当互斥体被灭绝时，从mutex_instances表中剔除相应的排外体行。
| /home/mysql/program/share/english/errmsg.sys |wait/io/file/sql/ERRMSG
大家先来探视表中记录的总括音讯是什么体统的。
| /data/mysqldata1/mydata/mysql/engine_cost.ibd |wait/io/file/innodb/innodb_data_file | 3 |
socket_instances表不一致意利用TRUNCATE TABLE语句。
-------------------- --------- ---------------------------------------------------------------- -------------- ------ ------------
·EVENT_NAME：生成事件消息的instruments 名称。与setup_instruments表中的NAME值对应；
| events_waits_summary_by_thread_by_event_name |
* 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操作的多少字节数 ；
----------------------------------------------------
hosts表字段含义如下：
NESTING_EVENT_ID: NULL
笔者们先来探视表中著录的总括音信是何许体统的。
蹲点文件系统层调用的表：
1row inset ( 0. 00sec)
| /data/mysqldata1/undo/undo004 |wait/io/file/innodb/innodb_data_file | 3 |
·session_account_connect_attrs：记录当前对话及其相关联的别的会话的延续属性；
| Tables_in_performance_schema (%transaction%) |
·WRITE_LOCKED_BY_THREAD_ID：当多个线程当前在独占（写入）情势下持有一个rwlock时，WCRUISERITE_LOCKED_BY_THREAD_ID列能够查阅到持有该锁的线程THREAD_ID，若无被其余线程持有则该列为NULL；
---------------------------------------- ----------------
·OBJECT_INSTANCE_BEGIN：instruments对象的内部存款和储蓄器地址；
performance_schema= ON# 注意：该参数为只读参数，须求在实例运营在此之前设置才生效
| qfsys |10.10. 20.15| 1 |1|
- 提供了一种在数据库运转时实时检查server的内部试行情状的点子。performance_schema 数据库中的表使用performance_schema存款和储蓄引擎。该数据库珍视关切数据库运营进度中的质量相关的数额，与information_schema不同，information_schema首要关怀server启动进度中的元数据音信
- performance_schema通过监视server的风云来兑现监视server内部运营状态， “事件”即是server内部活动中所做的别的专门的职业以及相应的时间消耗，利用这么些音信来推断server中的相关财富消耗在了哪个地方？一般的话，事件能够是函数调用、操作系统的守候、SQL语句实施的级差（如sql语句实行进度中的parsing 或 sorting阶段）恐怕全部SQL语句与SQL语句聚积。事件的收集能够平价的提供server中的相关存款和储蓄引擎对磁盘文件、表I/O、表锁等财富的一路调用音讯。
- performance_schema中的事件与写入二进制日志中的事件（描述数据修改的events）、事件安顿调解程序（那是一种存款和储蓄程序）的风云不一样。performance_schema中的事件记录的是server实践有些活动对少数财富的成本、耗费时间、这一个移动实行的次数等状态。
- performance_schema中的事件只记录在地面server的performance_schema中，其下的那几个表中数据产生变化时不会被写入binlog中，也不会通过复制机制被复制到别的server中。
- 当下活蹦乱跳事件、历史事件和事件摘要相关的表中记录的音讯。能提供有个别事件的施行次数、使用时长。进而可用来深入分析有个别特定线程、特定对象（如mutex或file）相关联的活动。
- PERFORMANCE_SCHEMA存款和储蓄引擎使用server源代码中的“检查评定点”来兑现事件数量的采摘。对于performance_schema达成机制自己的代码未有有关的单独线程来检验，那与其余成效（如复制或事件安顿程序）不一致
- 访谈的风浪数量存款和储蓄在performance_schema数据库的表中。那一个表能够行使SELECT语句询问，也足以动用SQL语句更新performance_schema数据库中的表记录（如动态修改performance_schema的setup_*千帆竞发的几个布局表，但要注意：配置表的改造会及时生效，那会听得多了就能说的详细多少搜罗）
- performance_schema的表中的多寡不会持久化存款和储蓄在磁盘中，而是保存在内存中，一旦服务重视启，那一个数量会屏弃（包罗配置表在内的一体performance_schema下的具有数据）
- MySQL帮忙的有着平台南事件监察和控制功用都可用，但差异平高雄用来总括事件时间支付的电火花计时器类型大概会持有分化。
·OBJECT_INSTANCE_BEGIN：mutex instruments实例的内部存储器地址；
从上文中咱们曾经了然，performance_schema在5.7.x及其以上版本中暗许启用（5.6.x及其以下版本暗许关闭），假诺要显式启用或关闭时，大家需求使用参数performance_schema=ON|OFF设置，并在my.cnf中进行配置：
COUNT_STAR: 1
| events_statements_summary_by_thread_by_event_name |
2.表I/O等待和锁等待事件总计
| FILE_NAME |EVENT_NAME | OPEN_COUNT |
* 如果log_error_verbosity系统变量设置值大于1，则performance_schema还有大概会将错误音讯写入错误日志：
qogir_env@localhost : performance_schema 06:14:08> SELECT THREAD_ID,EVENT_ID,EVENT_NAME,TIMER_WAIT FROM events_waits_history ORDER BY THREAD_ID limit 21;
|TABLE | xiaoboluo |test | 140568038528544 |0| 0 |NULL | NULL |
----------- ---------- ------------------------------------------ ------------
·OWNER_THREAD_ID：诉求元数据锁的线程ID；
| events_transactions_current |
·当呼吁立时收获元数据锁时，将插入状态为GRANTED的锁新闻行；
------------------------------------------------
---------------- ----------------- ---------------- ------------------
| events_statements_summary_by_account_by_event_name |
OBJECT_SCHEMA: xiaoboluo
qogir_env@localhost : performance_schema 03:20:43> use performance_schema
套接字instruments具有wait/io/socket/sql/socket_type情势的名称，如下：
IT从业多年，历任运营技术员、高等运转技术员、运行CEO、数据库技术员，曾出席版本公布系统、轻量级监察和控制连串、运转管理平台、数据库管理平台的宏图与编辑，熟知MySQL种类布局，Innodb存款和储蓄引擎，喜好专研开源本领，追求完美。
·accounts：依照user@host的样式来对各样客户端的连年举办计算；
| /data/mysqldata1/mydata/mysql/innodb_index_stats.ibd |wait/io/file/innodb/innodb_data_file | 3 |
从上面表中的笔录音讯我们得以看出（与公事I/O事件总计类似，两张表也各自依据socket事件类型总计与服从socket instance实行计算）
--------------------------------------------------- ------------
......
----------------------------------------
session_account_connect_attrs表不允许行使TRUNCATE TABLE语句。
9rows inset (0.00sec)
* _os：客户端操作系统类型（比如Linux，Win64）
2.4. performance_schema轻松布署与使用
·READ_LOCKED_BY_COUNT：当一个线程在分享（读）形式下持有贰个rwlock时，READ_LOCKED_BY_COUNT列值扩大1，所以该列只是多个计数器，无法一直用于查找是哪些线程持有该rwlock，但它可以用来查看是不是留存一个有关rwlock的读争用以及查看当前有个别许个读形式线程处于活跃状态。
| events_statements_summary_by_program |
*************************** 1. row ***************************
| /data/mysqldata1/mydata/mysql/help_category.ibd |wait/io/file/innodb/innodb_data_file | 3 |
·当二个pending状态的锁被死锁检查实验器检查评定并选定为用于打破死锁时，这几个锁会被撤废，并回到错误音讯（EHaval_LOCK_DEADLOCK）给央求锁的对话，锁状态从PENDING更新为VICTIM；
***************************
* events_waits_current表中得以查看到当下正在等候互斥体的线程时间消息（比方：TIMEENVISION_WAIT列表示已经等候的小时） ；
3rows inset (0.01sec)
socket_instances表列出了接二连三到MySQL server的外向接连的实时快速照相消息。对于每一个连接到mysql server中的TCP/IP或Unix套接字文件连续都会在此表中著录一行音信。（套接字计算表socket_summary_by_event_name和socket_summary_by_instance中提供了一部分叠合音信，比如像socket操作以及网络传输和接到的字节数）。
| users |
|4| _os |linux-glibc2. 5| 0 |
------------------------------------------------
OBJECT _INSTANCE_BEGIN: 139968890586816
87rows inset (0.00sec)
OBJECT_TYPE: TABLE
---------------------------------------
·users：依照用户名对每种客户端连接实行总计。
| Tables_in_performance_schema (%wait%) |
我们先来探问表中著录的总括音讯是怎么着子的。
| events_stages_history_long |
-------------------------------------- ----------------------- ---------------------
| events_stages_current |
performance_schema通过如下表来记录相关的锁音讯：
1row inset (0.00sec)
应用程序能够运用部分键/值对转移一些连接属性，在对mysql server成立连接时传递给server。对于C API，使用mysql_options()和mysql_options4()函数定义属性集。其他MySQL连接器能够应用部分自定义连接属性方法。
| 4 |348| wait/io/file/innodb/innodb_log_file |693076224|
·HOST：某老是的客户端主机名。倘使是贰个里边线程创立的总是，或许是无力回天印证的用户创造的接连，则该字段为NULL；
|4| 349 |wait/synch/mutex/innodb/fil_system_mutex | 65664 |
table_handles表不容许选择TRUNCATE TABLE语句。
WHERE TABLE_SCHEMA ='performance_schema'andengine='performance_schema';
OPEN_COUNT：文件当前已开荒句柄的计数。假设文件展开然后关门，则打开1次，但OPEN_COUNT列将加一然后减一，因为OPEN_COUNT列只总结当前已展开的文本句柄数，已关闭的文本句柄会从中减去。要列出server中当前张开的持有文件音信，可以使用where WHERE OPEN_COUNT> 0子句进行查看。
---------------------------------------- ----------------
·对于Unix domain套接字（server_unix_socket）的server端监听器，端口为0，IP为空白；
OBJECT_TYPE: NULL
元数据锁instruments使用wait/lock/metadata/sql/mdl，暗许未开启。
说话事件记录表，那一个表记录了话语事件新闻，当前讲话事件表events_statements_current、历史语句事件表events_statements_history和长语句历史事件表events_statements_history_long、以及集聚后的摘要表summary，当中，summary表还能依据帐号(account)，主机(host)，程序(program)，线程(thread)，用户(user)和全局(global)再开始展览分割)
数据库对象总结表
8rows inset (0.00sec)
在服务器端面，会对再三再四属性数据进行长度检查：
------------------------------------------------------
......
|wait/io/file/sql/casetest | 104324715 |
table_io_waits_summary_by_table表：
| NO |NO | NO |
从客户端发送到服务器的连接属性数据量存在限制：客户端在接连在此之前客户端有一个本身的一定长度限制（不可配置）、在客户端连接server时服务端也可能有一个恒定长度限制、以及在客户端连接server时的总是属性值在存入performance_schema中时也会有二个可安插的长度限制。
|wait/synch/mutex/mysys/LOCK_alarm | 147 |
·对此已接受的总是，performance_schema根据performance_schema_session_connect_attrs_size系统变量的值检查总括连接属性大小。借使属性大小抢先此值，则会实践以下操作：
EVENT_NAME: wait/synch/mutex/innodb/log_sys_mutex
·INTERNAL_LOCK：在SQL等第使用的表锁。有效值为：READ、READ WITH SHARED LOCKS、READ HIGH PRIOHighlanderITY、READ NO INSERT、WHighlanderITE ALLOW W卡宴ITE、W兰德昂科雷ITE CONCUSportageRENT INSERT、WSportageITE LOW P中华VIO揽胜极光ITY、WEnclaveITE。有关这么些锁类型的详细新闻，请参阅include/thr_lock.h源文件；
SPINS: NULL
-------------------------------------- ----------------------- ---------------------
qogir_env@localhost : performance_schema 03:58:27> show tables like '%file%';
------------- --------------------- -------------------
|wait/io/file/sql/pid | 72591750 |
admin@localhost : performance _schema 01:57:20> select * from table_lock _waits_summary _by_table where SUM _TIMER_WAIT!=0G;
Rowsmatched: 3 Changed: 3 Warnings: 0
MIN_TIMER_WAIT: 1905016
| 0 |
table_lock_waits_summary_by_table表：
| events_stages_history |
* performance_schema截断抢先长度的属性数据，并追加Performance_schema_session_connect_attrs_lost状态变量值，截断三遍扩大二遍，即该变量表示连接属性被截断了略微次
qogir_env@localhost : performance_schema 06:27:26> SELECT * FROM file_instances limit 20;
STATEMENT_ID: 1
| cond_instances |
------------- --------------- ------------- ----------------------- ----------------- ---------------- --------------- ---------------
| /data/mysqldata1/mydata/mysql/help_topic.ibd |wait/io/file/innodb/innodb_data_file | 3 |
·socket_summary_by_event_name表：按照EVENT_NAME列进行分组
|PERFORMANCE_SCHEMA | YES |Performance Schema
table_handles表是只读的，不可能更新。暗许自动调度表数据行大小，要是要显式钦赐个，能够在server运转在此以前安装系统变量performance_schema_max_table_handles的值。
-----------------------------------------------
对应的instruments为wait/io/table/sql/handler和wait/lock/table/sql/handler，私下认可开启。
｜目 录1、什么是performance_schema
| 4 |program_name | mysql |5|
| /data/mysqldata1/mydata/mysql/server_cost.ibd |wait/io/file/innodb/innodb_data_file | 3 |
| NULL |41| 45 |
责编：
·已予以的锁（呈现怎会话具有当前元数据锁）；
| Engine |Support | Comment
COUNT_STAR: 33
| Tables_in_performance_schema (%stage%) |
# table_io_waits_summary_by_table表
| events_transactions_summary_by_user_by_event_name |
套接字事件总计了套接字的读写调用次数和出殡和埋葬接收字节计数音讯，socket事件instruments暗中同意关闭，在setup_consumers表中无具体的附和配置，包罗如下两张表：
| wait/synch/mutex/mysys/LOCK_alarm |145126935|
·OBJECT_TYPE：呈现handles锁的种类，表示该表是被哪些table handles展开的；
----------------------------------------------------
*************************** 1. row ***************************
| cond_instances |
| HOST |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |
......
7.锁指标志录表
-------------------- -------
------------------------------------ -------------------------------------- ------------
qogir_env@localhost : performance_schema 06:19:20> SELECT EVENT_NAME,SUM_TIMER_WAIT FROM events_waits_summary_global_by_event_name
· OBJECT_INSTANCE_BEGIN：instruments condition的内部存款和储蓄器地址；
| events_waits_history |
EVENT_NAME: wait/io/socket/sql/client_connection
-----------------------------------------
COUNT_READ_NORMAL: 0
------------------------------------------------------
* COUNT_STAR，SUM_TIMER_WAIT，MIN_TIMER_WAIT，AVG_TIMER_WAIT，MAX_TIMER_WAIT：这个列总结全体I/O操作数量和操作时间 ；
qogir_env@localhost : performance_schema 03:21:06> show tables from performance_schema;
STATEMENT_NAME: stmt
|performance_schema | ON |
·HOST：有个别连接的主机名，若是是三个里边线程创设的接连，也许是无力回天印证的用户成立的连接，则该字段为NULL；
| events_waits_current |
*************************** 1. row ***************************
ORDER BY COUNT_STAR DESC LIMIT 10;
同意实践TRUNCATE TABLE语句，然而TRUNCATE TABLE只是重新设置prepared_statements_instances表的总括信息列，不过不会去除该表中的记录，该表中的记录会在prepare对象被灭绝释放的时候自动删除。
| 15 |291| wait/synch/mutex/innodb/buf_dblwr_mutex |37392|
MAX _TIMER_READ: 56688392
|EVENT_NAME | SUM_TIMER_WAIT |
admin@localhost : performance_schema 02:53:40> select * from file_instances where OPEN_COUNT> 0limit 1;
------------------------------------------------------
·VICTIM，TIMEOUT和KILLED状态值停留时间不会细小略，当三个锁处于这一个场合时，那么表示该锁行消息将要被去除（手动实行SQL只怕因为日子原因查看不到，能够选用程序抓取）；
5rows inset (0.01sec)
三个老是可知的接连属性集合取决于与mysql server建构连接的客户端平台项目和MySQL连接的客户端类型。
qogir_env@localhost: performance_schema 03:34:40> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES'where name like 'wait%';;
两张表中记录的剧情很相近：
OBJECT_SCHEMA: NULL
OBJECT _INSTANCE_BEGIN: 2658003840
2.1. 反省当前数据库版本是还是不是扶助
·prepare语句施行：为已检测的prepare语句实例实施COM_STMT_EXECUTE或SQLCOM_PREPARE命令，同时会更新prepare_statements_instances表中对应的行消息。
-------------------- --------- ---------------------------------------------------------------- -------------- ------ ------------
OBJECT _INSTANCE_BEGIN: 140568048055488
| 4 |342| wait/synch/mutex/innodb/fil_system_mutex |32832|
-----------------------------------------------
summary表提供全体事件的集中国国投息。该组中的表以分歧的艺术集中事件数量（如：按用户，按主机，按线程等等）。比如：要查看哪些instruments占用最多的时间，可以透过对events_waits_summary_global_by_event_name表的COUNT_STAR或SUM_TIMER_WAIT列实行询问（这两列是对事件的记录数执行COUNT（*）、事件记录的TIMEPRADO_WAIT列执行SUM（TIMER_WAIT）总计而来），如下：
与objects_summary_global_by_type 表总结新闻类似，表I/O等待和锁等待事件总计新闻越来越精致，细分了每一种表的增加和删除改查的实行次数，总等待时间，最小、最大、平均等待时间，乃至精细到有个别索引的增加和删除改查的等候时间，表IO等待和锁等待事件instruments（wait/io/table/sql/handler和wait/lock/table/sql/handler ）暗许开启，在setup_consumers表中无具体的应和配置，暗中同意表IO等待和锁等待事件统计表中就能够计算有关事件信息。包涵如下几张表：
直接在performance_schema库下选取show tables语句来查看有怎么样performance_schema引擎表：
·NAME：与互斥体关联的instruments名称；
等第事件记录表，记录语句施行的品级事件的表，与话语事件类型的连带记录表类似：
那几个消息使您能够领会会话之间的元数据锁信赖关系。不仅可以够观望会话正在等待哪个锁，仍是能够见到眼下颇具该锁的会话ID。
[mysqld]
| FILE_NAME |EVENT_NAME | OPEN_COUNT |
开辟等待事件的收集器配置项开关，供给修改setup_instruments 配置表中对应的采撷器配置项
table_handles表字段含义如下：
qogir_env@localhost : performance_schema 06:17:23> SELECT EVENT_NAME,COUNT_STAR FROM events_waits_summary_global_by_event_name
......
OBJECT_NAME: NULL
1row inset ( 0. 00sec)
| 13 |2259| wait/synch/mutex/innodb/fil_system_mutex |8708688|
·file_instances：文件对象实例；
| events_waits_summary_by_account_by_event_name |
·USELAND：某接二连三的客户端用户名。倘使是一个里头线程创立的再而三，恐怕是无力回天验证的用户创设的连天，则该字段为NULL；
------------------------------------------------------
AVG_TIMER_READ_NORMAL: 0
|wait/io/file/sql/FRM | 1292823243 |
·对此由此TCP/IP 套接字（client_connection）的客户端连接，端口是server随机分配的，但不会为0值. IP是源主机的IP（127.0.0.1或本地主机的:: 1）。
| wait/synch/mutex/sql/LOCK_global_system_variables |89|
-------------------------------------- ----------------------- ---------------------
-------------------- --------- -------------------- -------------- ------ ------------
SUM_TIMER_READ: 0
|wait/synch/mutex/mysys/THR_LOCK_malloc | 1530083250 |
OWNER_EVENT_ID: 54
qogir_env@localhost : performance_schema 03:13:10> SHOW VARIABLES LIKE 'performance_schema';
AVG _TIMER_WAIT: 56688392
21 rows inset (0.00 sec)
root@localhost : performance _schema 05:11:45> select * from socket_summary _by_instance where COUNT_STAR!=0G;
END_EVENT_ID: 60
-------------------------------------------------
| events_transactions_summary_by_thread_by_event_name |
* _client_name：客户端名称（客户端库的libmysql）
| events_stages_summary_by_host_by_event_name |
------- ------------- --------------------- -------------------
2.2. 启用performance_schema
Performance Schema通过metadata_locks表记录元数据锁新闻：
| /data/mysqldata1/innodb_log/ib_logfile1 |wait/io/file/innodb/innodb_log_file | 2 |
* 复制slave连接的program_name属性值被定义为mysqld、定义了_client_role属性，值为binary_log_listener、_client_replication_channel_name属性，值为坦途名称字符串
| file_instances |
*************************** 2. row ***************************
| events_waits_summary_by_instance |
rwlock_instances表列出了server实施rwlock instruments时performance_schema所见的兼具rwlock（读写锁）实例。rwlock是在代码中使用的一路机制，用于强制在给定时期内线程能够遵从有个别法规访谈一些公共财富。可以以为rwlock珍重着这几个财富不被别的线程随便抢占。访谈形式能够是分享的（多少个线程能够同一时间全数分享读锁）、排他的（同时唯有四个线程在加以时间足以具有排他写锁）或分享独占的（有个别线程持有排他锁定期，同期允许其余线程试行不同性读）。共享独占采访被称为sxlock，该访谈情势在读写场景下能够增长并发性和可扩充性。
TIMER_START: 1582395491787124480
* _runtime_version：Java运维条件（JRE）版本
| /data/mysqldata1/innodb_ts/ibdata1 |wait/io/file/innodb/innodb_data_file | 3 |
·依赖于连接表中国国投息的summary表在对这一个连接表试行truncate时会同临时候被隐式地实行truncate，performance_schema维护着依照accounts，hosts或users总计各类风浪总结表。那个表在称呼包含：_summary_by_account，_summary_by_host，*_summary_by_user
qogir_env@localhost : performance_schema 03:58:38> show tables like '%memory%';
| NAME |OBJECT_INSTANCE_BEGIN | LOCKED_BY_THREAD_ID |
------------------------------------------------------
4 rows in set (0.00 sec)
依据事件类型分组记录品质事件数量的表
admin@localhost : performance_schema 03:23:47> select * from mutex_instances limit 1;
| /data/mysqldata1/mydata/mysql/plugin.ibd |wait/io/file/innodb/innodb_data_file | 3 |
OBJECT_NAME: test
-------------------- -------
| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |
NUMBER_OF_BYTES: NULL
*************************** 1. row ***************************
PS：本种类小说所选择的数据库版本为 MySQL 官方 5.7.17版本
·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列实行分组
performance_schema达成机制遵守以下设计目的：
PS：什么是prepare语句？prepare语句其实正是四个预编写翻译语句，先把SQL语句实行编写翻译，且可以设定参数占位符（比如：?符号），然后调用时经过用户变量传入具体的参数值（叫做变量绑定），假如二个说话供给频仍实践而仅仅只是where条件分歧，那么使用prepare语句能够大大减弱硬分析的费用，prepare语句有八个步骤，预编写翻译prepare语句，实行prepare语句，释放销毁prepare语句，prepare语句援救三种协议，前边已经涉嫌过了，binary协议一般是提须求应用程序的mysql c api接口格局访问，而文本协议提供给通过客户端连接到mysql server的方法访谈，下边以文件协议的法子访问进行自己要作为表率遵循规则验证：
| 0 |
（2）file_instances表
现行反革命，我们精晓了在 MySQL 5.7.17 版本中，performance_schema 下一同有87张表，那么，那87帐表都以贮存什么数据的啊？咱们什么样采纳他们来询问我们想要查看的多寡吧？先别焦急，大家先来探望那么些表是哪些分类的。
SUM _TIMER_READ _WITH_SHARED_LOCKS: 0
12rows inset (0.01sec)
表字段含义与session_account_connect_attrs表一样，可是该表是保留全数连接的连年属性表。
qogir_env@localhost: performance_schema 04:23:40> UPDATE setup_consumers SET ENABLED = 'YES'where name like '%wait%';
mutex_instances.LOCKED_BY_THREAD_ID和rwlock_instances.WRITE_LOCKED_BY_THREAD_ID列对于排查品质瓶颈或死锁难点首要。
以后，你能够在performance_schema下选拔show tables语句只怕经过询问 INFORMATION_SCHEMA.TABLES表中performance_schema引擎相关的元数据来询问在performance_schema下存在着怎么样表：
3rows inset ( 0. 00sec)
2.4. performance_schema不难安顿与利用
·已被死锁质量评定器检测到并被杀掉的锁，只怕锁诉求超时正在等候锁须要会话被撤消。
| /data/mysqldata1/mydata/mysql/help_keyword.ibd |wait/io/file/innodb/innodb_data_file | 3 |
INDEX_NAME: PRIMARY
# 该事件音信表示线程ID为4的线程正在等候innodb存款和储蓄引擎的log_sys_mutex锁，那是innodb存款和储蓄引擎的贰个互斥锁，等待时间为65664阿秒（*_ID列表示事件起点哪个线程、事件编号是稍稍；EVENT_NAME表示检查评定到的现实的剧情；SOURCE表示那一个检查实验代码在哪些源文件中以及行号；计时器字段TIME纳瓦拉_START、TIMER_END、TIMER_WAIT分别代表该事件的开始时间、停止时间、以及总的费用时间，如若该事件正在周转而从未终结，那么TIME哈弗_END和TIMER_WAIT的值展现为NULL。注：电火花计时器总括的值是相近值，实际不是截然标准）
上一篇 《事件总计 | performance_schema全方位介绍》详细介绍了performance_schema的风浪总结表，但这几个总括数据粒度太粗，仅仅依照事件的5大种类 用户、线程等维度举办分类总结，但神蹟大家必要从越来越细粒度的维度进行分拣总括，比如：有个别表的IO花费多少、锁成本多少、以及用户连接的一部分个性总计新闻等。此时就要求查阅数据库对象事件总结表与品质总括表了。前几日将指引大家共同踏上排山倒海第五篇的道路(全系共7个篇章)，本期将为大家无所不至授课performance_schema中指标事件总计表与质量计算表。上面，请跟随大家共同开始performance_schema系统的就学之旅吧~
| memory_summary_global_by_event_name |
下卷将为我们共享 《复制状态与变量记录表 | performance_schema全方位介绍》 ，多谢你的翻阅，大家不见不散！回去年今年日头条，查看越来越多
本篇内容到这里就附近尾声了，相信广大人皆感觉，大家当先四分之二时候并不会直接接纳performance_schema来查询质量数据，而是选用sys schema下的视图代替，为啥不直接攻读sys schema呢？那你理解sys schema中的数据是从哪个地方吐出来的呢？performance_schema 中的数据实际上首纵然从performance_schema、information_schema中获取，所以要想玩转sys schema，周全摸底performance_schema必不可缺。别的，对于sys schema、informatiion_schema乃至是mysql schema，大家三番伍次也会推出差别的三种作品分享给大家。
当客户端断开连接时，performance_schema将削减对应连接的行中的CUPAJERORENT_CONNECTIONS列，保留TOTAL_CONNECTIONS列值。
| wait/io/file/sql/MYSQL_LOG |1599816582|
------------------------------------------------
| wait/io/file/sql/FRM |452|
---------------------------------------- ----------------------- ----------- ----------- -------------------- ------- --------
| wait/synch/mutex/sql/THD::LOCK_thd_data |115|
EVENT_NAME: wait/io/file/innodb/innodb_data_file
EVENT_ID: 60
| NAME |OBJECT_INSTANCE_BEGIN |
NESTING_EVENT_TYPE: NULL
MAX_TIMER_READ: 0
QueryOK, 0 rowsaffected(0.00sec)
COUNT_STAR: 1
| EVENT_NAME |COUNT_STAR |
3.文件I/O事件总括
出品：沃趣科学和技术
| 10.10.20.15 |1| 1 |
伺机事件记录表，与话语事件类型的相关记录表类似：
| wait/io/socket/sql/client_connection |110668160 | 46 |53| |0| ACTIVE |
| events_transactions_summary_global_by_event_name |
2rows inset ( 0. 00sec)
| TABLE_NAME |
14 rows inset (0.01 sec)
----------------------------------------------------
performance_schema怎样保管metadata_locks表中记录的内容(使用LOCK_STATUS列来代表每一个锁的场地）：
|wait/synch/mutex/mysys/THR_LOCK_malloc | 6419 |
文件I/O事件总计表允许利用TRUNCATE TABLE语句。但只将总结列重新初始化为零，并非剔除行。
| Tables_in_performance_schema (%file%) |
EVENT_NAME: wait/io/socket/sql/server_unix_socket
原标题：初相识｜performance_schema全方位介绍（一）
·OBJECT_INSTANCE_BEGIN：此列是套接字实例对象的独一标志。该值是内部存款和储蓄器中对象的地址；
performance_schema库下的表可以依据监视区别的纬度实行了分组，比如：或根据不一致数据库对象开始展览分组，或依据分裂的事件类型实行分组，或在根据事件类型分组之后，再进一步依据帐号、主机、程序、线程、用户等，如下：
| socket_summary_by_instance |
| events_transactions_summary_by_account_by_event_name |
·SOCKET_ID：分配给套接字的里边文件句柄；
----------------------------------------
·TOTAL_CONNECTIONS：某帐号的总连接数（新添二个连接累计四个，不会像当前连接数那样连接断开会减少）。
前段时间，大家曾经大概知道了performance_schema中的主要表的归类，但，怎么着行使他们来为大家提供需求的质量事件数量吧？上边，大家介绍怎么样通过performance_schema下的配备表来配置与行使performance_schema。
OBJECT_NAME: test
- 启用performance_schema不会促成server的行事发生变化。举个例子，它不会改动线程调节机制，不会形成查询施行安插（如EXPLAIN）产生变化
- 启用performance_schema之后，server会持续不间断地监测，开支非常的小。不会导致server不可用
- 在该兑现机制中未有扩展新的机要字或言辞，分析器不会转换
- 即使performance_schema的监测机制在里面前遇到某一件事件实行监测失利，也不会默转潜移server符合规律运作
- 假如在起来搜集事件数量时遇见有任何线程正在针对那些事件音讯举办查询，那么查询会优先试行事件数量的搜集，因为事件数量的搜罗是多少个持续不断的经过，而寻觅(查询)那个事件数量仅仅只是在必要查阅的时候才开始展览搜寻。也说不定有个别事件数量永世都不会去追寻
- 亟待很轻便地增添新的instruments监测点
- instruments(事件访谈项)代码版本化：借使instruments的代码发生了变动，旧的instruments代码还能持续做事。
- 专注：MySQL sys schema是一组对象（包涵有关的视图、存款和储蓄进程和函数），可以平价地寻访performance_schema搜聚的数目。同一时候招来的数目可读性也更加高(举例：performance_schema中的时间单位是微秒，经过sys schema查询时会转换为可读的us,ms,s,min,hour,day等单位)，sys schem在5.7.x版本私下认可安装
| OBJECT_TYPE |OBJECT_SCHEMA | OBJECT_NAME |OBJECT_INSTANCE_BEGIN | OWNER_THREAD_ID |OWNER_EVENT_ID | INTERNAL_LOCK |EXTERNAL_LOCK |
当今，很欢娱的告诉大家，我们依照 MySQL 官方文书档案加上大家的证实，整理了一份能够系统学习 performance_schema 的资料分享给大家，为了有助于我们阅读，大家整理为了贰个二种，一共7篇小说。上面，请跟随大家一齐起来performance_schema系统的上学之旅吧。
·已呼吁但未予以的锁（显示怎会话正在等候哪些元数据锁）；
连日来属性记录在如下两张表中：
“翻过那座山，你就能够见到一片海”
------------------------------------------------------- ----------------------- --------------------------- ----------------------
下卷将为大家分享"performance_schema之二(配置表详解)" ，多谢您的阅读，大家不见不散！重临天涯论坛，查看越来越多
·server只接受的总是属性数据的计算大小限制为64KB。假诺客户端尝试发送当先64KB(正好是三个表全部字段定义长度的总限制长度)的属性数据，则server将不容该连接；
|4| 343 |wait/io/file/innodb/innodb_log_file | 544126864 |
·各样文件I/O事件总括表有如下总括字段：
| events_stages_summary_by_thread_by_event_name |
·当多少个线程尝试获得已经被某些线程持有的互斥体时，在events_waits_current表中会彰显尝试获得那个互斥体的线程相关等待事件音信，突显它正值守候的mutex 种类（在EVENT_NAME列中能够看到），并出示正在守候的mutex instance（在OBJECT_INSTANCE_BEGIN列中得以见见）；
当我们看到PEKoleosFORMANCE_SCHEMA 对应的Support 字段输出为YES时就象征大家日前的数据库版本是支撑performance_schema的。但敞亮我们的实例支持performance_schema引擎就足以选取了啊？NO，很不满，performance_schema在5.6及其以前的本子中，私下认可未有启用，从5.7会同之后的版本才修改为暗中同意启用。现在，我们来探视如何设置performance_schema默许启用吧！
| Tables_in_performance_schema (%file_summary%) |
11rows inset (0.00sec)
* 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操作未有字节计数新闻。
20rows inset (0.00sec)
OBJECT _INSTANCE_BEGIN: 2655350784
使用 INFORMATION_SCHEMA.ENGINES表来询问你的数据库实例是或不是协助INFORMATION_SCHEMA引擎
FILE_NAME: /data/mysqldata1/innodb_ts/ibdata1
| setup_objects |
*************************** 1. row ***************************
# 那一个结果证明，TH讴歌RDX_LOCK_malloc互斥事件是最热的。注：TH昂Cora_LOCK_malloc互斥事件仅在DEBUG版本中存在,GA版本不设有
·STATEMENT_NAME：对于二进制协议的讲话事件，此列值为NULL。对于文本协议的话语事件，此列值是用户分配的外表语句名称。举个例子：PREPARE stmt FROM'SELECT 1';，语句名字为stmt。
------------------------------------------------------ -------------------------------------- ------------
admin@localhost : performance_schema 02:50:02> select * from cond_instances limit 1;
| events_transactions_history_long |
COUNT_STAR: 802
|13| 2260 |wait/synch/mutex/innodb/buf_pool_mutex | 111264 |
OBJECT_SCHEMA: xiaoboluo
......
·ORDINAL_POSITION：将三番五次属性加多到连年属性集的逐条。
---------------------------------------- ----------------
......
Rowsmatched: 323 Changed: 0 Warnings: 0
* _pid：客户端进度ID
| wait/synch/mutex/sql/LOCK_open |88|
·OBJECT_INSTANCE_BEGIN：instruments对象的内部存款和储蓄器地址；
87rows inset (0.00sec)
| wait/io/socket/sql/client_connection |110667840 | 45 |51| ::ffff:10.10.20.15 |56842| ACTIVE |
-------------------- -------
file_instances表列出推行文书I/O instruments时performance_schema所见的有着文件。 如若磁盘上的文书未有打开，则不会在file_instances中著录。当文件从磁盘中剔除时，它也会从file_instances表中删去相应的记录。
| events_statements_history_long |
------------------------------------ -------------------------------------- ------------
1row inset (0.00sec)
当客户端与server端建构连接时，performance_schema使用符合种种表的独一标志值来分明每种连接表中怎样开展记录。借使缺少对应标记值的行，则新扩张加一行。然后，performance_schema会大增该行中的CU景逸SUVRENT_CONNECTIONS和TOTAL_CONNECTIONS列值。
| /data/mysqldata1/mydata/mysql/help_relation.ibd |wait/io/file/innodb/innodb_data_file | 3 |
·LOCK_TYPE：元数据锁子系统中的锁类型。有效值为：INTENTION_EXCLUSIVE、SHARED、SHARED_HIGH_PRIO、SHARED_READ、SHARED_WRITE、SHARED_UPGRADABLE、SHARED_NO_WRITE、SHARED_NO_READ_WRITE、EXCLUSIVE；
qogir_env@localhost : performance_schema 03:55:07> show tables like 'events_stage%';
PS：对于mutexes、conditions和rwlocks，在运营时尽管允许修改配置，且布局能够修改成功，然而有部分instruments不见效，必要在运维时配置才会卓有成效，如果您品尝着使用一些行使场景来追踪锁音讯，你也许在那几个instance表中不或许查询到对应的音讯。
| events_stages_summary_global_by_event_name |
大家先来探访表中著录的计算音信是何许样子的。
| /data/mysqldata1/undo/undo003 |wait/io/file/innodb/innodb_data_file | 3 |
OBJECT_TYPE: TABLE
---------------------------------------
基于央求锁的线程数以及所诉求的锁的品质，访谈格局有：独占方式、分享独占情势、分享格局、或许所央求的锁不能够被全部予以，必要先等待别的线程达成并释放。
| file_summary_by_instance |
EVENT_NAME: wait/io/socket/sql/server_unix_socket
| Tables_in_performance_schema (%memory%) |
admin@localhost : performance_schema 06:48:12> show tables like '%file_summary%';
| /data/mysqldata1/innodb_log/ib_logfile0 |wait/io/file/innodb/innodb_log_file | 2 |
·table_handles：表锁的有着和央求记录。
| /home/mysql/program/share/charsets/Index.xml |wait/io/file/mysys/charset
咱俩先来寻访表中记录的总结音讯是怎么体统的。
THREAD_ID: 4
3rows inset ( 0. 00sec)
|wait/io/file/myisam/dfile | 322401645 |
·hosts：根据host名称对各样客户端连接实行计算；
工作事件记录表，记录事务相关的风浪的表，与话语事件类型的相干记录表类似：
1 row in set (0.00 sec)
-----------------------------------------------
*************************** 2. row ***************************
2.3. performance_schema表的分类
天性总结表
|13| 2261 |wait/synch/mutex/innodb/flush_list_mutex | 122208 |
6.instance 统计表
-----------------------------------------
COUNT_STAR: 2560
-------------------- --------- -------------------- -------------- ------ ------------
·SUM_xxx：其余的SUM_xxx初始的列与语句总括表中的音讯一致，语句总括表后续章节会详细介绍。
下一场，简介了哪些快速上手使用performance_schema的方法；
OWNER _EVENT_ID: 49
TIMER_WAIT: 65664
作者们先来探视表中著录的总结音信是什么体统的。
| accounts |
SUM_ROWS_SENT: 0
_current表中各样线程只保留一条记下，且倘使线程完结专门的职业，该表中不会再记录该线程的平地风波消息，_history表中著录各类线程已经推行到位的风浪音信，但各种线程的只事件信息只记录10条，再多就可以被遮住掉，*_history_long表中著录全数线程的事件新闻，但总记录数据是10000行，超越会被遮蔽掉，以后我们查看一下历史表events_waits_history 中记录了何等：
---------------------------------- -----------------------
终极，简要介绍了performance_schema中由哪些表组成，这几个表大概的功用是什么。
------------------------------------------------------- ----------------------- --------------------------- ----------------------
root@localhost : performance_schema 12:18:46> show tables like '%setup%';
hosts表满含客户端连接到MySQL server的主机信息，一个主机名对应一行记录，该表针对主机作为独一标志实行计算当前连接数和总连接数。server运维时，表的深浅会活动调节。 要显式设置该表大小，能够在server运维在此之前设置系统变量performance_schema_hosts_size的值。假设该变量设置为0，则象征禁止使用hosts表计算音讯。
| events_statements_summary_by_host_by_event_name |
套接字计算表允许选拔TRUNCATE TABLE语句(除events_statements_summary_by_digest之外)，只将计算列重新初始化为零，并不是去除行。
| setup_timers |
·prepare语句预编译：COM_STMT_PREPARE或SQLCOM_PREPARE命令在server中创设三个prepare语句。假使语句检查实验成功，则会在prepared_statements_instances表中新增加加一行。假如prepare语句不可能检验，则会加多Performance_schema_prepared_statements_lost状态变量的值。
｜2、performance_schema使用便捷入门
file_instances表字段含义如下：
| events_waits_summary_by_user_by_event_name |
mutex_instances表字段含义如下：
qogir_env@localhost : performance_schema 02:41:54> show engines;
1 rows in set (0.00 sec)
----------------------------------------
| PROCESSLIST_ID |ATTR_NAME | ATTR_VALUE |ORDINAL_POSITION |
|4| 341 |wait/synch/mutex/innodb/fil_system_mutex | 84816 |
该表允许采取TRUNCATE TABLE语句。只将总括列重新恢复设置为零，并非剔除行。该表实行truncate时也会隐式触发table_io_waits_summary_by_table表的truncate操作。别的利用DDL语句改动索引结构时，会招致该表的保有索引总括新闻被重新恢复设置
| memory_summary_by_thread_by_event_name |
SUM_TIMER_WAIT: 412754363625
------------------------------------------------------
MAX_TIMER_WAIT: 9498247500
| wait/synch/mutex/sql/LOCK_plugin |86027823|
OBJECT_SCHEMA: xiaoboluo
｜导 语相当久从前，当自个儿还在品味着系统地球科学习performance_schema的时候，通过在网络各个寻找资料实行学习，但很可惜，学习的功效并非很醒目，相当多标称类似 "深入显出performance_schema" 的稿子，基本上都以这种动不动就贴源码的作风，然后深刻了将来却出不来了。对系统学习performance_schema的作用有限。
file_instances表不相同意利用TRUNCATE TABLE语句。
| variables_by_thread |
OWNER_OBJECT_TYPE: NULL
|PERFORMANCE_SCHEMA | YES |Performance Schema | NO |NO | NO |
·OBJECT_NAME：instruments对象的称谓，表等第对象；
FLAGS: NULL
| 4 |_client_version | 5.7.18 |3|
动态对performance_schema实行布局的配置表：
大家先来寻访表中记录的总括信息是什么样体统的。
| variables_by_thread |
连年总结音讯表允许利用TRUNCATE TABLE。它会同期删除总括表中尚无连接的帐户，主机或用户对应的行，重新恢复设置有连日的帐户，主机或用户对应的行的并将其余行的CU奇骏RENT_CONNECTIONS和TOTAL_CONNECTIONS列值。
| /data/mysqldata1/mydata/mysql/gtid_executed.ibd |wait/io/file/innodb/innodb_data_file | 3 |
·当线程成功锁定（持有）互斥体时：
| Tables_in_performance_schema (%setup%) |
·PHP定义的习性正视于编写翻译的习性：
| THREAD_ID |EVENT_ID | EVENT_NAME |TIMER_WAIT |
admin@localhost : performance_schema 06:53:42> show tables like '%socket%summary%';
OPERATION: lock
---------------- ---------------------------------- --------------------- ------------------
运用show命令来查询你的数据库实例是还是不是扶助INFORMATION_SCHEMA引擎
·TOTAL_CONNECTIONS：某用户的总连接数。
------------------------------------------------------
SUM_ERRORS: 0
-------------------- --------- -------------------- -------------- ------ ------------
从表中的记录内容能够看出，根据库xiaoboluo下的表test进行分组，总结了表相关的等候事件调用次数，总括、最小、平均、最大延迟时间新闻，利用那么些新闻，大家能够概略驾驭InnoDB中表的探望成效排名总计情形，一定水平上反应了对存储引擎接口调用的频率。
| events_stages_summary_by_account_by_event_name |
|4| _pid |3766| 2 |
| 4 |350| wait/synch/mutex/innodb/log_sys_mutex |25536|
------- ------------- --------------------- -------------------
2.2. 启用performance_schema
EVENT_NAME: wait/io/socket/sql/client_connection
SOURCE: log0log.cc:1572
·file_summary_by_event_name：依照各种事件名称进行计算的公文IO等待事件
| events_statements_summary_by_digest |
| /data/mysqldata1/innodb_ts/ibdata1 |wait/io/file/innodb/innodb_data_file | 3 |
2、performance_schema使用便捷入门
5.prepare语句实例总计表
|wait/io/file/myisam/kfile | 102 |
2rows inset ( 0. 00sec)
| /data/mysqldata1/mydata/multi_master/test.ibd |wait/io/file/innodb/innodb_data_file | 1 |
·OBJECT_SCHEMA：该锁来自于哪个库品级的靶子；
| file_summary_by_event_name |
---------------------------------------- ----------------------- ----------- ----------- -------------------- ------- --------
instance表记录了何等类型的靶子会被检查实验。那些指标在被server使用时，在该表上将会产生一条事件记录，譬如，file_instances表列出了文本I/O操作及其关联文件名：
| table_lock_waits_summary_by_table |# 遵照每种表举办总结的表锁等待事件
------------------------------------------------------ -------------------------------------- ------------
| 4 |_client_name | libmysql |1|
| wait/io/file/myisam/kfile |411193611|
| socket_summary_by_event_name |
ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;
* 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字段，用于记录具体的磁盘文件有关消息。
| events_statements_summary_global_by_event_name |
| NULL |41| 45 |
| setup_consumers |
*************************** 1. row ***************************
蹲点内部存款和储蓄器使用的表：
·OBJECT_INSTANCE_BEGIN：读写锁实例的内部存款和储蓄器地址；
qogir_env@localhost : performance_schema 03:55:30> show tables like 'events_transaction%';
·NAME：与rwlock关联的instruments名称；
|wait/synch/mutex/sql/LOCK_plugin | 337 |
............
---------------------------------------
AVG _TIMER_WAIT: 3496961251500
......
session_account_connect_attrs表仅满含当前接连及其相关联的其余总是的连年属性。要翻开全部会话的总是属性，请查看session_connect_attrs表。
QueryOK, 3 rowsaffected(0.04sec)
SUM _TIMER_READ: 56688392
张开等待事件的保存表配置按钮，修改修改setup_consumers 配置表中对应的陈设i向
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;
| events_waits_summary_global_by_event_name |
MAX_TIMER_READ: 9498247500
该表允许选取TRUNCATE TABLE语句。只将总计列重新载入参数为零，并非删除行。
对于代码中的每一个互斥体，performance_schema提供了以下音信：
-------------------------------------------------
·file_summary_by_instance：遵照每一个文件实例(对应现实的各类磁盘文件，举例：表sbtest1的表空间文件sbtest1.ibd)实行总计的文本IO等待事件
LOCK_TYPE: SHARED_READ
AVG_TIMER_EXECUTE: 0
1row inset ( 0. 00sec)
performance_schema提供了针对性prepare语句的督察记录，并根据如下方法对表中的内容进行田间管理。
AVG_TIMER_WAIT: 514656000
| qfsys |1| 1 |
admin@localhost : performance_schema 06:50:03> show tables like '%table%summary%';
·socket_summary_by_instance：针对各样socket实例的持有 socket I/O操作，那一个socket操作相关的操作次数、时间和出殡和埋葬接收字节音信由wait/io/socket/* instruments发生。但当连接中断时，在该表中对应socket连接的音信就要被去除（这里的socket是指的当前活蹦乱跳的接连创设的socket实例）
------- --------------------- -------------------
admin@localhost : performance_schema 10:49:34> select * from socket_instances;
·COUNT_MISC，SUM_TIMER_MISC，MIN_TIMER_MISC，AVG_TIMER_MISC，MAX_TIMER_MISC：这个列总计了全部别的套接字操作，如socket的CONNECT、LISTEN，ACCEPT、CLOSE、SHUTDOWN类型操作。注意：这一个操作未有字节计数
COUNT_STAR: 56
......
OBJECT _INSTANCE_BEGIN: 2658004160
rwlock_instances表字段含义如下：
1row inset ( 0. 00sec)
PS：socket总结表不会总括空闲事件生成的等候事件新闻，空闲事件的守候音讯是记录在伺机事件计算表中进行总结的。
SUM _TIMER_WAIT: 195829830101250
·LOCK_STATUS：元数据锁子系统的锁状态。有效值为：PENDING、GRANTED、VICTIM、TIMEOUT、KILLED、PRE_ACQUIRE_NOTIFY、POST_RELEASE_NOTIFY。performance_schema依据区别的级差更换锁状态为这一个值；
大家先来拜见表中记录的总结消息是什么体统的。
OWNER _THREAD_ID: 46
·CURRENT_CONNECTIONS：某帐号的当前连接数；
MIN_TIMER_READ_NORMAL: 0
·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从闲暇状态切换成活动状态，并上升套接字连接的流年搜集功能。
·LOCKED_BY_THREAD_ID：当三个线程当前抱有贰个排斥锁按时，LOCKED_BY_THREAD_ID列显示全部线程的THREAD_ID，若无被其它线程持有，则该列值为NULL。
[Warning] Connection attributes oflength N were truncated
| Tables_in_performance_schema (%table%summary%) |
admin@localhost : performance _schema 01:55:49> select * from table_io _waits_summary _by_index _usage where SUM_TIMER_WAIT!=0G;
咱俩先来会见表中记录的总计新闻是何许体统的。
·SQL_TEXT：prepare的讲话文本，带“？”的意味是占位符标志，后续execute语句能够对该标识进行传参。
| table_io_waits_summary_by_index_usage |# 依照每一个索引进行计算的表I/O等待事件
上面临这一个表分别展开认证。
EVENT_NAME: wait/io/file/innodb/innodb_data_file
COUNT _READ_WITH _SHARED_LOCKS: 0
| USER |HOST | CURRENT_CONNECTIONS |TOTAL_CONNECTIONS |
1 row in set (0.00 sec)
·当监听套接字检查测量检验到三番五次时，srever将接连转移给二个由独立线程管理的新套接字。新连接线程的instruments具备client_connection的socket_type值，组成对应的instruments名称；
......
admin@localhost : performance _schema 11:10:42> select * from objects_summary _global_by _type where SUM_TIMER_WAIT!=0G;
MIN_TIMER_WAIT: 0
| localhost |1| 1 |
# table_lock_waits_summary_by_table表
·MySQL Connector/Net定义了之类属性：
* FEDERATED存款和储蓄引擎连接的program_name属性值被定义为mysqld、定义了_client_role属性，值为federated_storage
AVG_TIMER_READ: 530278875
4rows inset ( 0. 00sec)
1 row in set (0.00 sec)
3 rows in set (0.00 sec)
prepared_statements_instances表字段含义如下：
·OBJECT_TYPE：元数据锁子系统中利用的锁类型（类似setup_objects表中的OBJECT_TYPE列值）：有效值为：GLOBAL、SCHEMA、TABLE、FUNCTION、PROCEDURE、T奔驰M级IGGELacrosse（当前未选取）、EVENT、COMMIT、USE猎豹CS6LEVEL LOCK、TABLESPACE、LOCKING SE奔驰M级VICE，USEHaval LEVEL LOCK值表示该锁是使用GET_LOCK()函数获取的锁。LOCKING SEWranglerVICE值表示使用锁服务获得的锁；
admin@localhost : performance_schema 11:05:51> select * from session_connect_attrs;
......
- END -
（5） socket_instances表
该表的分组列与table_io_waits_summary_by_table表相同
COUNT_EXECUTE: 0
·EXTERNAL_LOCK：在仓库储存引擎等级使用的表锁。有效值为：READ EXTEHighlanderNAL、W汉兰达ITE EXTE奥迪Q3NAL。
1 row in set (0.00 sec)
metadata_locks表是只读的，不能立异。暗中认可保留行数会自行调治，固然要安顿该表大小，能够在server运营从前设置系统变量performance_schema_max_metadata_locks的值。
*************************** 1. row ***************************
MySQL允许应用程序引进新的连年属性，然而以下划线（_）开头的本性名称保留供内部选择，应用程序不要成立这种格式的连天属性。以担保内部的连日属性不会与应用程序创制的连年属性相争辨。
（3）hosts表
AVG _TIMER_READ: 56688392
·rwlock_instances：查看当前rwlock行的一对锁音信（独占锁被哪些线程持有，分享锁被有个别个线程持有等）。
|NULL | NULL |41| 45 |
（4）rwlock_instances表
......
|wait/synch/cond/sql/COND_manager | 31903008 |
文本I/O事件总计表只记录等待事件中的IO事件(不包涵table和socket子连串)，文件I/O事件instruments私下认可开启，在setup_consumers表中无实际的对应配置。它涵盖如下两张表：
按照与table_io_waits_summary_by_table的分组列 INDEX_NAME列实行分组，INDEX_NAME有如下二种：
SUM_TIMER_WAIT: 62379854922
------------------------------------------------
·当有着互斥体的线程释放互斥体时，mutex_instances表中对应排斥体行的THREAD_ID列被涂改为NULL；
OBJECT _INSTANCE_BEGIN: 2655351104
performance_schema通过table_handles表记录表锁消息，以对当前种种张开的表所持有的表锁进行追踪记录。table_handles输出表锁instruments收集的故事情节。那几个新闻呈现server中已张开了什么样表，锁定方式是何等以及被哪些会话持有。
笔者们先来探视表中记录的计算音信是哪些体统的。
admin@localhost : performance _schema 10:50:38> select * from prepared_statements_instancesG;
·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读取数据的操作）相关的次数、时间、接收字节数等新闻
# socket_summary_by_event_name表
·当行音信中CU凯雷德RENT_CONNECTIONS 字段值大于0时，实行truncate语句不会去除这个行，TOTAL_CONNECTIONS字段值被重新设置为CU瑞虎RENT_CONNECTIONS字段值；
·PORT：TCP/IP端口号，取值范围为0〜65535；
---------------------------------- -----------------------
TIMER_PREPARE: 896167000
·当server中有的代码成立了贰个互斥量时，在mutex_instances表中会增加一行对应的互斥体音信（除非相当小概再成立mutex instruments instance就不会加多行）。OBJECT_INSTANCE_BEGIN列值是互斥体的唯一标记属性；
这一个连接表都允许使用TRUNCATE TABLE语句：
·libmysqlclient客户端库（在MySQL和MySQL Connector / C发行版中提供）提供以下属性：
OBJECT_TYPE: TABLE
| wait/io/socket/sql/server_unix_socket |110667520| 1 |34| |0| ACTIVE |
· 对于通过Unix domain套接字（client_connection）的客户端连接，端口为0，IP为空白；
大家先来探访表中记录的总括消息是何许体统的。
·OWNER_EVENT_ID：央求元数据锁的风云ID。
* 使用libmysqlclient编写翻译：php连接的属性集结使用标准libmysqlclient属性，参见上文
------- --------------------- -------------------
-----------------------------------------------
mutex_instances表列出了server奉行mutex instruments时performance_schema所见的保有互斥量。互斥是在代码中利用的一种共同机制，以强制在给定期期内独有三个线程能够访谈一些公共财富。能够以为mutex爱护着这个集体能源不被随机抢占。
......
socket_instances表字段含义如下：
·LOCK_DURATION：来自元数据锁子系统中的锁定期间。有效值为：STATEMENT、TRANSACTION、EXPLICIT，STATEMENT和TRANSACTION值分别代表在讲话或工作甘休时会释放的锁。 EXPLICIT值表示能够在言语或作业甘休时被会保留，要求显式释放的锁，举例：使用FLUSH TABLES WITH READ LOCK获取的全局锁；
* _client_license：连接器许可证类型
通过对以下几个表实行查询，能够兑现对应用程序的监察或DBA能够检查测量检验到关系互斥体的线程之间的瓶颈或死锁新闻（events_waits_current能够查阅到当前正在等候互斥体的线程新闻，mutex_instances能够查看到眼下有些互斥体被哪些线程持有）。
EVENT_NAME: wait/io/socket/sql/server_tcpip_socket
---------------- ----------------- ---------------- ------------------
SUM _NUMBER_OF _BYTES_READ: 11567104
·STATEMENT_ID：由server分配的讲话内部ID。文本和二进制协议都利用该语句ID。
3rows inset ( 0. 00sec)
| NAME |OBJECT_INSTANCE_BEGIN | WRITE_LOCKED_BY_THREAD_ID |READ_LOCKED_BY_COUNT |
·server 监听二个socket以便为网络连接协议提供帮助。对于监听TCP/IP或Unix套接字文件接二连三来讲，分别有一个名叫server_tcpip_socket和server_unix_socket的socket_type值，组成对应的instruments名称；
·表面锁对应存款和储蓄引擎层中的锁。通过调用handler::external_lock()函数来贯彻。（官方手册上说有叁个OPERATION列来区分锁类型，该列有效值为：read external、write external。但在该表的概念上并不曾看到该字段)
从下面表中的笔录消息我们得以看来：
|wait/synch/rwlock/session/LOCK_srv_session_collection | 31856216 |NULL | 0 |
......
SQL_TEXT: SELECT 1
OBJECT _INSTANCE_BEGIN: 139882156936704
metadata_locks表字段含义如下：
* _thread：客户端线程ID（仅适用于Windows）
·USERAV4：某些连接的用户名，假若是三个里边线程创立的总是，大概是心有余而力不足印证的用户创设的接连，则该字段为NULL；
| admin |1| 1 |
* mysqlbinlog定义了_client_role属性，值为binary_log_listener
OBJECT_NAME: test
SUM_TIMER_EXECUTE: 0
# socket_summary_by_instance表
---------------- ----------------- ---------------- ------------------
（1）accounts表
·PS：cond_instances表不允许使用TRUNCATE TABLE语句。
·OWNER_THREAD_ID，OWNER_EVENT_ID：这几个列表示创造prepare语句的线程ID和事件ID。
表字段含义与session_account_connect_attrs表字段含义同样。
*************************** 1. row ***************************
1 row in set (0.00 sec)
------------- --------------- ------------- ----------------------- ----------------- ---------------- --------------- ---------------
（2）session_connect_attrs表
3rows inset ( 0. 00sec)
admin@localhost : performance _schema 04:55:42> select * from metadata_locksG;
SUM _TIMER_WAIT: 56688392
·prepare语句解除能源分配：对已检验的prepare语句实例试行COM_STMT_CLOSE或SQLCOM_DEALLOCATE_PREPARE命令，同一时间将去除prepare_statements_instances表中对应的行音信。为了防止财富泄漏，请务必在prepare语句不需求使用的时候试行此步骤释放财富。
MAX_TIMER_WAIT: 18446696808701862260
* _pid：客户端进度ID
·cond_instances：wait sync相关的condition对象实例；
SUM_TIMER_READ_NORMAL: 0
AVG_TIMER_WAIT: 24366870
*************************** 1. row ***************************
·MySQL Connector/J定义了之类属性：
MIN _TIMER_READ: 56688392
-------------------------------------------------
admin@localhost : performance_schema 09 :34:49> select * from accounts;
MIN _TIMER_WAIT: 56688392
| EVENT_NAME |OBJECT_INSTANCE_BEGIN | THREAD_ID |SOCKET_ID | IP |PORT | STATE |
·OBJECT_INSTANCE_BEGIN：prepare语句事件的instruments 实例内部存储器地址。
COUNT_READ: 0
------- --------------------- -------------------
MAX _TIMER_WAIT: 56688392
* _runtime_vendor：Java运行境况（JRE）供应商名称
·execute步骤：语法EXECUTE stmt_name[USING @var_name [, @var_name] …]，示例：execute stmt; 再次回到实行结果为1，此时在prepared_statements_instances表中的总结新闻会实行更新；
主要编辑：
* file_summary_by_event_name表：按照EVENT_NAME列实行分组 ；
·当待管理的锁乞求超时，会回去错误音讯（EXC60_LOCK_WAIT_TIMEOUT）给央浼锁的对话，锁状态从PENDING更新为TIMEOUT；
admin@localhost : performance _schema 01:56:16> select * from table_io _waits_summary _by_table where SUM _TIMER_WAIT!=0G;
该表允许使用TRUNCATE TABLE语句。只将总结列重新初始化为零，并不是剔除行。对该表实践truncate还只怕会隐式truncate table_io_waits_summary_by_index_usage表
·CURRENT_CONNECTIONS：某主机的脚下连接数；
users表包括连接到MySQL server的每一个用户的连日音讯，各类用户一行。该表将对准用户名作为唯一标记进行计算当前连接数和总连接数，server运维时，表的高低会自动调度。 要显式设置该表大小，能够在server运行之前设置系统变量performance_schema_users_size的值。该变量设置为0时表示禁用users总括音讯。
* _os：操作系统类型（举例Linux，Win64）
# table_io_waits_summary_by_index_usage表
cond_instances表列出了server实践condition instruments 时performance_schema所见的具备condition，condition表示在代码中一定事件发生时的联手复信号机制，使得等待该条件的线程在该condition满意条件时方可还原工作。
mutex_instances表区别意使用TRUNCATE TABLE语句。
accounts表字段含义如下：
·OWNER_EVENT_ID：触发table handles被打开的风波ID，即持有该handles锁的平地风波ID；
（2）users表
session_account_connect_attrs表字段含义：
上面临那几个表分别开展介绍。
·THREAD_ID：由server分配的里边线程标记符，各类套接字都由单个线程实行田间管理，由此每种套接字都能够映射到多少个server线程（假设能够映射的话）；
1.数额库表等级对象等待事件计算
我们先来探视表中记录的总结新闻是怎么体统的。
大家先来探视表中记录的计算消息是什么体统的。
·FILE_NAME：磁盘文件名称；
当在server中並且进行的八个线程（例如，相同的时间实践查询的八个用户会话）须求拜谒同一的财富（举例：文件、缓冲区或少数数据）时，那八个线程相互竞争，因而首先个成功收获到互斥体的询问将会卡住其余会话的询问，直到成功博得到互斥体的对话实施到位并释放掉这些互斥体，别的会话的查询才具够被实施。
| wait/synch/mutex/mysys/THR_LOCK_heap |32576832| NULL |
我们先来探视表中记录的总结音信是哪些体统的。
1. 老是音信总括表
| wait/io/socket/sql/server_tcpip_socket |110667200| 1 |32| :: |3306| ACTIVE |
| 3 |_client_name | libmysql |1|
MAX_TIMER_EXECUTE: 0
·中间锁对应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。但在该表的概念上并从未观察该字段)
·COUNT_EXECUTE，SUM_TIMER_EXECUTE，MIN_TIMER_EXECUTE，AVG_TIMER_EXECUTE，MAX_TIMER_EXECUTE：施行prepare语句时的连锁总结数据。
·IP：客户端IP地址。该值能够是IPv4或IPv6地址，也能够是空荡荡，表示那是一个Unix套接字文件连续；
亟待具有互斥体的办事负荷能够被感到是处于叁个注重地方的劳作，七个查询或者须求以体系化的章程（贰次二个串行）实行那一个主要部分，但那或者是多个机密的属性瓶颈。
·借使值为NULL，则象征表I/O未有应用到目录
·当四个线程正在等候某一件事发生时，condition NAME列展现了线程正在等待什么condition（但该表中并从未别的列来显示对应哪个线程等音讯），可是如今还未曾一直的不二等秘书技来剖断某些线程或有些线程会促成condition产生变动。
·TOTAL_CONNECTIONS：某主机的总连接数。
MAX _TIMER_READ _WITH_SHARED_LOCKS: 0
LOCK_STATUS: GRANTED
·CURRENT_CONNECTIONS：某用户的当前连接数；
我们先来看看表中著录的总括消息是什么样子的。
rwlock_instances表差异意行使TRUNCATE TABLE语句。
从上边表中的笔录音信我们得以见见，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等待时间，那个表的分组和总计列含义请大家自行以微知著，这里不再赘言，上边针对那三张表做一些必备的印证：
COUNT_READ: 1
|admin | localhost |1| 1 |
SUM_ROWS_AFFECTED: 0
truncate *_summary_global计算表也会隐式地truncate其对应的接连和线程总括表中的音信。举例：truncate events_waits_summary_global_by_event_name会隐式地truncate依照帐户，主机，用户或线程总结的等候事件计算表。
因此对以下四个表推行查询，能够达成对应用程序的督察或DBA可以检验到事关锁的线程之间的有的瓶颈或死锁消息：
·当呼吁元数据锁无法登时赢得时，将插入状态为PENDING的锁新闻行；
admin@localhost : performance_schema 11:00:45> select * from session_account_connect_attrs;
# file_summary_by_event_name表
·相当的多MySQL客户端程序设置的属性值与客户端名称相等的三个program_name属性。例如：mysqladmin和mysqldump分别将program_name连接属性设置为mysqladmin和mysqldump，另外一些MySQL客户端程序还定义了附加属性：
友情提醒：下文中的总括表中山高校部分字段含义与上一篇 《事件总计 | performance_schema全方位介绍》 中关系的计算表字段含义一样，下文中不再赘言。其它，由于一些总计表中的笔录内容过长，限于篇幅会轻巧部分文件，如有需求请自行设置MySQL 5.7.11上述版本跟随本文进行同步操作查看。
MAX_TIMER_READ_NORMAL: 0
............
· NAME：与condition相关联的instruments名称；
AVG_TIMER_READ: 0
------------------------------------------------
COUNT_STAR: 213055844
·metadata_locks：元数据锁的具备和需要记录；
MIN _TIMER_READ _WITH_SHARED_LOCKS: 0
EVENT_NAME: wait/io/socket/sql/server_tcpip_socket
MIN_TIMER_EXECUTE: 0
·events_waits_current：查看线程正在等待什么rwlock；
............
---------------- ---------------------------------- --------------------- ------------------
6 rows inset (0.00 sec)
* _program_name：客户端程序名称
* COUNT_WRITE，SUM_TIMER_WRITE，MIN_TIMER_WRITE，AVG_TIMER_WRITE，MAX_TIMER_WRITE，SUM_NUMBER_OF_BYTES_W传祺ITE：那一个列计算了独具文件写操作，富含FPUTS，FPUTC，FPENCOREINTF，VFPRubiconINTF，FWOdysseyITE和PWRubiconITE系统调用，还包罗了那一个I/O操作的数据字节数 ；
（1）cond_instances表
对于使用C API运转的连日，libmysqlclient库对客户端上的客户端面连接属性数据的总结大小的一直长度限制为64KB：超出限制时调用mysql_options（）函数会报CMurano_INVALID_PARAMETER_NO错误。其余MySQL连接器大概会设置本身的客户端面的总是属性长度限制。
依据数据库对象名称（库品级对象和表等第对象，如：库名和表名）举行总结的守候事件。依据OBJECT_TYPE、OBJECT_SCHEMA、OBJECT_NAME列举办分组，依照COUNT_STAR、xxx_TIMER_WAIT字段实行总结。富含一张objects_summary_global_by_type表。
# file_summary_by_instance表
大家先来拜望表中著录的总括消息是什么样样子的。
*************************** 3. row ***************************
·放出元数据锁时，对应的锁消息行被剔除；
· OWNER_THREAD_ID：持有该handles锁的线程ID；
* _client_version：客户端库版本
· 当行信息中CURubiconRENT_CONNECTIONS 字段值为0时，试行truncate语句会删除这么些行；
·TIMER_PREPARE：试行prepare语句笔者消耗的时刻。
| Tables_in_performance_schema (%socket%summary%) |
02
·ATTR_VALUE：连接属性值；
table_io_waits_summary_by_index_usage表：
AVG _TIMER_READ _WITH_SHARED_LOCKS: 0
OBJECT_SCHEMA: xiaoboluo
COUNT_STAR: 24
SUM_WARNINGS: 0
admin@localhost : performance_schema 05:47:55> select * from table_handles;
这几个表列出了等候事件中的sync子类事件相关的靶子、文件、连接。个中wait sync相关的靶子类型有二种：cond、mutex、rwlock。各类实例表皆有二个EVENT_NAME或NAME列，用于呈现与每行记录相关联的instruments名称。instruments名称恐怕装有三个部分并摇身一变档期的顺序结构，详见"配置详解 | performance_schema全方位介绍"。
SUM _NUMBER_OF _BYTES_READ: 0
* _platform：客户端机器平台（举例，x86_64）
EVENT_NAME: wait/io/socket/sql/client_connection
MIN _TIMER_WAIT: 2971125
IP：PORT列组合值可用以标志三个再三再四。该组合值在events_waits_xxx表的“OBJECT_NAME”列中使用，以标志这一个事件音讯是缘于哪个套接字连接的：
·socket_instances：活跃接连实例。
可由此如下语句查看：
LOCK_DURATION: TRANSACTION
*************************** 1. row ***************************
* _platform：客户端机器平台（比方，x86_64）
cond_instances表字段含义如下：
| USER |CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |
| table_io_waits_summary_by_table |# 依据每个表进行计算的表I/O等待事件
·COUNT_WRITE，SUM_TIMER_WRITE，MIN_TIMER_WRITE，AVG_TIMER_WRITE，MAX_TIMER_WRITE，SUM_NUMBER_OF_BYTES_W奥迪Q3ITE：这么些列总括了全部发送操作（socket的SEND、SENDTO、SENDMSG类型操作，即以server为参照他事他说加以考察的socket写入数据的操作）相关的次数、时间、接收字节数等消息
OWNER_OBJECT_NAME: NULL
注意：rwlock_instances表中的音讯只可以查看到独具写锁的线程ID，不过不可能查看到全数读锁的线程ID，因为写锁W逍客ITE_LOCKED_BY_THREAD_ID字段记录的是线程ID，读锁唯有多个READ_LOCKED_BY_COUNT字段来记录读锁被有个别个线程持有。
·OBJECT_NAME：instruments对象的称号，表等第对象；
* _thread：客户端线程ID（仅适用于Windows）
SOURCE: sql_parse.cc:6031
（1）metadata_locks表
1 row in set (0.00 sec)
COUNT_REPREPARE: 0
每一个连接信息表都有CULX570RENT_CONNECTIONS和TOTAL_CONNECTIONS列，用于追踪连接的近来连接数和总连接数。对于accounts表，每一种连接在表中每行音信的独步天下标志为USEHighlander HOST，可是对于users表，唯有叁个user字段进行标记，而hosts表唯有二个host字段用于标记。
......
·SOURCE：源文件的名号，个中包涵生成事件音信的检验代码行号；
* _client_version：客户端libmysql库版本
三翻五次音信表accounts中的user和host字段含义与mysql系统数据库中的MySQL grant表（user表）中的字段含义类似。
·每种文件I/O总计表都有三个或多个分组列，以申明怎么着总括那些事件新闻。这么些表中的风云名称来自setup_instruments表中的name字段：
* 使用mysqlnd编译：只有_client_name属性，值为mysqlnd
·DEALLOCATE PREPARE步骤：语法 {DEALLOCATE | DROP} PREPARE stmt_name，示例：drop prepare stmt; ，此时在prepared_statements_instances表中对应的prepare示例记录自动删除。
OWNER_THREAD_ID: 48
·OWNER_OBJECT_TYPE，OWNER_OBJECT_SCHEMA，OWNER_OBJECT_NAME：对于由客户端会话使用SQL语句间接创设的prepare语句，这么些列值为NULL。对于由存款和储蓄程序创设的prepare语句，那几个列值显示相关存款和储蓄程序的音讯。假诺用户在蕴藏程序中忘记释放prepare语句，那么这一个列可用于查找那几个未释放的prepare对应的积攒程序，使用语句查询：SELECT OWNE宝马X5_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;
root@localhost : performance _schema 04:44:00> select * from socket_summary _by_event_nameG;
|3| _os |linux-glibc2. 5| 0 |
users表字段含义如下：
accounts表富含连接到MySQL server的每种account的记录。对于每种帐户，没个user host独一标记一行，每行单独总结该帐号的前段时间连接数和总连接数。server运营时，表的分寸会自行调度。要显式设置表大小，能够在server运营此前设置系统变量performance_schema_accounts_size的值。该系统变量设置为0时，表示禁止使用accounts表的计算音信意义。
·当已给予的锁或挂起的锁央求被杀死时，其锁状态从GRANTED或PENDING更新为KILLED；
| file_summary_by_event_name |
---------------------------------- -----------------------
·EVENT_NAME：与公事相关联的instruments名称；
·session_connect_attrs：全体会话的三番两次属性。
该表富含关于内部和表面锁的音信：
当客户端连接到MySQL server时，它的用户名和主机名都以特定的。performance_schema根据帐号、主机、用户名对那么些连接的计算音讯举行分类并保留到种种分类的接连新闻表中，如下：
本文由盖世电竞发布于盖世竞猜官网,转载请注明出处：数据库对象事件与质量总括，performance_schema全方
关键词： 盖世电竞