版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/sun_ashe/article/details/82111156
日常管理
- 1，用户登陆状态监控
#最近使用performance_schema最多的一个场景，通过查询accounts表进行用户登陆信息监控，不管长链接还是短链接，都可以捕获到，并且默认状态下的pfs库就支持。最近在做服务器资源回收，通过使用脚本监控此表，即可知道谁还在访问此实例,如果通过账号查不到使用人，就从cmdb种查询机器所属人。
mysql> select * from accounts;
+-------------+---------------+---------------------+-------------------+
| USER | HOST | CURRENT_CONNECTIONS | TOTAL_CONNECTIONS |
+-------------+---------------+---------------------+-------------------+
| NULL | NULL | 26 | 29 |
| ha_op | 127.0.0.1 | 2 | 2 |
| repl | 100.107.21.12 | 1 | 1 |
| dba_manager | 127.0.0.1 | 3 | 6 |
| action | 10.127.33.79 | 0 | 6 |
+-------------+---------------+---------------------+-------------------+
5 rows in set (0.00 sec)
- 2，复制监控，在出现复制中断时，这种方法比show slave status显示效果更直观。但是人手动敲起来比较费劲。可以做到脚本中，或者监控告警直接细化到channel级别。
mysql> select replication_applier_status.channel_name,replication_applier_status.SERVICE_STATE as sql_thread_status,replication_connection_status.SERVICE_STATE as io_thread_status from replication_applier_status,replication_connection_status where replication_applier_status.CHANNEL_NAME=replication_connection_status.CHANNEL_NAME;
+--------------+-------------------+------------------+
| channel_name | sql_thread_status | io_thread_status |
+--------------+-------------------+------------------+
| crm_im_221 | ON | ON |
| crs | ON | ON |
| datagent_161 | ON | ON |
| finance | ON | ON |
| lawagent_218 | ON | ON |
| lawsuit_215 | ON | ON |
| opui_181 | ON | ON |
| product | ON | ON |
| repay_164 | ON | ON |
| voip_133 | ON | ON |
+--------------+-------------------+------------------+
10 rows in set (0.00 sec)
- 3，查看其他session的variables
mysql> show processlist;
+----+------+-----------+--------------------+---------+------+----------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-----------+--------------------+---------+------+----------+------------------+
| 6 | ashe | localhost | performance_schema | Query | 0 | starting | show processlist |
| 8 | ashe | localhost | NULL | Sleep | 338 | | NULL |
+----+------+-----------+--------------------+---------+------+----------+------------------+
2 rows in set (0.00 sec)
mysql> select * from performance_schema.variables_by_thread where VARIABLE_NAME='sql_log_bin' and THREAD_ID=sys.ps_thread_id(8);
+-----------+---------------+----------------+
| THREAD_ID | VARIABLE_NAME | VARIABLE_VALUE |
+-----------+---------------+----------------+
| 58 | sql_log_bin | OFF |
+-----------+---------------+----------------+
1 row in set (0.00 sec)
- 4，查看数据库中哪些索引重复建立
```shell
mysql> select * from sys.schema_redundant_indexes limit 2\G
*************************** 1. row ***************************
table_schema: ermasdb
table_name: ermas_address_book
redundant_index_name: idx_address_book
redundant_index_columns: CUST_NO
redundant_index_non_unique: 1
dominant_index_name: custNoPhoneNbr
dominant_index_columns: CUST_NO,PHONE_NBR
dominant_index_non_unique: 1
subpart_exists: 0
sql_drop_index: ALTER TABLE `ermasdb`.`ermas_address_book` DROP INDEX `idx_address_book`
*******
******************** 2. row ***************************
table_schema: ermasdb
table_name: ermas_address_book_access_rec
redundant_index_name: ID
redundant_index_columns: ID
redundant_index_non_unique: 0
dominant_index_name: PRIMARY
dominant_index_columns: ID
dominant_index_non_unique: 0
subpart_exists: 0
sql_drop_index: ALTER TABLE `ermasdb`.`ermas_address_book_access_rec` DROP INDEX `ID`
2 rows in set (12.09 sec)
- 5，查看没有用到的索引
mysql> select * from sys.schema_unused_indexes limit 10;
+---------------+-------------------------+--------------------------------------+
| object_schema | object_name | index_name |
+---------------+-------------------------+--------------------------------------+
| crm_im | im_session_record | index_im_session_record_fromUserId |
| crm_im | im_session_record | index_session_record_count_endDate |
| crm_im | im_session_record | index_im_session_record_toUserId |
| crm_im | im_session_record | uk_im_session_record_sessionId |
| crm_im | im_session_record_count | index_session_record_count_sessionId |
| crs | forbidden_user | idx_user_uuid |
| crs | forbidden_user | uni_topic_user_uuid |
| crs | forbidden_user | idx_type |
| crs | reply_detail_0 | uni_reply_uuid |
| crs | reply_detail_1 | uni_reply_uuid |
+---------------+-------------------------+--------------------------------------+
10 rows in set (0.52 sec)mysql5.6没有sys库，怎么看没有用到的索引？
select
`performance_schema`.`table_io_waits_summary_by_index_usage`.`OBJECT_SCHEMA` AS `object_schema`,
`performance_schema`.`table_io_waits_summary_by_index_usage`.`OBJECT_NAME` AS `object_name`,
`performance_schema`.`table_io_waits_summary_by_index_usage`.`INDEX_NAME` AS `index_name`
from
`performance_schema`.`table_io_waits_summary_by_index_usage`
where
(
(`performance_schema`.`table_io_waits_summary_by_index_usage`.`INDEX_NAME` is not null)
and
(`performance_schema`.`table_io_waits_summary_by_index_usage`.`COUNT_STAR` = 0)
and
(`performance_schema`.`table_io_waits_summary_by_index_usage`.`OBJECT_SCHEMA` <> 'mysql')
and
(`performance_schema`.`table_io_waits_summary_by_index_usage`.`INDEX_NAME` <> 'PRIMARY')
)
order by
`performance_schema`.`table_io_waits_summary_by_index_usage`.`OBJECT_SCHEMA`,
`performance_schema`.`table_io_waits_summary_by_index_usage`.`OBJECT_NAME`;
- 6 setup_actors
锁相关
目前mysql版本（5.7.17）中，performance_schema跟锁相关的表有两个，分别是metadata_locks和 table_handles。mysql还没有把所有跟锁相关的信息全部放在performance_schema 中去展示，information_schema依然发挥余热，以后会慢慢把锁相关的信息放在pfs中。
- 1，找到未提交事务的sql
session 1
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from test;
+----+------+
| id | name |
+----+------+
| 1 | a |
| 2 | b |
| 3 | c |
+----+------+
3 rows in set (0.00 sec)
mysql> delete from test where id=1;
Query OK, 1 row affected (0.00 sec)
session 2
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from test;
+----+------+
| id | name |
+----+------+
| 1 | a |
| 2 | b |
| 3 | c |
+----+------+
3 rows in set (0.00 sec)
mysql> delete from test where id=1;
session 3
mysql> select * from INNODB_LOCKS;
+---------------+-------------+-----------+-----------+---------------+------------+------------+-----------+----------+-----------+
| lock_id | lock_trx_id | lock_mode | lock_type | lock_table | lock_index | lock_space | lock_page | lock_rec | lock_data |
+---------------+-------------+-----------+-----------+---------------+------------+------------+-----------+----------+-----------+
| 219373:93:3:2 | 219373 | X | RECORD | `ashe`.`test` | PRIMARY | 93 | 3 | 2 | 1 |
| 219368:93:3:2 | 219368 | X | RECORD | `ashe`.`test` | PRIMARY | 93 | 3 | 2 | 1 |
+---------------+-------------+-----------+-----------+---------------+------------+------------+-----------+----------+-----------+
2 rows in set, 1 warning (0.01 sec)
mysql> select * from INNODB_LOCK_WAITS;
+-------------------+-------------------+-----------------+------------------+
| requesting_trx_id | requested_lock_id | blocking_trx_id | blocking_lock_id |
+-------------------+-------------------+-----------------+------------------+
| 3601 | 3601:32:3:1 | 3600 | 3600:32:3:1 |
+-------------------+-------------------+-----------------+------------------+
1 row in set, 1 warning (0.00 sec)
session 4
先查到是哪个未提交的线程造成阻塞的。
mysql> select * from sys.innodb_lock_waits\G
*************************** 1. row ***************************
wait_started: 2017-04-17 16:12:31
wait_age: 00:00:44
wait_age_secs: 44
locked_table: `ashe`.`test`
locked_index: PRIMARY
locked_type: RECORD
waiting_trx_id: 219373
waiting_trx_started: 2017-04-17 16:12:21
waiting_trx_age: 00:00:54
waiting_trx_rows_locked: 1
waiting_trx_rows_modified: 0
waiting_pid: 26
waiting_query: delete from test where id=1
waiting_lock_id: 219373:93:3:2
waiting_lock_mode: X
blocking_trx_id: 219368
blocking_pid: 25
blocking_query: NULL
blocking_lock_id: 219368:93:3:2
blocking_lock_mode: X
blocking_trx_started: 2017-04-17 16:12:00
blocking_trx_age: 00:01:15
blocking_trx_rows_locked: 1
blocking_trx_rows_modified: 1
sql_kill_blocking_query: KILL QUERY 25
sql_kill_blocking_connection: KILL 25
1 row in set, 3 warnings (0.00 sec)
mysql> show warnings;
+---------+------+-----------------------------------------------------------------------------------------------+
| Level | Code | Message |
+---------+------+-----------------------------------------------------------------------------------------------+
| Warning | 1681 | 'INFORMATION_SCHEMA.INNODB_LOCK_WAITS' is deprecated and will be removed in a future release. |
| Warning | 1681 | 'INFORMATION_SCHEMA.INNODB_LOCKS' is deprecated and will be removed in a future release. |
| Warning | 1681 | 'INFORMATION_SCHEMA.INNODB_LOCKS' is deprecated and will be removed in a future release. |
+---------+------+-----------------------------------------------------------------------------------------------+
3 rows in set (0.00 sec)
但此时已经无法通过show processlist查看到线程3执行的sql，或者说线程3事务中的哪条sql造成的。
此时可以通过查看performance schema中的statement相关表来查看。
events_statements_current ##当前所有线程最后执行的sql。
events_statements_history ##保存线程最近performance_schema_events_statements_history_size 个数的event
events_statements_history_long ##保存最近performance_schema_events_statements_history_long_size个数的event statement*************************** 15. row ***************************
THREAD_ID: 46
EVENT_ID: 557
END_EVENT_ID: 570
EVENT_NAME: statement/sql/begin
SOURCE: socket_connection.cc:95
TIMER_START: 23956057411540000
TIMER_END: 23956057609814000
TIMER_WAIT: 198274000
LOCK_TIME: 0
SQL_TEXT: begin
DIGEST: f57daa74a09445d1e1c496f28fe6d906
DIGEST_TEXT: BEGIN
CURRENT_SCHEMA: ashe
OBJECT_TYPE: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
OBJECT_INSTANCE_BEGIN: NULL
MYSQL_ERRNO: 0
RETURNED_SQLSTATE: 00000
MESSAGE_TEXT: NULL
ERRORS: 0
WARNINGS: 0
ROWS_AFFECTED: 0
ROWS_SENT: 0
ROWS_EXAMINED: 0
CREATED_TMP_DISK_TABLES: 0
CREATED_TMP_TABLES: 0
SELECT_FULL_JOIN: 0
SELECT_FULL_RANGE_JOIN: 0
SELECT_RANGE: 0
SELECT_RANGE_CHECK: 0
SELECT_SCAN: 0
SORT_MERGE_PASSES: 0
SORT_RANGE: 0
SORT_ROWS: 0
SORT_SCAN: 0
NO_INDEX_USED: 0
NO_GOOD_INDEX_USED: 0
NESTING_EVENT_ID: NULL
NESTING_EVENT_TYPE: NULL
NESTING_EVENT_LEVEL: 0
*************************** 16. row ***************************
THREAD_ID: 46
EVENT_ID: 572
END_EVENT_ID: 624
EVENT_NAME: statement/sql/select
SOURCE: socket_connection.cc:95
TIMER_START: 23966445916567000
TIMER_END: 23966446333843000
TIMER_WAIT: 417276000
LOCK_TIME: 294000000
SQL_TEXT: select * from test
DIGEST: 27fbb298c187f24abf99b059f356e195
DIGEST_TEXT: SELECT * FROM `test`
CURRENT_SCHEMA: ashe
OBJECT_TYPE: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
OBJECT_INSTANCE_BEGIN: NULL
MYSQL_ERRNO: 0
RETURNED_SQLSTATE: NULL
MESSAGE_TEXT: NULL
ERRORS: 0
WARNINGS: 0
ROWS_AFFECTED: 0
ROWS_SENT: 3
ROWS_EXAMINED: 3
CREATED_TMP_DISK_TABLES: 0
CREATED_TMP_TABLES: 0
SELECT_FULL_JOIN: 0
SELECT_FULL_RANGE_JOIN: 0
SELECT_RANGE: 0
SELECT_RANGE_CHECK: 0
SELECT_SCAN: 1
SORT_MERGE_PASSES: 0
SORT_RANGE: 0
SORT_ROWS: 0
SORT_SCAN: 0
NO_INDEX_USED: 1
NO_GOOD_INDEX_USED: 0
NESTING_EVENT_ID: 563
NESTING_EVENT_TYPE: TRANSACTION
NESTING_EVENT_LEVEL: 0
*************************** 17. row ***************************
THREAD_ID: 46
EVENT_ID: 626
END_EVENT_ID: 690
EVENT_NAME: statement/sql/delete
SOURCE: socket_connection.cc:95
TIMER_START: 23973031583421000
TIMER_END: 23973040561642000
TIMER_WAIT: 8978221000
LOCK_TIME: 1438000000
SQL_TEXT: delete from test where id=1
DIGEST: 21ddab0ad3ed4e5a8bfe56c2e832dcf8
DIGEST_TEXT: DELETE FROM `test` WHERE `id` = ?
CURRENT_SCHEMA: ashe
OBJECT_TYPE: NULL
OBJECT_SCHEMA: NULL
OBJECT_NAME: NULL
OBJECT_INSTANCE_BEGIN: NULL
MYSQL_ERRNO: 0
RETURNED_SQLSTATE: 00000
MESSAGE_TEXT: NULL
ERRORS: 0
WARNINGS: 0
ROWS_AFFECTED: 1
ROWS_SENT: 0
ROWS_EXAMINED: 1
CREATED_TMP_DISK_TABLES: 0
CREATED_TMP_TABLES: 0
SELECT_FULL_JOIN: 0
SELECT_FULL_RANGE_JOIN: 0
SELECT_RANGE: 0
SELECT_RANGE_CHECK: 0
SELECT_SCAN: 0
SORT_MERGE_PASSES: 0
SORT_RANGE: 0
SORT_ROWS: 0
SORT_SCAN: 0
NO_INDEX_USED: 0
NO_GOOD_INDEX_USED: 0
NESTING_EVENT_ID: 563
NESTING_EVENT_TYPE: TRANSACTION
NESTING_EVENT_LEVEL: 0
17 rows in set (0.42 sec)metadata_locks使用
顾名思义，这张表用来展现数据库中的元数据信息锁。
从此表可以获取到的信息有
- 1，谁当前拥有对谁的锁，例如：
mysql> select * from metadata_locks;
+-------------+--------------------+----------------+-----------------------+-------------+---------------+-------------+-------------------+-----------------+----------------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_DURATION | LOCK_STATUS | SOURCE | OWNER_THREAD_ID | OWNER_EVENT_ID |
+-------------+--------------------+----------------+-----------------------+-------------+---------------+-------------+-------------------+-----------------+----------------+
| TABLE | performance_schema | metadata_locks | 140608438136768 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6030 | 68 | 199 |
+-------------+--------------------+----------------+-----------------------+-------------+---------------+-------------+-------------------+-----------------+----------------+
1 row in set (0.00 sec)
- 2，谁正在请求谁的锁，例如：
#THREAD_ID为69的线程已经占有ashe.test表的元数据信息SHARED_READ锁，而THREAD_ID为70的线程正在申请ashe.test表的元数据信息的EXCLUSIVE锁，如果一直获取不到此锁，则等待超时，关于锁超时.
mysql> select * from metadata_locks;
+-------------+--------------------+----------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_DURATION | LOCK_STATUS | SOURCE | OWNER_THREAD_ID | OWNER_EVENT_ID |
+-------------+--------------------+----------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+
| TABLE | ashe | test | 140608773683968 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6030 | 69 | 157 |
| GLOBAL | NULL | NULL | 140608505192896 | INTENTION_EXCLUSIVE | STATEMENT | GRANTED | sql_base.cc:5496 | 70 | 73 |
| SCHEMA | ashe | NULL | 140608505178816 | INTENTION_EXCLUSIVE | TRANSACTION | GRANTED | sql_base.cc:5481 | 70 | 73 |
| TABLE | ashe | test | 140608505192800 | EXCLUSIVE | TRANSACTION | PENDING | sql_parse.cc:6030 | 70 | 73 |
| TABLE | performance_schema | metadata_locks | 140608371049408 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6030 | 71 | 189 |
+-------------+--------------------+----------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+
5 rows in set (0.00 sec)
- 3，被死锁检测器杀掉的锁请求，或者是锁请求超时的。
疑问点？元数据信息死锁举例？？
通过 metadata_locks中的信息，可以很清楚的发现各线程之间持有锁与申请锁之间的依赖关系。
与此表相关的全局变量和全局状态值
mysql> show global variables like '%performance_schema_max_metadata_locks%';
+---------------------------------------+-------+
| Variable_name | Value |
+---------------------------------------+-------+
| performance_schema_max_metadata_locks | -1 |
+---------------------------------------+-------+
1 row in set (0.00 sec)
mysql> show global status like '%Performance_schema_metadata_lock_lost%';
+---------------------------------------+-------+
| Variable_name | Value |
+---------------------------------------+-------+
| Performance_schema_metadata_lock_lost | 0 |
+---------------------------------------+-------+
1 row in set (0.00 sec)什么是元数据信息？
什么是元数据信息锁？
使用前开启对元数据信息锁的监控
mysql> select * from setup_instruments where NAME like '%meta%'
-> ;
+------------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+------------------------------------------------------+---------+-------+
| wait/io/file/csv/metadata | YES | YES |
| wait/io/file/archive/metadata | YES | YES |
| stage/sql/Waiting for tablespace metadata lock | NO | NO |
| stage/sql/Waiting for schema metadata lock | NO | NO |
| stage/sql/Waiting for table metadata lock | NO | NO |
| stage/sql/Waiting for stored function metadata lock | NO | NO |
| stage/sql/Waiting for stored procedure metadata lock | NO | NO |
| stage/sql/Waiting for trigger metadata lock | NO | NO |
| stage/sql/Waiting for event metadata lock | NO | NO |
| memory/performance_schema/metadata_locks | YES | NO |
| wait/lock/metadata/sql/mdl | NO | NO |
+------------------------------------------------------+---------+-------+
mysql> update setup_instruments set ENABLED='Yes',TIMED='Yes' where NAME like '%meta%';
Query OK, 9 rows affected (0.00 sec)
Rows matched: 11 Changed: 9 Warnings: 0
#例如当前查询到的metadata_locks表里的数据
mysql> select * from metadata_locks;
+-------------+--------------------+----------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_DURATION | LOCK_STATUS | SOURCE | OWNER_THREAD_ID | OWNER_EVENT_ID |
+-------------+--------------------+----------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+
| TABLE | ashe | test_gtid | 140608371049408 | SHARED_WRITE | TRANSACTION | GRANTED | sql_parse.cc:6030 | 60 | 21 |
| GLOBAL | NULL | NULL | 140608303883088 | INTENTION_EXCLUSIVE | STATEMENT | GRANTED | sql_base.cc:5496 | 56 | 141 |
| SCHEMA | ashe | NULL | 140608303950064 | INTENTION_EXCLUSIVE | TRANSACTION | GRANTED | sql_base.cc:5481 | 56 | 141 |
| TABLE | ashe | test_gtid | 140608303896096 | EXCLUSIVE | TRANSACTION | PENDING | sql_parse.cc:6030 | 56 | 141 |
| TABLE | performance_schema | metadata_locks | 140608572299840 | SHARED_READ | TRANSACTION | GRANTED | sql_parse.cc:6030 | 61 | 213 |
+-------------+--------------------+----------------+-----------------------+---------------------+---------------+-------------+-------------------+-----------------+----------------+通过pstack查看mysql线程堆栈信息,可以看到申请mdl锁的线程
Thread 7 (Thread 0x7fe238119700 (LWP 9587)):
#0 0x000000384100ba5e in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x0000000000c527d0 in MDL_wait::timed_wait(MDL_context_owner*, timespec*, bool, PSI_stage_info_v1 const*) ()
#2 0x0000000000c54ba0 in MDL_context::acquire_lock(MDL_request*, unsigned long) ()
#3 0x0000000000c556e5 in MDL_context::acquire_locks(I_P_List<MDL_request, I_P_List_adapter<MDL_request, &(MDL_request::next_in_list), &(MDL_request::prev_in_list)>, I_P_List_counter, I_P_List_no_push_back<MDL_request> >*, unsigned long) ()
#4 0x0000000000ca2585 in lock_table_names(THD*, TABLE_LIST*, TABLE_LIST*, unsigned long, unsigned int) ()
#5 0x0000000000d67b7d in mysql_rm_table(THD*, TABLE_LIST*, char, char) ()
#6 0x0000000000cfdbf2 in mysql_execute_command(THD*, bool) ()
#7 0x0000000000d022f5 in mysql_parse(THD*, Parser_state*) ()
#8 0x0000000000d034ff in dispatch_command(THD*, COM_DATA const*, enum_server_command) ()
#9 0x0000000000d04374 in do_command(THD*) ()
#10 0x0000000000dd36cc in handle_connection ()
#11 0x0000000000f51911 in pfs_spawn_thread ()
#12 0x0000003841007aa1 in start_thread () from /lib64/libpthread.so.0
#13 0x0000003840ce8aad in clone () from /lib64/libc.so.6
metadata_locks表字段详解
mysql> desc metadata_locks;
+-----------------------+---------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-----------------------+---------------------+------+-----+---------+-------+
| OBJECT_TYPE | varchar(64) | NO | | NULL | |
| OBJECT_SCHEMA | varchar(64) | YES | | NULL | |
| OBJECT_NAME | varchar(64) | YES | | NULL | |
| OBJECT_INSTANCE_BEGIN | bigint(20) unsigned | NO | | NULL | |
| LOCK_TYPE | varchar(32) | NO | | NULL | |
| LOCK_DURATION | varchar(32) | NO | | NULL | |
| LOCK_STATUS | varchar(32) | NO | | NULL | |
| SOURCE | varchar(64) | YES | | NULL | |
| OWNER_THREAD_ID | bigint(20) unsigned | YES | | NULL | |
| OWNER_EVENT_ID | bigint(20) unsigned | YES | | NULL | |
+-----------------------+---------------------+------+-----+---------+-------+
mutex_instances
什么是mutex？
http://www.tocker.ca/2013/11/27/what-is-a-mutex-anyway.html
简而言之：
mutex是一种互斥锁，是保护临界资源的并发访问的一种机制。
不只是mysql,在大多数多线程程序中，都需要mutex来保护某些临界资源的正确性。mutex跟行锁和表锁是不同的概念。
Some examples
….
update setup_instruments set ENABLED=’yes’,TIMED=’yes’ where name like ‘%mutex%’;
查询性能相关
- 1，全表扫描的sql
statements_with_full_table_scans
mysql> select * from sys.statements_with_full_table_scans where db='ashe'\G
*************************** 1. row ***************************
query: SELECT * FROM `test`
db: ashe
exec_count: 2
total_latency: 869.14 us
no_index_used_count: 2
no_good_index_used_count: 0
no_index_used_pct: 100
rows_sent: 6
rows_examined: 6
rows_sent_avg: 3
rows_examined_avg: 3
first_seen: 2017-04-17 16:12:01
last_seen: 2017-04-17 16:12:22
digest: 27fbb298c187f24abf99b059f356e195
*************************** 2. row ***************************
query: SELECT * FROM `test` WHERE NAME = ?
db: ashe
exec_count: 3
total_latency: 4.99 ms
no_index_used_count: 1
no_good_index_used_count: 0
no_index_used_pct: 33
rows_sent: 2
rows_examined: 4
rows_sent_avg: 1
rows_examined_avg: 1
first_seen: 2017-04-17 16:03:51
last_seen: 2017-04-17 16:42:18
digest: 93dd47f72504a4b38929ade2c1bc4f76
2 rows in set (0.01 sec)
- 2，需要用到filesort的sql
db显示有问题，并非为真实的表所在库名，而是执行sql时，use到的库名。
mysql> select * from sys.statements_with_sorting where query like '%test%'\G
*************************** 1. row ***************************
query: SELECT * FROM `ashe` . `test` ORDER BY NAME
db: performance_schema
exec_count: 2
total_latency: 1.58 ms
sort_merge_passes: 0
avg_sort_merges: 0
sorts_using_scans: 2
sort_using_range: 0
rows_sorted: 6
avg_rows_sorted: 3
first_seen: 2017-04-17 18:20:46
last_seen: 2017-04-17 18:26:13
digest: 802a62af8e35a94e02e31d9c70e18400
*************************** 2. row ***************************
query: SELECT COUNT ( * ) FROM `ashe` . `test` GROUP BY NAME LIMIT ?
db: performance_schema
exec_count: 1
total_latency: 1.21 ms
sort_merge_passes: 0
avg_sort_merges: 0
sorts_using_scans: 1
sort_using_range: 0
rows_sorted: 1
avg_rows_sorted: 1
first_seen: 2017-04-17 18:28:51
last_seen: 2017-04-17 18:28:51
digest: 6e5efebb71ed41d8f1a1be3f50c9318f
*************************** 3. row ***************************
query: SELECT COUNT ( * ) FROM `ashe` . `test` GROUP BY NAME
db: NULL
exec_count: 1
total_latency: 419.97 us
sort_merge_passes: 0
avg_sort_merges: 0
sorts_using_scans: 1
sort_using_range: 0
rows_sorted: 3
avg_rows_sorted: 3
first_seen: 2017-04-17 18:31:20
last_seen: 2017-04-17 18:31:20
digest: 0bc4ab04666b5e991ecdf5beff298c66
*************************** 4. row ***************************
query: SELECT COUNT ( * ) FROM `ashe` . `test` GROUP BY NAME
db: performance_schema
exec_count: 1
total_latency: 407.22 us
sort_merge_passes: 0
avg_sort_merges: 0
sorts_using_scans: 1
sort_using_range: 0
rows_sorted: 3
avg_rows_sorted: 3
first_seen: 2017-04-17 18:21:56
last_seen: 2017-04-17 18:21:56
digest: 0bc4ab04666b5e991ecdf5beff298c66
4 rows in set (0.02 sec)
- 4，用到临时表的sql
mysql> select * from sys.statements_with_temp_tables order by last_seen desc limit 2\G
*************************** 1. row ***************************
query: EXPLAIN SELECT COUNT ( * ) FROM `ashe` . `test` GROUP BY NAME
db: performance_schema
exec_count: 2
total_latency: 2.67 ms
memory_tmp_tables: 2
disk_tmp_tables: 0
avg_tmp_tables_per_query: 1
tmp_tables_to_disk_pct: 0
first_seen: 2017-04-17 18:28:27
last_seen: 2017-04-17 18:33:11
digest: 47eed23914b71703360399c64fb1be32
*************************** 2. row ***************************
query: SELECT COUNT ( * ) FROM `ashe` . `test` GROUP BY NAME
db: NULL
exec_count: 1
total_latency: 419.97 us
memory_tmp_tables: 1
disk_tmp_tables: 0
avg_tmp_tables_per_query: 1
tmp_tables_to_disk_pct: 0
first_seen: 2017-04-17 18:31:20
last_seen: 2017-04-17 18:31:20
digest: 0bc4ab04666b5e991ecdf5beff298c66
2 rows in set (0.02 sec)压测信息收集
1,mysql配置准备
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE '%statement/%';
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE '%stage/%';
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%events_statements_%';
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%events_stages_%';
insert into performance_schema.setup_actors values('%','paycenter_rw','%','YES','YES');
update performance_schema.setup_actors set ENABLED='NO' where USER != 'paycenter_rw';
update performance_schema.setup_objects set ENABLED='NO',timed='NO';
insert into performance_schema.setup_objects values('table','paycenter','%','YES','YES');历史数据清理
定位sql的每个环节时间
SELECT EVENT_ID, TRUNCATE(TIMER_WAIT/1000000000000,6) as Duration, SQL_TEXT FROM performance_schema.events_statements_history_long WHERE SQL_TEXT like '%10001%';
SELECT event_name AS Stage, TRUNCATE(TIMER_WAIT/1000000000000,6) AS Duration FROM performance_schema.events_stages_history_long WHERE NESTING_EVENT_ID=31;