如何理解MySQL5.6中的PERFORMANCE_SCHEM
通过sql语句找出正在经历哪些等待事件！
Statement -> stage -> wait的三级结构通过nesting_event_id关联起来，nesting_event_id代表的是一个事件。
例如分析一条包含count(*)的SQL语句，如下：（类似oraclev$sql、v$sqlstat、v$sqlarea)
选择
EVENT_ID，
sql_text
FROM events_statements_history
WHERE sql_text LIKE '%count(*)%';
+----------+---------- - ---------------------------+
|事件 ID | sql_text |
+- ---------+-------------------------------------------- ------------+
| 1690 |从chuck.test_slow中选择count(*) |
+---------+----- ---------------- ------------------+
a.查看各个阶段的时间消耗（类似Oracle的时间模型V$SYS_TIME_MODEL V$SESS_TIME_MODEL）
SELECT
event_id,
EVENT_NAME，
p>
来源，
TIMER_END - TIMER_START
来自 events_stages_history_long
WHERE NESTING_EVENT_ID = 1690;
+--------------------+-------------------- --- ----------+------------------------+------------- ----------+
|事件 ID |活动名称 |来源 | TIMER_END-TIMER_START |
+------------+-- ------------------------- --------+-------------------- ---+----------------- ------+
……
| 2647 | stage/sql/发送数据 | sql_executor.cc:192 | 7369072089000 |
b.查看某个阶段的锁等待状态(类似oracle的v$session_wait)
对于每个阶段可能发生的锁等待，一个阶段会对应一次或多次等待， events_waits_history_long 表很容易就满了[默认阈值 10000]。由于select count(*)需要IO（逻辑IO或者物理IO），所以在stage/sql/发送数据阶段会有IO等待统计。 stage_xxx 表的 event_id 字段与 waits_xxx 表的nesting_event_id 关联。
选择
event_id，
event_name，
源，
timer_wait，
object_name，
index_name，
操作，
nesting_event_id
FROM events_waits_history_long
其中nesting_event_id = 2647;
+--------------------+-------------------- ----- ---+----------------+----------------+-------------------- ---+----------------+------------------------+----------------- -+
|事件 ID |事件名称 |来源 |定时器等待|对象名称 |索引名称 |操作|嵌套_事件_id |
+----------+--------- ------------------+--------- --------+------------+ -------------+---------------- --+------------+---------- -------+
| 190607 |等待/io/表/sql/处理程序| handler.cc:2842 | 1845888 |测试慢 | idx_c1 |获取| 2647 |
https://www.cnblogs.com/zhoujinyi/p/5236705.html
MySQL5.6 PERFORMANCE_SCHEMA 说明
背景：强>
MySQL 5.5新增了一个数据库：PERFORMANCE_SCHEMA，主要用于收集数据库服务器性能参数。而且库中表的存储引擎都是PERFORMANCE_SCHEMA，但是用户无法使用PERFORMANCE_SCHEMA存储引擎创建表。 MySQL5.5默认是关闭的，需要手动开启。在配置文件中添加：
[mysqld]
performance_schema=ON
检查是否开启：
mysql>显示“performance_schema”等变量；
+------------ --------+--------+
|变量名 |值 |
+------------- -------+--------+
|性能模式 | 开启 |
+-------- -------------+--------+
< p>从MySQL5.6开始，默认开启。本文将讲解如何在MySQL5.6开始的数据库中使用它。其中，PERFORMANCE_SCHEMA的一些比较常用的函数。具体信息可以查看官方文档。相关表格信息：
一：配置（设置) 表格：
zjy@performance_schema 10:16:56显示表格，例如'%setup%';
+------------------------------------------------ -- ---+
| Tables_in_performance_schema (%setup%) |
+--------------------- -------------- ----+
|设置演员p>| setup_consumers ------------------------------------------------+
1、setup_actors：配置用户纬度的监控，默认监控所有用户。
zjy@performance_schema 10:19:11>从 setup_actors 中选择 *;
+ ------+------+-----+
|主持人|用户|角色 |
+------+-----+------+
| % | % | % |
+------+------+ ------+
2, setup_consumers：配置事件的消费者类型，即收集到的事件写入到哪些统计表中。
zjy@: Performance_schema 10:23:35>se从 setup_consumers 中选择*；
+--------------------------------+---- -----+
|姓名 ------+
|当前事件阶段 |否|
|事件阶段历史|否|
|事件_阶段_历史_长|否 |
|当前事件语句|是 |
|事件_陈述_历史|否|
| events_statements_history_long | 事件声明历史长否|
| events_waits_current | 事件等待当前否|
| events_waits_history | 事件等待历史否|
| events_waits_history_long | events_waits_history_long | events_waits_history_long | events_waits_history_long | events_waits_history_long否|
|全局仪器 |是 |
|线程检测 |是 |
|声明摘要 |是 |
+--------------------------------+--------- +
这里需要说明的是需要勾选哪一项，并将其ENABLED栏更新为YES。例如：
zjy@performance_schema 10:25:02update setup_consumers set ENABLED='YES' where NAME in （'事件_stages_current','events_waits_current');
查询正常，2 行受影响（0.00 秒）
已更新立即生效，但服务器重启后会恢复默认值。要永久生效，需要添加：
[mysqld]
#performance_schema
performance_schema_consumer_events_waits_current=on
performance_schema_consumer_events_stages_current=on< /p>
performance_schema_consumer_events_statements_current=on
performance_schema_consumer_events_waits_history=on
performance_schema_consumer_events_stages_history=on
Performance_schema_consumer_events_statements_history=on
即添加：这些表前面的 Performance_schema_consumer_xxx。 setup_consumers表中的值有层级关系：
global_instrumentation > thread_instrumentation = statements_digest > events_stages_电流nt = events_statements_current = events_waits_current > events_stages_history = events_statements_history = events_waits_history > events_stages_history_long = events_statements_history_long = events_waits_history_long
仅当上一级别为YES，会继续检查当前级别是YES还是NO。 global_instrumentation 是最高级别的消费者。如果设置为NO，则所有消费者都将被忽略。其中history和history_long存储当前表的历史记录条数。 History表记录了每个线程最近等待的10个事件，而history_long表记录了所有线程最近生成的10,000个事件。这里的10和10000都是可配置的。这三个表具有相同的表结构，history和history_long表数据都来自当前表。长度由参数控制：
zjy@performance_schema 11:10:03>显示“performance_schema%history% size”等变量；
+--------- ------------------------------------------ ------------------+- -----+
|变量名 bsp; ------------------+--------+
| 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 |
+-------------------------------- ----------------- ------+--------+
3、setup_instruments：配置具体的instruments，主要包括4类：idle、stage/xxx、statement/xxx、wait/xxx：
zjy@performance_schema 10:56:35从 setup_instruments 组中选择 name,count(*) by LEFT(name,5 < /strong>);
+--------------------------------+-- --------+
|姓名 ---------------+------------+
|空闲
|阶段/sql/创建后 | | 111 |
|语句/sql/select ----------------------------------+----------+< /p>
idle代表socket的空闲时间，stage类代表statement各个执行阶段的统计信息，statement类统计statement维度信息，wait类统计v各种等待事件，如IO、mutux、spin_lock、condition等。
4、setup_objects：配置监控对象。默认情况下，不监控mysql、performance_schema和information_schema中的表。其他数据库中的所有表都会受到监控。
zjy@performance_schema 11:00:18>从 setup_objects 中选择 *;
+ ------------+--------------------------------+--- ----------+- --------+--------+
|对象类型 |对象架构| OBJECT_NAME |已启用 |定时 |
+------ ------+--------------------+------ -------+-------- -+--------+
|表| mysql | | % |否 |否|
|表|性能模式 | % |否 |否|
|表|信息模式 | % |否 |否|
|表| % | % | 是 | 是 |
+------------------------+-- ----------------- -+-------------+---------+------ +
5,<强g>setup_timers：配置各类指令的统计时间单位。 MICROSECOND表示统计单位是微秒，CYCLE表示统计单位是时钟周期，时间测量与CPU主频有关，NANOSECOND表示统计单位是纳秒。但无论使用哪种计量单位，最终统计表中统计的时间都会转换为皮秒。 （1 秒 = 1000000000000 皮秒）
zjy@performance_schema 11:05:12从 setup_timers 中选择 *；
+----------+-------------+
|姓名 | TIMER_NAME |
+------------+-------------+
|闲置|微秒 |
|等待|循环|
|舞台|纳秒 |
|声明|纳秒 |
+----------+-- -----------+
两个 ：实例表格
1，cond_instances：条件等待对象实例
该表记录系统使用的条件变量的对象，OBJECT_INSTANCE_BEGIN为内存地址的对象。
2、file_instances：文件实例
该表记录了打开文件的对象系统，包括ibdata文件、redo文件、binlog文件、用户表文件等。open_count显示当前打开的文件数量。如果不再次打开，则不会出现在表中。
zjy@performance_schema 11:20:04从 file_instances 限制中选择 * 2 ， 5;
+-------------------------------- - +----------------------------------------------------+-------- - ---+
|文件名 |活动名称 | OPEN_COUNT |
+------------------------------------------------ +--------------------------------- -----+------------+
| /var/lib/mysql/mysql/plugin.frm | /var/lib/mysql/mysql/plugin.frm |等待/io/file/sql/FRM | /var/lib/mysql/mysql/plugin.MYD | /var/lib/mysql/mysql/plugin.MYD |等待/io/文件/myisam/dfile |等待 /io/file/innodb/innodb_data_file | |等待/io/文件/innodb/innodb_log_file | 2 |
| /var/lib/mysql/ib_logfile0 /strong> |
+-------------------------------------------- ---+---- ----------------------------------+----- ---------+
3,mutex_instances:互斥同步对象实例
该表记录了系统中所有使用互斥对象的记录，其中名称为：wait/synch/mutex/*。 LOCKED_BY_THREAD_ID 显示哪个线程正在持有互斥体。如果没有线程持有它，则它为 NULL。
4、rwlock_instances：读写锁同步对象实例
该表记录了一个ll记录系统中使用读写锁对象的情况，名称为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：活动会话对象实例
记录table 在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，客户端套接字
三：等待表
1、events_waits_current：记录当前线程正在等待的事件
2、events_waits_history：记录每个线程最近等待的10个事件。
3、events_waits_history_long：记录最近所有线程产生的10000个事件
表结构体定义如下：
CREATE TABLE `events_waits_current` (
`THREAD_ID` bigint(20) unsigned NOT NULL COMMENT 'Thread ID',< /p >
`EVENT_ID` bigint(20) unsigned NOT NULL COMMENT 't 的事件 ID当前线程是唯一的 THREAD_ID',
`END_EVENT_ID` bigint( 20) unsigned DEFAULT NULL COMMENT '当事件开始时，此列设置为 NULL。事件结束时，更新为当前事件 ID',
`EVENT_NAME` varchar(128) NOT NULL COMMENT '事件名称',
`SOURCE` varchar(64) DEFAULT NULL COMMENT '事件发生时的源代码文件',
`TIMER_START` bigint(20) unsigned DEFAULT NULL COMMENT '事件开始时间（皮秒）',
`TIMER_END` bigint(20) unsigned DEFAULT NULL COMMENT '事件结束时间（皮秒）',
p>`TIMER_WAIT` bigint(20) unsigned DEFAULT NULL COMMENT '事件等待时间（皮秒）',
`SPINS` int(10< /strong>) unsigned DEFAULT NULL COMMENT '',
`OBJECT_SCHEMA` varchar(64) DEFAULT NULL COMMENT '库名称',
`OBJECT_NAME` varchar(512) 默认 NULL COMMENT '文件名、表名、IP：SOCK 值',
`OBJECT_TYPE` varchar(64) DEFAULT NULL COMMENT '文件、表、临时表',
`INDEX_NAME` varchar(64) DEFAULT NULL COMMENT '索引名称',
`OBJECT_INSTANCE_BEGIN` bigint (20) unsigned NOT NULL COMMENT '内存地址',
`NESTING_EVENT_ID` bigint(20) unsigned DEFAULT NULL COMMENT '该事件对应的父事件 ID',
`NESTING_EVENT_TYPE` enum('STATMENT','STAGE','WAIT') DEFAULT NULL COMMENT '父事件类型（STATMENT、STAGE、WAIT）',
`OPERATION` varchar(32< /strong>) NOT NULL COMMENT '操作类型（锁定、读、写）',
`NUMBER_OF_BYTES` bigint(20) DEFAULT NULL COMMENT '',
` FLAGS` int(10) 无符号 DEFAULT NULL COMMENT 'flag'
) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8
四 ：舞台>表
1,events_stages_current：记录了的执行阶段当前线程
2、events_stages_history：记录当前线程执行阶段的10条历史记录
3、events_stages_history_long：记录当前线程执行阶段的10000条历史记录
表格结构体定义如下：
CREATE TABLE `events_stages_current` (
`THREAD_ID` bigint(20) unsigned NOT NULLCOMMENT 'Thread ID',
p>
`EVENT_ID` bigint(20) unsigned NOT NULL COMMENT '事件 ID',
`END_EVENT_ID` bigint(20) unsigned DEFAULT NULL COMMENT '结束事件 ID',
`EVENT_NAME` varchar(128) NOT NULL COMMENT '事件名称',
`SOURCE` varchar( 64) 默认空注释'源代码位置',
`TIMER_START` bigint(20) unsigned DEFAULT NULL COMMENT '事件开始时间（皮秒）',
`TIMER_END` bigint(20) unsigned DEFAULT NULL COMMENT '事件结束时间（皮秒）',
`TIMER_WAIT` bigint(20) unsigned DEFAULT NULL COMMENT '事件等待时间（皮秒）',
`NESTING_EVENT_ID` bigint(20) unsigned DEFAULT NULL COMMENT '该事件对应的父事件ID',
`NESTING_EVENT_TYPE` enum('STATMENT','STAGE','WAIT') DEFAULT NULL COMMENT '父事件类型（STATMENT、STAGE、WAIT）'
) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8< /p>
五：语句表格
1< /strong>、events_statements_current：通过thread_id+event_id可以唯一确定一条记录。 Statments表只记录顶层请求、SQL语句或C语句OMAND，每个语句占一行。 event_name 的格式为statement/sql/* 或statement/com/*
2, events_statements_history< /p>
3, events_statements_history_long
表结构定义如下：
< p>创建表 `events_statements_current ` (`THREAD_ID` bigint(20) unsigned NOT NULL COMMENT '线程 ID',
`EVENT_ID` bigint( 20strong>) unsigned NOT NULL COMMENT '事件 ID',
`END_EVENT_ID` bigint(20) unsigned DEFAULT NULL COMMENT '结束事件 ID' ,
`EVENT_NAME` varchar(128) NOT NULL COMMENT '事件名称',
`SOURCE` varchar(64 ) DEFAULT NULL COMMENT '源代码位置',
`TIMER_START` bigint(20) unsigned DEFAULT NULL COMMENT '事件开始时间（皮秒）',
`TIMER_END` bigint(20) 无符号 DEFAULT NULL COMMENT '事件结束时间（皮秒）',
`TIMER_WAIT` bigint(20strong>) unsigned DEFAULT NULL COMMENT '事件等待时间（皮秒）',
`LOCK_TIME` bigint(20) unsigned NOT NULL COMMENT '锁定时间',
`SQL_TEXT` longtext COMMENT '记录SQL语句',
`DIGEST` varchar(32) DEFAULT NULL COMMENT 'SQL_TEXT MD5生成的32位字符串',
`DIGEST_TEXT` longtext COMMENT '替换数值部分带问号的语句，用于对 SQL 语句进行分类',
`CURRENT_SCHEMA` varchar(64) DEFAULT NULL COMMENT '默认数据库名称',
`OBJECT_TYPE` varchar(64) DEFAULT NULL COMMENT '保留字段',
` OBJECT_SCHEMA` varchar(64) DEFAULT NULL COMMENT '保留字段' ,
`OBJECT_NAME` varchar(64) DEFAULT NULL COMMENT '保留字段',
`OBJECT_INSTANCE_BEGIN` bigint(20 ）你nsigned DEFAULT NULL COMMENT '内存地址',
`MYSQL_ERRNO` int(11) DEFAULT NULL COMMENT '',
`RETURNED_SQLSTATE` varchar( >5) DEFAULT NULL COMMENT '',
`MESSAGE_TEXT` varchar(128) DEFAULT NULL COMMENT '消息',
`ERRORS ` bigint(20 ) unsigned NOT NULL COMMENT '错误数量',
`警告` bigint(20) unsigned NOT NULL COMMENT '错误数量warnings',
`ROWS_AFFECTED` bigint(20) unsigned NOT NULL COMMENT '受影响的数字',
`ROWS_SENT` bigint(20< /strong>) unsigned NOT NULL COMMENT '返回的记录数',
`ROWS_EXAMINED` bigint(20) unsigned NOT NULL COMMENT '读取和扫描的记录数',< /p>
`CREATED_TMP_DISK_TABLES `bigint(20) unsigned NOT NULL COMMENT '创建的磁盘临时表的数量',
`CREATED_TMP_TABLES` bigint(20< /strong>) 无符号 NOT NULL COMMENT 'Number oftemporary tablecreated ',
`SELECT_FULL_JOIN` bigint(20) unsigned NOT NULL COMMENT '连接时首表为全表扫描次数',
`SELECT_FULL_RANGE_JOIN` bigint(20) unsigned NOT NULL COMMENT '范围模式扫描的引用表数量',
`SELECT_RANGE` bigint( 20) unsigned NOT NULL COMMENT '连接时，范围内扫描的第一个表的数量',
`SELECT_RANGE_CHECK` bigint(20) unsigned NOT NULL COMMENT ' ',
p>`SELECT_SCAN` bigint(20) unsigned NOT NULL COMMENT '连接时，第一个表位置的全表扫描次数',
`SORT_MERGE_PASSES` bigint (20) unsigned NOT NULL COMMENT '',
`SORT_RANGE` bigint(20) unsigned NOT NULL COMMENT '范围排序编号',
`SORT_ROWS` bigint(20) unsigned NOTNULL COMMENT '排序的记录数',
`SORT_SCAN` bigint(20) unsigned NOT NULL COMMENT '排序记录数',
`NO_INDEX_USED ` bigint(20) unsigned NOT NULL COMMENT '否使用的索引号',
`NO_GOOD_INDEX_USED` bigint(20) unsigned NOT NULL COMMENT '' ,
`NESTING_EVENT_ID` bigint(20< /strong>) unsigned DEFAULT NULL COMMENT '与此事件对应的父事件 ID',
`NESTING_EVENT_TYPE` enum('STATMENT ','STAGE','WAIT') DEFAULT NULL COMMENT '父事件类型（声明、阶段、等待）'
) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8
六：连接表格
1,strong>用户：记录用户连接数信息
2、hosts：记录的主机连接数信息
3、账户：记录用户主机连接号信息
zjy@performance_schema 12:03:27select * from users;
+--------- ---------+--------------------+----- ------------- -+
|用户|当前连接 | TOTAL_CONNECTIONS |
+-----------------+-------------------+ -------------------+
| debian 系统维护 | 36 |
| zjy |强>10770 |
| dchat_data |2233023 |
|空| | 15866 |
| dchat_api | 60 | 60 2754212 |
| mha_数据| | 1 | 36 |
|备份| | 172414 |
+--------------------+------------------------- - -------+-------------------+
12 行（0.00 秒）
zjy@performance_schema 12:03:34>从主机中选择 *;
+------ ------- ---+--------------------+----------------- --+
|主持人|当前连接 | TOTAL_CONNECTIONS |
+----------------+------------------------ -------+-- ------------------+
| 192.168。100.218 | >10 |; >
| 192.168。100.220 |强>192.168。100.25 |; 7 |
|空| 100.241 | 100.241 | p; 2 |
| 192.168。100.251 | 192.168.100.23 |; 31 |
| 192.168。100.193 |
+----------------+--------------------+----- - -------------+
14 行（0.01 秒）
zjy@performance_schema 12:< strong>05:21从帐户中选择*；
+-------- ----------+--- ---------------+------------------------ -+-------- ----------+
|用户|主持人|当前连接 | TOTAL_CONNECTIONS |
+---- --------------+-----------------+-- --------------- ----+--------------------+
|仙人掌| 192.168。100.251 | 36 |
|备份| 192.168。100.193 | | dchat_api | 192.168。100.220 | /strong>.100.220 | |bsp； | 192.168。100.241 | 100.191 | | 2 |
|网红 | 192.168。100.240 | |
| dxy奴隶| 192。168。100.25 | |
| dchat_数据 | 192.168。100.218 |p; >31 |
| dchat_php | 192.168。100.218 | p>| dchat_数据 | 192.168。100.220 |ng>70 |数据 strong>192.168.100.21 | |sp; ------------------+----------------+------------- --------+--------------------+
查看代码
七： SummaryTable ： Summary Table汇总了各种Dimension统计信息包括表维度、索引维度、会话维度、语句维度、锁维度统计
1,< strong>events_waits_summary_global_by_event_name：按等待事件类型聚合，每个事件一条记录
CREATE TABLE `events_waits_summary_global_by_event_name` (
`EVENT_NAME` varchar(128
strong>) NOT NULL COMMENT '事件名称',`COUNT_STAR` bigint(20) unsigned NOT NULL COMMENT '事件计数',
`SUM_TIMER_WAIT ` bigint(20) unsigned NOT NULL COMMENT '总等待时间',
`MIN_TIMER_WAIT` bigint(20) unsigned NOT NULL COMMENT '最短等待时间time',
`AVG_TIMER_WAIT` bigint(20) unsigned NOT NULL COMMENT '平均等待时间',
`MAX_TIMER_WAIT` bigint(20 ) 无符号 NOT NULL COMMENT '最长等待时间'
) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8
2 ,events_waits_summary_by_instance：通过等待事件对象聚合，同一种等待事件可能有多个实例，each实例有不同的内存地址，所以
event_name+object_instance_begin唯一确定一条记录。
创建表 `events_waits_summary_by_instance` (
`EVENT_NAME` varchar(128) NOT NULL COMMENT '事件名称',
` OBJECT_INSTANCE_BEGIN` bigint(20)unsigned NOT NULL COMMENT '内存地址',
`COUNT_STAR` bigint(20) unsigned NOT NULL COMMENT '事件计数',
`SUM_TIMER_WAIT` bigint (20) unsigned NOT NULL COMMENT '总等待时间',
`MIN_TIMER_WAIT` bigint(20< /strong>) unsigned NOT NULL COMMENT '最短等待时间',
`AVG_TIMER_WAIT` bigint(20) unsigned NOT NULL COMMENT '平均等待时间',
< p> `MAX_TIMER_WAIT` bigint(20) unsigned NOT NULL COMMENT '最大等待时间') ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8
3、events_waits_summary_by_thread_by_event_name：对每个线程和事件进行统计，thread_id+event_name唯一确定一条记录。
创建表 `events_waits_summary_by_thread_by_event_name` (
`THREAD_ID` bigint(20) unsigned NOT NULL COMMENT '线程 ID',
`EVENT_NAME` varchar(128) NOT NULL COMMENT '事件名称',
`COUNT_STAR` bigint(20) unsigned NOT NULL COMMENT '事件计数',
`SUM_TIMER_WAIT` bigint(20) unsigned NOT NULL COMMENT '总等待时间',
`MIN_TIMER_WAIT` bigint(20< /strong>) unsigned NOT NULL COMMENT '最短等待时间',
`AVG_TIMER_WAIT ` bigint(20) unsigned NOT NULL COMMENT '平均等待时间',
< p> `MAX_TIMER_WAIT` bigint(20) unsigned NOT NULL COMMENT '最长等待时间') ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8
4、events_stages_summary_global_by_event_name：按偶数t stage类型聚合，每个事件一条记录，表结构同上。
5、events_stages_summary_by_thread_by_event_name：每个线程和事件的Stage统计信息，表结构同上。
6、events_statements_summary_by_digest：根据事件的陈述进行聚合。
创建表 `events_statements_summary_by_digest` (
`SCHEMA_NAME` varchar(64) DEFAULT NULL COMMENT '库名称',
` DIGEST` varchar(32) DEFAULT NULL COMMENT '对 SQL_TEXT 进行 MD5 得到的 32 位字符串。如果消费者表中未打开 statements_digest 选项，则将为 NULL',
`DIGEST_TEXT` longtext COMMENT '将语句的值部分替换为 SQL 语句分类的问号。如果消费者表没有打开 statements_digest 选项，则为 NULL。',
`COUNT_STAR` bigint(20) unsigned NOT NULL COMMENT '事件计数',
`SUM_TIMER_WAIT` bigint(20) strong>) unsigned NOT NULL COMMENT '总等待时间',
`MIN_TIMER_WAIT` bigint(20) unsigned NOT NULL COMMENT '最短等待时间',
< p > `AVG_TIMER_WAIT` bigint(20) unsigned NOT NULL COMMENT '平均等待时间',`MAX_TIMER_WAIT` bigint(20) unsigned NOT NULL COMMENT '最大等待时间',
`SUM_LOCK_TIME` bigint(20) unsigned NOT NULL COMMENT '总锁定时间',
`SUM_ERRORS` bigint (< strong>20) unsigned NOT NULL COMMENT '错误总数',
`SUM_WARNINGS` bigint(20) unsigned NOT NULL COMMENT '警告总数' ,
` SUM_ROWS_AFFECTED` bigint(20) unsigned NOT NULL COMMENT '受影响的总数',
`SUM_ROWS_SENT` bigint(20) strong>) 无符号 NOT NULL COMMENT ' 返回 t总数',
`SUM_ROWS_EXAMINED` bigint(20) unsigned NOT NULL COMMENT '扫描总数',
`SUM_CREATED_TMP_DISK_TABLES` bigint( 20) unsigned NOT NULL COMMENT '创建的磁盘临时表总数',
`SUM_CREATED_TMP_TABLES` bigint(20) unsigned NOT NULL COMMENT '创建临时表总数',
`SUM_SELECT_FULL_JOIN` bigint(20) unsigned NOT NULL COMMENT '第一个表的全表扫描总数',
< p> `SUM_SELECT_FULL_RANGE_JOIN` bigint(20) unsigned NOT NULL COMMENT '范围扫描总数',`SUM_SELECT_RANGE` bigint(20) >) unsigned NOT NULLCOMMENT '第一个表的范围扫描总数',
`SUM_SELECT_RANGE_CHECK` bigint(20) unsigned NOT NULL COMMENT '',
`SUM_SELECT_SCAN` bigint(20) unsigned NOT NULL COMMENT '完整选项卡总数第一个表位的文件扫描',
`SUM_SORT_MERGE_PASSES` bigint(20) unsigned NOT NULL COMMENT '',
`SUM_SORT_RANGE` bigint( >20) unsigned NOT NULL COMMENT '范围排序总数',
`SUM_SORT_ROWS ` bigint(20) unsigned NOT NULL COMMENT '排序记录总数',
`SUM_SORT_SCAN` bigint(20) unsigned NOT NULL COMMENT '第一个表的排序扫描总数',
`SUM_NO_INDEX_USED` bigint( 20) unsigned NOT NULL COMMENT '未使用的索引总数',
` SUM_NO_GOOD_INDEX_USED` bigint(20) unsigned NOT NULL COMMENT '' ,
`FIRST_SEEN` 时间戳 NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT '第一次执行时间',
`LAST_SEEN` 时间戳 NOT NULL DEFAULT '0000 -00-00 00:00:00' COMMENT '上次执行时间'
) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8
7, events_statements_summary_global_by_event_name：按事件陈述聚合。表结构与上面相同。
8、events_statements_summary_by_thread_by_event_name：根据线程和事件的statement进行聚合，表结构同上。
9、file_summary_by_instance：按事件类型统计（物理IO< /strong>维度)
10、file_summary_by_event_name：特定文件统计信息（物理IO维度）
9和10一起解释：
统计IO操作：COUNT_STAR， SUM_TIMER_WAIT、MIN_TIMER_WAIT、AVG_TIMER_WAIT、MAX_TIMER_WAIT
统计数据读取：COUNT_READ、SUM_TIMER_READ、MIN_TIMER_READ、AVG_TIMER_READ、MAX_TIMER_READ、SUM_NUMBER_OF_BYTES_READ
统计数据写入iting: COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WRITE,AVG_TIMER_WRITE,MAX_TIMER_WRITE, SUM_NUMBER_OF_BYTES_WRITE
统计其他IO事件，如创建、删除、打开、关闭等：COUNT_MISC、SUM_TIMER_MISC、MIN_TIMER_MISC、AVG_TIMER_MISC、MAX_TIMER _MISC
11、table_io_waits_summary_by_table：根据wait/io/table/sql/handler聚合各个表的I/O操作（ 逻辑IOLatitude）
统计IO操作：COUNT_STAR、SUM_TIMER_WAIT、MIN_TIMER_WAIT、AVG_TIMER_WAIT、MAX_TIMER_WAIT
< p>统计读取：COUNT_READ,SUM_TIMER_READ, MIN_TIMER_READ,AVG_TIMER_READ,MAX_TIMER_READ：COUNT_FETCH,SUM_TIMER_FETCH,MIN_TIMER_FETCH,AVG_TIMER_FETCH, MAX_TIMER_FETCH
统计写入：COUNT_WRITE,SUM_TIMER_WRITE,MIN_TIMER_WR ITE，AVG_TIMER_WRITE， MAX_TIMER_WRITE
INSERT统计信息，对应DELETE和UPDATE统计信息：COUNT_INSERT、SUM_TIMER_INSERT、MIN_TIMER_INSERT、AVG_TIMER_INSERT、MAX_TIMER_INSERT
12、table_io_waits_summary_by_index_usage：与table_io_waits_summary_by_table类似，统计按索引维度
13、table_lock_waits_summary_by_table：聚合表锁等待事件，包括内部锁和外部锁
内部锁通过SQL层函数thr_lock调用，OPERATION值为：
读正常、读带共享锁、读高优先级、读无插入、写允许写、写并发插入、延迟写、写低优先级、写正常
外部锁通过接口函数handler::external_lock调用存储引擎层。 OPERATION 列的值为：读取外部、写入外部
14、连接摘要表< /strong>：帐户、用户、主机
甚至ts_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
15、socket_summary_by_instance、 socket_summary_by_event_name：socket聚合统计表。
八：其他相关表格
1、< strong>Performance_timers：系统支持的统计时间单位
2、threads：监控服务器当前状态运行线程
统计应用程序ication:
关于SQL 维度的统计信息主要集中在events_statements_summary_by_digest表，通过抽象出SQL语句strong>digest ，可以统计某类SQL语句各个维度的统计信息
1，其中SQL执行次数最多：
zjy@performance_schema 11 :36:22选择 SCHEMA_NAME、DIGEST_TEXT、COUNT_STAR、SUM_ROWS_SENT、SUM_ROWS_EXAMINED、FIRST_SEEN、LAST_SEEN FROM events_statements_summary_by_digest ORDER BY COUNT_STAR desc 限制1\G
******** ********** ********** 1。行****************************
SCHEMA_NAME：dchat
< p> DIGEST_TEXT：选择...COUNT_STAR：1161210102
SUM_ROWS_SENT：1161207842
SUM_ROWS_EXAMINED：
FIRST_SEEN：2016-02-<强>1700：36：46
LAST_SEEN：< strong>2016-03-0711:36:29
各个字段的注释请参见上表结构描述：从2月17日到3月7日，这条SQL被执行了1161210102次。
2，其中SQL平均响应时间最长：
zjy@performance_schema 11:36:28选择 SCHEMA_NAME ,DIGEST_TEXT,COUNT_STAR,AVG_TIMER_WAIT, SUM_ROWS_SENT,SUM_ROWS_EXAMINED,FIRST_SEEN,LAST_SEEN 来自 events_statements_summary_by_digest 顺序 <强>BYAVG_TIMER_WAITdescLIMIT1\G
** ************************** 1。行****************************
SCHEMA_NAME：dchat
< p> DIGEST_TEXT：选择...COUNT_STAR：1
AVG_TIMER_WAIT：273238183964000
SUM_ROWS_SENT：50208
SUM_ROWS_EXAMINED：5565651
FIRST_SEEN< /strong>: 2016-02-22 13 strong>：27：33
LAST_SEEN：2016-02< /strong>-22 13:27:33
每个字段的注释可以看上面的表结构描述：从2月17日到3月7日，这条SQL的平均响应时间为273238183964000皮秒（1000000000000皮秒=1秒）
3 ，SQL扫描最多的行：
SUM_ROWS_EXAMINED
4< strong>，SQL使用最多的临时表：
SUM_CREATED_TMP_DISK_TABLES、SUM_CREATED_TMP_TABLES
5 哪个SQL返回最大的结果集：
SUM_ROWS_SENT
6，其中SQL排序次数最多：
SUM_SORT_ROWS
通过以上指标，我们可以间接获得某类SQL的逻辑IO（SUM_ROWS_EXAMINED）、CPU消耗（SUM_SORT_ROWS）、网络带宽（SUM_ROWS_SENT）的对比情况。
通过file_summary_by_instance表，可以得到系统运行至今，哪个文件（表）的物理IO最多。这可能意味着这个表经常需要访问磁盘IO。
7、哪个表和文件逻辑IO最多（热点数据）：
zjy@performance_schema 12:16:18>选择 < /strong >FILE_NAME,EVENT_NAME,COUNT_READ,SUM_NUMBER_OF_BYTES_READ,COUNT_WRITE,SUM_NUMBER_OF_BYTES_WRITE 来自 file_summary_by_instance ORDER <强> BY SUM_NUMBER_OF_BYTES_READ+SUM_NUMBER_OF_BYTES_WRITE DESCLIMIT2\G
******************************** 1 。行****************************
strong>ibdata1 #文件
EVENT_NAME：等待/io/file/innodb/innodb_data_file
COUNT_READ：544
SUM_NUMBER_OF_BYTES_READ：10977280< /strong>
COUNT_WRITE：3700729
SUM_NUMBER_OF_BYTES_WRITE：1433734217728
strong>**** ***************************** : /var/lib/mysql/dchat/fans.ibd # 表
EVENT_NAME：wait/io/file/innodb/innodb_data_file
Count_read： 9370680
Sum_number_of_Bytes_READ： 153529188352
Count_write： 675766 376SUM_NUMBER_OF_BYTES_WRITE：1107815432192
8< strong>，哪个索引使用最多：
zjy@performance_schema 12:18:42 SELECT OBJECT_NAME、INDEX_NAME、COUNT_FETCH、COUNT_INSERT、COUNT_UPDATE、COUNT_DELETE FROM table_io_waits_summary_by_index_usage 订单 BYstrong> SUM_TIMER_WAIT DESC限制 1;
+ -------------+-------- ---------+-------------+--------- -----+------------ ---+--------------+
| OBJECT_NAME | INDEX_NAME | COUNT_FETCH | COUNT_插入| COUNT_UPDATE | COUNT_DELETE |
+------------------------+------------+------------ ---- +--------------+--------------+--------------+
| <斯特罗ng>粉丝 | 主要 | 29002695158 |
+-------------+------------+----------------+----- ----------+--------------+--------------+
1 row in set ( 0.29 sec)
通过table_io_waits_summary_by_index_usage表，可以获取具体索引（包括主键索引和系统运行至今，哪个表被使用最多（二级索引）。
9，未使用哪个索引：
zjy@performance_schema 12：<强>23：22选择OBJECT_SCHEMA，OBJECT_NAME，INDEX_NAME FROM table_io_waits_summary_by_index_usage WHERE INDEX_NAME IS NOT NULL 并且 COUNT_STAR = 并且 OBJECT_SCHEMA <> 'mysql' ORDER < /strong>BYOBJECT_SCHEMA，OBJECT_NAME；
10，哪个等待事件消耗时间最多：
zjy@performance_schema 12:25:22< /strong>>选择 EVENT_NAME、COUNT_STAR、SUM_TIMER_WAIT、AVG_TIMER_WAIT 来自 events_waits_summary_global_by_event_name 地点 event_name != '空闲' 订单<强> BY SUM_TIMER_WAIT DESC LIMIT 1;
< p>11，类似于分析功能：分析一条具体的SQL，该SQL执行各阶段的时间消耗可以通过events_statements_xxx表和events_stages_xxx表得知。这两个表通过event_id与nesting_event_id相关。 stage表的nesting_event_id是对应statements表的event_id；对于每个阶段可能存在的锁等待，每个阶段对应一个或多个等待，并通过stage_xxx表的event_id字段与waits_xxx表的nesting_event_id关联。例如：
例如分析一条包含count(*)的SQL语句，如下：
SELECT
EVENT_ID,
sql_text
来自 events_statements_history
WHERE sql_text LIKE '%count(*)%';
+----------+-- - ----------------------------------+
|事件 ID | sql_text |
+----------+-----------------------------------------------------+
| 1690 |从chuck.test_slow中选择count(*) |
+--------- -+------------------------ -------------------+
先获取该语句的event_id为1690，通过查找记录即可达到目的events_stages_xxx 中的嵌套_event_id 1690。
a.查看各个阶段的耗时：
SELECT
event_id,
EVENT_NAME,
SOURCE,
TIMER_END - TIMER_START
来自 events_stages_history_long
其中 NESTING_EVENT_ID = 1690；
+-- --------+ --------------------------------+-------------------- --------- ----+------------------------+
|事件 ID |活动名称 |来源 | TIMER_END-TIMER_START |
+------------+---------------------------- ---+--------------------+-------- ------------- --+
| 1691 |阶段/sql/init | mysqld.cc:990 | 316945000 |
| 1693 |阶段/sql/che检查权限| sql_parse.cc：5776 | 26774000 |
| 1695 |阶段/sql/打开表| sql_base.cc：4970 | 41436934000强> |
| 2638 |阶段/sql/init | sql_select.cc：1050 | 85757000 |
| 2639 |阶段/sql/系统锁 | lock.cc:303 | 40017000 |
| 2643 |阶段/sql/优化 | sql_optimizer.cc：138 | 38562000 |
| 2644|阶段/sql/统计 | sql_optimizer.cc：362 | 52845000 |
| 2645 |阶段/sql/准备 | sql_optimizer.cc：485 | 53196000 |
| 2646 |阶段/sql/执行| sql_executor.cc:112 | 3153000 |
| 2647 | stage/sql/发送数据 | sql_executor.cc：192 | 7369072089000 |
| 4304138 |阶段/sql/结束 | sql_select.cc:1105 | 19920000 |
| 4304139 |阶段/sql/查询结束 | sql_parse.cc:5463 | 44721000 |
| 4304145 |阶段/sql/关闭表| sql_parse.cc:5524 | 61723000 |
| 4304152|阶段/sql/释放项目 | sql_parse.cc：6838 | 455678000 |
| 4304155 | stage/sql/logging 慢查询 | sql_parse.cc:2258 | 83348000 |
| 4304159 |阶段/sql/清理| sql_parse.cc:2163 |4433000 |
+------------+--------- -------------- ----------+------------------------+ ---------------- ------+
通过间接关联，我们可以分析得到时间co每个阶段的SQL语句消耗量，时间单位为皮秒。此处显示的结果与分析函数非常相似。使用性能模式，不再需要分析功能。另外需要注意的是，默认情况下，events_stages_history 表中只记录每个连接的最后 10 条记录。为了保证获取到所有记录，需要访问events_stages_history_long表
b。查看某一阶段的锁等待情况
对于每个阶段可能发生的锁等待，一个阶段会对应一次或多次等待，events_waits_history_long表很容易就满了[默认阈值10000]。由于select count(*)需要IO（逻辑IO或者物理IO），所以在stage/sql/发送数据阶段会有IO等待统计。 stage_xxx 表的 event_id 字段与 waits_xxx 表的nesting_event_id 关联。
选择
event_id，
event_name，
源，
timer_wait，
object_name，
index_name，
操作，
nesting_event_id
来自 events_waits_history_long
其中nesting_event_id = 2647;
+------------ +--------------------- ---+-----------------+------ ----------+-------------+- -----------+------------+ ------------------+
|事件 ID |事件名称 |来源 |定时器等待|对象名称 |索引名称 |操作|嵌套_事件_id |
+---------+------------------------ ------+- ------------------+------------+---------- -+-------- ------+----------+------------------+
| 190607 |等待/io/表/sql/处理程序| handler.cc:2842 | 1845888 |测试慢 | idx_c1 |获取| 2647 |
| 190608 |等待/io/表/sql/处理程序| handler.cc:2842 | 1955328 |测试慢 | idx_c1 |获取| 2647 |
| 190609 |等待/io/表/sql/处理程序| handler.cc:2842 | 1929792 |测试慢 | idx_c1 |获取| 2647 |
| 190610 |等待/io/表/sql/处理程序| handler.cc:2842 | 1869600 |测试慢 | idx_c1 |获取| 2647 > |
| 190611 |等待/io/表/sql/处理程序| handler.cc:2842 | 1922496 |测试慢 | idx_c1 |获取| 2647 |
+--------------------+---- ------------------ ---+-----------------+-------- ----+------------- +----------------+------------+------ ------------+< /p>
通过上面的实验，我们知道了statement、stage、wait的三级结构，它们通过nesting_event_id关联起来，nesting_event_id代表一个事件的父级。 event_id。
（2）。模拟innodb行锁等待示例
会话A执行语句update test_icp set y=y+1 where x=1（x为主键），不提交；会话B执行同样的语句update test_icp set y=y+1 where x=1strong>，会话B被阻塞，最终报错。通过connection连接查询events_statements_history_long和events_stages_history_long，可以看到更新阶段大约需要60s。这主要是因为实例上的innodb_lock_wait_timeout设置为60，等待60秒后报错。
SELECT
statement.EVENT_ID，
stages.event_id，
statement.sql_text，
阶段。 event_name,
stages.timer_wait
FROM events_statements_history_long 语句
加入 events_stages_history_long 阶段
on statements.event_id=stages.nesting_event_id
WHERE 语句.sql_text = '更新 test_icp set y=y+1 where x=1';
+------------+-------- ---+- ----------------------------------+---------- --- ------------------+----------------+
|事件 ID |事件 ID | sql_text |事件名称 | timer_wait |
+------------+------------+---------------- --- --------------------+---------------------------------------- -- ---+----------------+
| 5816 | 5817 |更新 test_icp 设置 y=y+1 其中 x=1 |阶段/sql/init | 195543000 |
| 5816 | 5819 |更新 test_icp 设置 y=y+1 其中 x=1 |阶段/sql/检查权限| 22730000 |
| 5816 | 5821 |更新 test_icp 设置 y=y+1 其中 x =1 |阶段/sql/打开表| 66079000 |
| 5816 | 5827 |更新 test_icp 设置 y=y+1 其中 x=1 |阶段/sql/init | 89116000 |
| 5816 | 5828|更新 test_icp 设置 y=y+1 其中 x=1 |阶段/sql/系统锁 | 218744000 |
| 5816 | 5832 |更新 test_icp 设置 y=y+1 其中 x=1 |阶段/sql/更新 | 6001362045000 |
| 5816 | 5968 |更新 test_icp 设置 y=y+1 其中 x=1 |阶段/sql/结束 | 10435000 |
| 5816 | 5969 |更新 test_icp 设置 y=y+1 其中 x=1 |阶段/sql/查询结束 | 85979000 |
| 5816 | 5983 |更新 test_icp 设置 y=y+1 其中 x=1strong> |阶段/sql/关闭表| 56562000 |
| 5816 | 5990 |更新 test_icp 设置 y=y+1 其中 x=1 |阶段/sql/释放项目 | 83563000|
| 5816 | 5992 |更新 test_icp 设置 y=y+1 其中 x=1 |阶段/sql/清理 | 4589000 |
+------------+-------- ---+------------ --------------------------------------+-------- ------------ --------------+----------------+
查看等待事件：
选择
event_id，
event_name，
源，
timer_wait，
object_name，
index_name，
操作，
nesting_event_id
FROM events_waits_history_long
WHEREnesting_event_id = 5832;
**************************** 1。行****************************
event_id：5832
< p>event_name: wait/io/table/sql/handler来源: handler.cc:2782
timer_wait: 6005946156624
object_name: test_icp
index_name: PRIMARY
操作: fetch
从结果中，fetch 等待事件记录在侍应桌，但没有更详细的Innodb行锁等待事件统计信息。
（3）。模拟MDL锁等待示例
会话A执行大查询select count(*) from test_slow，会话B执行表结构更改alter table test_slowmodify c2 varchar(152 ）；通过以下语句可以获取alter语句的执行过程，重点关注“stage/sql/等待表元数据锁”阶段。
SELECT
statement.EVENT_ID，
stages.event_id，
statement.sql_text，
阶段。 event_name as stage_name，
stages.timer_wait as stage_time
FROM events_statements_history_long 语句
左连接 events_stages_history_long 阶段
on statements.event_id=stages .nesting_event_id
WHERE语句.sql_text = 'alter table test_slow修改c2 varchar(152)';
+-----------+---- -------+---------------------------------------- --- ---+------------------------------------------------ -------+----------------+
|事件 ID |事件 ID | sql_text |舞台名称 | stage_time |
+ ----------+------------------------+---------------- ---------------------------------- --+------------- ------------------------------------------------ -----+-------- --------+
| 326526744 | 326526745 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/init | 216662000 |
| 326526744 | 326526747 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/检查权限| 18183000 |
| 326526744| 326526748 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/检查权限| 10294000 |
| 326526744 | 326526750 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/init | 4783000 |
| 326526744 | 326526751 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/打开表| 140172000 |
| 326526744 | 326526760 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/设置| 157643000 |
| 326526744 | 326526769 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/创建表 | 8723217000 |
| 326526744 | 326526803 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/创建后 | 257332000 |
| 326526744 | 326526832 |更改表 test_slow 修改 c2 varchar(152) | stage/sql/等待表元数据锁 | 1000181831000 |
| 326526744 | 326526835 | 6835更改表 test_slow 修改 c2 varchar(152) |阶段/sql/创建后 | 33483000 |
| 326526744 | 326526838 |更改表 test_slow 修改 c2 varchar(152) | stage/sql/等待表元数据锁 | 1000091810000 |
| 326526744 | 326526841 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/创建后 | 17187000 |
| 326526744 | 326526844 |更改表 test_slow 修改 c2 varchar(152) | stage/sql/等待表元数据锁 | 1000126464000 |
| 326526744 | 326526847 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/创建后 | 27472000 |
| 326526744 | 326526850 |更改表 test_slow 修改 c2 varchar(152) | stage/sql/等待表元数据锁 | 561996133000 |
| 326526744| 326526853 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/创建后 | 124876000 |
| 326526744 | 326526877 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/系统锁 | 30659000 > |
| 326526744 | 326526881 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/准备更改表| 40246000 |
| 326526744 | ) |阶段/sql/更改表 | 36628000 |
| 326526744 | 326528280 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/结束 | 43824000 |
| 326526744| 326528281|更改表 test_slow 修改 c2 varchar(152) |阶段/sql/查询结束 | 112557000 |
| 326526744 | 326528299 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/关闭表| 27707000 |
| 326526744 | 326528305 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/释放项目 | 201614000 |
| 326526744 | 326528308 |更改表 test_slow 修改 c2 varchar(152) |阶段/sql/清理 | 3584000 |
+------------+------------------------+-------------------- ----------------------------+--------------------- -------------------------------+--------------+
从结果可以看出，stage/sql/Waiting for table metadata lock阶段多次发生，间隔时间为1s，说明g 每隔1s重试一次判断。在这个阶段找到一个event_id并将其与nesting_event_id关联起来以确定您正在等待哪个等待事件。
选择
event_id，
event_name，
源，
timer_wait，
object_name，
index_name，
操作，
nesting_event_id
FROM events_waits_history_long
其中nesting_event_id = 326526850;
+--------------------+------------------------ -----------------------+--------------------+----- ------+-------------+----------------+--------- -------+ ------------------+
|事件 ID |事件名称 |来源 |定时器等待|对象名称 |索引名称 |操作|嵌套事件 ID |
+---------+---------------------------- ----------- ---------------+-----------------+---- ---------+- ------------+------------+------------+ ----------- -------+
| 326526851 |等待/同步/cond/sql/MDL_context::COND_wait_status | mdl.cc:1327 |
| 326526852 |等待/同步/互斥体/mysys/ my_thread_var::mutex | sql_class.h:3481 | 733248 |空|空|锁| 326526850 |
+------------------------+------------------------ ------------- --------------------------------+---------------- --+---------- ----+-------------+------------+----- -------+----- -------------+
从结果可以知道条件变量MDL_context::COND_wait_status处于阻塞状态，并显示代码的位置。
查看代码
这里介绍了《如何理解MySQL5.6中的PERFORMANCE_SCHEM》。感谢您的阅读。如果您想了解更多行业资讯，可以关注网站，小编将为大家输出更多优质实用文章！
2. 本站积分货币获取途径以及用途的解读，想在本站混的好，请务必认真阅读！
3. 本站强烈打击盗版/破解等有损他人权益和违法作为，请各位会员支持正版！
4. 编程技术 > 如何理解MySQL5.6中的PERFORMANCE_SCHEM
