MySQL8.0 SYS スキーマ概要

MySQL8.0 SYS Schema概要
MySQL SYS Schemaによるパフォーマンスモニタリング
Updated: 2018/05/10
@RDBMS
URL: http://variable.jp

SYS Schema in MySQL8.0.11
[sys]> select * from schema_object_overview where db = 'sys';
+-----+---------------+-------+
| db | object_type | count |
+-----+---------------+-------+
| sys | BASE TABLE | 1 |
| sys | FUNCTION | 22 |
| sys | INDEX (BTREE) | 1 |
| sys | PROCEDURE | 26 |
| sys | TRIGGER | 2 |
| sys | VIEW | 100 |
+-----+---------------+-------+
6 rows in set (0.16 sec)
MySQL5.7.21と比較しても、VIEWの数等に変化はなく、
INDEX等が追加されただけの様に見える。
但し、VIEWの中身は若干調整が入っている。
詳細： https://github.com/mysql/mysql-sys

VIEWの種類
statement_* SQL文分析ビュー
user_* ユーザ集計ビュー
host_* ホスト集計ビュー
io_* ファイルIO 集計ビュー
schema_* スキーマ分析ビュー
wait_* 「待機」分析ビュー
root@localhost [sys]> show tables like '%statement%';
+-----------------------------------------------+
| Tables_in_sys (%statement%) |
+-----------------------------------------------+
| host_summary_by_statement_latency |
| host_summary_by_statement_type |
| statement_analysis |
| statements_with_errors_or_warnings |
| statements_with_full_table_scans |
| statements_with_runtimes_in_95th_percentile |
| statements_with_sorting |
| statements_with_temp_tables |
| user_summary_by_statement_latency |
| user_summary_by_statement_type |
| x$host_summary_by_statement_latency |
| x$host_summary_by_statement_type |
| x$statement_analysis |
| x$statements_with_errors_or_warnings |
| x$statements_with_full_table_scans |
| x$statements_with_runtimes_in_95th_percentile |
| x$statements_with_sorting |
| x$statements_with_temp_tables |
| x$user_summary_by_statement_latency |
| x$user_summary_by_statement_type |
+-----------------------------------------------+
X$から始まるViewとX$が付かないViewがある。
X$が付かないViewは、管理者が分かり易いように”ms”, “s”等の単位
が付加されている。
+----------------+-------------------+---------------+
| user | statement_latency | rows_affected |
+----------------+-------------------+---------------+
| root@localhost | 61.61 ms | 0 |
+----------------+-------------------+---------------+
1 row in set (0.06 sec)
https://dev.mysql.com/doc/refman/5.7/en/sys-schema-views.html

例： VIEWの変更箇所 (innodb_lock_waits)
FROM
((((ìnformation_schema`.ìnnodb_lock_waits` `w`
JOIN ìnformation_schema`.ìnnodb_trx` `b` ON ((`b`.`trx_id` = `w`.`blocking_trx_id`)))
JOIN ìnformation_schema`.ìnnodb_trx` `r` ON ((`r`.`trx_id` = `w`.`requesting_trx_id`)))
JOIN ìnformation_schema`.ìnnodb_locks` `bl` ON ((`bl`.`lock_id` = `w`.`blocking_lock_id`)))
JOIN ìnformation_schema`.ìnnodb_locks` `rl` ON ((`rl`.`lock_id` = `w`.`requested_lock_id`)))
ORDER BY `r`.`trx_wait_started`
FROM
((((`performance_schema`.`data_lock_waits` `w`
JOIN ìnformation_schema`.ÌNNODB_TRX` `b` ON ((CONVERT( `b`.`trx_id` USING UTF8MB4) = CAST(`w`.`BLOCKING_ENGINE_TRANSACTION_ID` AS CHAR CHARSET UTF8MB4))))
JOIN ìnformation_schema`.ÌNNODB_TRX` `r` ON ((CONVERT( `r`.`trx_id` USING UTF8MB4) = CAST(`w`.`REQUESTING_ENGINE_TRANSACTION_ID` AS CHAR CHARSET UTF8MB4))))
JOIN `performance_schema`.`data_locks` `bl` ON ((`bl`.ÈNGINE_LOCK_ID` = `w`.`BLOCKING_ENGINE_LOCK_ID`)))
JOIN `performance_schema`.`data_locks` `rl` ON ((`rl`.ÈNGINE_LOCK_ID` = `w`.`REQUESTING_ENGINE_LOCK_ID`)))
ORDER BY `r`.`trx_wait_started`
MySQL5.7.21
MySQL8.0.11

host_summaryおよびx$host_summary
root@localhost [sys]> SELECT * FROM sys.host_summary limit 1G
*************************** 1. row ***************************
host: 192.168.56.1
statements: 293
statement_latency: 798.93 ms
statement_avg_latency: 2.73 ms
table_scans: 28
file_ios: 39
file_io_latency: 159.38 ms
current_connections: 0
total_connections: 2
unique_users: 1
current_memory: 300.96 KiB
total_memory_allocated: 97.71 MiB
root@localhost [sys]>
SQLステートメントのアクティビティ、ファイルI / O、および接続をホスト別にまとめたものです。
データベースに接続してSQLステートメントを実行しているホストが、
ファイルI/Oやメモリーをどれだけ発生させているか確認出来ます。
どのホスト処理が負荷をかけているか容易に確認可能です。

host_summary_by_file_ioおよび x$host_summary_by_file_io
root@localhost [sys]> SELECT * FROM sys.host_summary_by_file_io limit 3G
*************************** 1. row ***************************
host: background
ios: 1792
io_latency: 5.12 s
*************************** 2. row ***************************
host: localhost
ios: 285
io_latency: 943.07 ms
*************************** 3. row ***************************
host: 192.168.56.1
ios: 39
io_latency: 159.38 ms
ファイルI/Oをホストごとにまとめたものです。
デフォルトでは、ファイルI/O全体のレイテンシが降順に並べ替えられて行がソートされます。
データベースに接続しているホストが、ファイルI/Oをどれだけ発生させ
ているか確認出来ます。どのホスト処理がI/O負荷をかけているか容易
に確認可能です。

host_summary_by_file_io_typeとx$host_summary_by_file_io_type
root@localhost [sys]> SELECT * FROM sys.host_summary_by_file_io_type limit 2G
*************************** 1. row ***************************
host: background
event_name: wait/io/file/innodb/innodb_data_file
total: 1528
total_latency: 1.66 s
max_latency: 81.06 ms
*************************** 2. row ***************************
host: background
event_name: wait/io/file/innodb/innodb_log_file
total: 37
total_latency: 45.17 ms
ファイルI/Oをホストとイベントのタイプ別にまとめたものです。
デフォルトでは、行はホストごとにソートされ、合計I/Oレイテンシは降順にソートされます。
データベースに接続しているホストが、ファイルI/Oをどれだけ発生させて
いるか確認出来ます。EVENT_NAMEは計測された値を示しています。

host_summary_by_stagesおよびx$host_summary_by_stages
root@localhost [sys]> SELECT * FROM sys.host_summary_by_stages limit 1G
*************************** 1. row ***************************
host: background
event_name: stage/innodb/buffer pool load
total: 1
avg_latency: 21.87 ms
ステートメントのステージをホストごとにまとめたものです。
デフォルトで、行はホストごとにソートされ、合計レイテンシは降順にソートされます。
ステートメントがどのような状態にあるか、ホスト毎に確認可能です。
処理に時間がかかっている処理順にソートされているため、
ステージ毎に重い処理を特定することが可能です。

host_summary_by_statement_latencyおよび
x$host_summary_by_statement_latency
root@localhost [sys]> SELECT * FROM sys.host_summary_by_statement_latency limit 1G
*************************** 1. row ***************************
host: localhost
total: 259
lock_latency: 101.21 ms
rows_sent: 118
rows_examined: 2758
rows_affected: 0
full_scans: 5
ホストごとにサマライズされた、全体的なステートメント統計を要約します。
デフォルトで、行は合計レイテンシを降順にソートされます。
ホスト毎にステートメントの遅延状態を確認する事が可能です。
処理に時間がかかっているステートメント順にソートされているため、
時間のかかっているステートメントを容易に特定することが可能です。

host_summary_by_statement_typeおよび
x$host_summary_by_statement_type
root@localhost [sys]> SELECT * FROM sys.host_summary_by_statement_type limit 1G
*************************** 1. row ***************************
host: background
statement: select
total: 1
total_latency: 156.43 us
max_latency: 156.43 us
lock_latency: 0 ps
rows_sent: 1
rows_examined: 0
rows_affected: 0
full_scans: 0
実行されたステートメントに関する情報を、ホストおよびステートメントタイプ別にグループ化して要約し
たものです。デフォルトでは、行はホストごとにソートされ、合計レイテンシは降順にソートされます。
ホスト毎のステートメント種類毎にレイテンシを確認可能です。
参照処理が特に重い場合は、メモリー設定やインデックス等を見直して
みるのも良いかもしれません。

innodb_buffer_stats_by_schemaと
x$innodb_buffer_stats_by_schema
root@localhost [sys]> SELECT * FROM sys.innodb_buffer_stats_by_schema limit 2G
*************************** 1. row ***************************
object_schema: mysql
allocated: 3.89 MiB
data: 1.75 MiB
pages: 249
pages_hashed: 81
pages_old: 130
rows_cached: 842
*************************** 2. row ***************************
object_schema: APP
allocated: 64.00 KiB
data: 5.14 KiB
pages: 4
pages_hashed: 0
pages_old: 4
rows_cached: 25
スキーマごとにグループ化されたINFORMATION_SCHEMA INNODB_BUFFER_PAGE表の情報を要約します。
デフォルトで、行はバッファサイズの降順でソートされます。
スキーマ毎にInnoDB Buffer Poolの利用状況を確認する事が出来る為、
メモリーを多く利用しすぎている場合などは、インデックスなどが適切に利
用されているか確認してみると良いかもしれません。

innodb_buffer_stats_by_tableとx$innodb_buffer_stats_by_table
root@localhost [sys]> SELECT * FROM sys.innodb_buffer_stats_by_table limit 2G
*************************** 1. row ***************************
object_name: columns
allocated: 1.23 MiB
data: 948.26 KiB
pages: 79
pages_hashed: 47
pages_old: 57
rows_cached: 3432
*************************** 2. row ***************************
object_name: component
allocated: 544.00 KiB
data: 412.96 KiB
pages: 34
pages_hashed: 31
pages_old: 12
rows_cached: 377
INFORMATION_SCHEMA INNODB_BUFFER_PAGE表の情報をスキーマと表でグループ化して要約したも
のです。デフォルトでは、行はバッファサイズの降順でソートされます。
テーブル毎にInnoDB Buffer Poolの利用状況を確認する事が出来る為、
メモリーを多く利用しすぎている場合などは、インデックスなどが適切に　
利用されているか確認してみると良いかもしれません。

innodb_lock_waitsとx $ innodb_lock_waits
root@localhost [sys]> SELECT * FROM sys.innodb_lock_waits limit 1¥G
*************************** 1. row ***************************
wait_started: 2018-03-09 13:30:03
wait_age: 00:00:03
wait_age_secs: 3
locked_table: `world`.`Demo_City`
locked_index: GEN_CLUST_INDEX
<SNIP>
waiting_query: update Demo_City set Name = 'Japan2' where ID = 1
waiting_lock_id: 1504133:5522:5:2
waiting_lock_mode: X
blocking_trx_id: 1504132
blocking_pid: 9
blocking_query: NULL
blocking_lock_id: 1504132:5522:5:2
<SNIP>
blocking_trx_rows_modified: 1
sql_kill_blocking_query: KILL QUERY 9
sql_kill_blocking_connection: KILL 9
トランザクション待機イベントが発生している、InnoDBロックの状態を要約しています。
既定で、行の降順にロックの待機時間でソートされます。
ロックがかかっている処理を確認する事が可能です。
また、sql_kill_blocking_queryでブロックしている処理を停止、
させる事も可能です。

io_by_thread_by_latencyと x$io_by_thread_by_latency
root@localhost [sys]> SELECT * FROM sys.io_by_thread_by_latency limit 1G
*************************** 1. row ***************************
user: main
total: 136
min_latency: 35.58 ns
avg_latency: 333.45 us
thread_id: 1
processlist_id: NULL
スレッドごとにグループ化されたI/O待機時間を表示するためにI/Oコンシューマを要約します。
デフォルトで、行は合計I/O待機時間を降順にソートされます。
どのスレッド処理がI/Oを多く発生させているか確認できます。
合計だけでなく、平均、最大、最小も確認出来るので、
一時的なものなのか?　等確認する事が出来ます。

io_global_by_file_by_bytesおよびx$io_global_by_file_by_bytes
root@localhost [sys]> SELECT * FROM sys.io_global_by_file_by_bytes limit 2G
*************************** 1. row ***************************
file: @@basedir/data/ibtmp1
count_read: 5
total_read: 80.00 KiB
avg_read: 16.00 KiB
count_write: 521
total_written: 19.95 MiB
avg_write: 39.22 KiB
total: 20.03 MiB
write_pct: 99.61
*************************** 2. row ***************************
file: @@basedir/data/undo_001
count_read: 384
total_read: 6.05 MiB
avg_read: 16.12 KiB
count_write: 7
total_written: 112.00 KiB
avg_write: 16.00 KiB
total: 6.16 MiB
write_pct: 1.78
グローバルI/Oコンシューマを要約し、I/O発生をファイルごとにグループ化して表示します。
デフォルトで、行は合計I/O（読み書きされたバイト数）で降順にソートされます。
どのデータベースファイルにI/Oバイトが多く発生しているか確認出来る
為、ファイルのパスを変更する等の検討材料にも利用可能です。

io_global_by_file_by_latencyおよびx$io_global_by_file_by_latency
root@localhost [sys]> SELECT * FROM sys.io_global_by_file_by_latency limit 2G
*************************** 1. row ***************************
total: 390
count_read: 382
read_latency: 598.46 ms
count_write: 2
write_latency: 15.03 us
count_misc: 6
misc_latency: 198.75 us
*************************** 2. row ***************************
total: 397
count_read: 384
read_latency: 526.24 ms
count_write: 7
write_latency: 46.22 us
count_misc: 6
misc_latency: 198.15 us
グローバルI/Oコンシューマを要約し、ファイルごとにグループ化されたI/O待機時間を表示します。
どのデータベースファイルにI/O遅延が多く発生しているか確認出来る
例) 更新処理が多発してい、UNDO領域の負荷が高い場合

io_global_by_wait_by_bytesおよびx$io_global_by_wait_by_bytes
root@localhost [sys]> SELECT * FROM sys.io_global_by_wait_by_bytes limit 1G
*************************** 1. row ***************************
event_name: innodb/innodb_data_file
total: 1976
min_latency: 0 ps
count_read: 1251
avg_read: 17.76 KiB
count_write: 536
avg_written: 38.96 KiB
total_requested: 42.09 MiB
グローバルI/Oコンシューマを要約し、I/O量と待機時間をイベント別にグループ化して表示。
デフォルトで、行は合計I/O（読み書きされたバイト数）を降順にソートされます。
特定のテーブルの場合、インデックス等も検討してみると良さそうです。

io_global_by_wait_by_latencyおよびx$io_global_by_wait_by_latency
root@localhost [sys]> SELECT * FROM sys.io_global_by_wait_by_latency limit 1G
*************************** 1. row ***************************
event_name: innodb/innodb_data_file
total: 1976
read_latency: 1.67 s
write_latency: 26.17 ms
misc_latency: 2.42 ms
count_read: 1251
avg_read: 17.76 KiB
count_write: 536
avg_written: 38.96 KiB
グローバルI/Oコンシューマを要約し、I/O量と待機時間をイベント別にグループ化して表示します。
特定のテーブルの場合、インデックス等も検討してみると良さそうです。

memory_by_host_by_current_bytesおよび
x$memory_by_host_by_current_bytes
root@localhost [sys]> SELECT * FROM sys.memory_by_host_by_current_bytes limit 2G
*************************** 1. row ***************************
host: background
current_count_used: 2490
current_allocated: 46.25 MiB
current_avg_alloc: 19.02 KiB
current_max_alloc: 24.00 MiB
total_allocated: 102.80 MiB
*************************** 2. row ***************************
host: localhost
current_max_alloc: 1012.80 KiB
ホストごとにグループ化されたメモリー使用量を要約します。
デフォルトで、行は使用されたメモリ量の降順でソートされます。
現在、どのホストがメモリーを多く、使用しているか確認する事が可能。

memory_by_thread_by_current_bytesおよび
x$memory_by_thread_by_current_bytes
root@localhost [sys]> SELECT * FROM sys.memory_by_thread_by_current_bytes limit 2G
*************************** 1. row ***************************
thread_id: 45
user: root@localhost
*************************** 2. row ***************************
thread_id: 42
user: sql/event_scheduler
current_allocated: 16.18 KiB
total_allocated: 16.18 KiB
スレッドごとにグループ化されたメモリー使用量を要約します。
現在、どのスレッドがメモリーを多く、使用しているか確認する事が可能。

memory_by_user_by_current_bytesおよび
x$memory_by_user_by_current_bytes
root@localhost [sys]> SELECT * FROM sys.memory_by_user_by_current_bytes limit 2G
*************************** 1. row ***************************
user: background
current_max_alloc: 24.00 MiB
*************************** 2. row ***************************
user: root
ユーザーごとにグループ化されたメモリー使用量を要約します。
現在、どのユーザーがメモリーを多く、使用しているか確認する事が可能。

memory_global_by_current_bytesおよび
x$memory_global_by_current_bytes
root@localhost [sys]> SELECT * FROM sys.memory_global_by_current_bytes limit 2G
*************************** 1. row ***************************
event_name: memory/performance_schema/events_errors_summary_by_thread_by_error
current_count: 257
current_alloc: 34.20 MiB
high_count: 257
high_alloc: 34.20 MiB
high_avg_alloc: 136.26 KiB
*************************** 2. row ***************************
event_name: memory/innodb/ut0link_buf
current_count: 2
current_alloc: 24.00 MiB
current_avg_alloc: 12.00 MiB
high_count: 2
high_alloc: 24.00 MiB
high_avg_alloc: 12.00 MiB
割り当てられたタイプ（イベント別）毎にグループ化されたメモリー使用量を要約します。　
現在、どのイベントがメモリーを多く、使用しているか確認する事が可能。

memory_global_totalおよびx$memory_global_total
root@localhost [sys]> SELECT * FROM sys.memory_global_total limit 2G
*************************** 1. row ***************************
サーバー内の合計メモリー使用量を要約します。
MySQL全体で利用しているメモリー量の合計を確認出来ます。
搭載されているメモリーと合わせて調整してみてください。

metrics
root@localhost [sys]> SELECT * FROM sys.metrics where Variable_name like 'innodb%' limit 10;
+----------------------------------+--------------------------------------------------+---------------+---------+
| Variable_name | Variable_value | Type | Enabled |
+----------------------------------+--------------------------------------------------+---------------+---------+
| innodb_buffer_pool_bytes_data | 24608768 | Global Status | YES |
| innodb_buffer_pool_bytes_dirty | 65536 | Global Status | YES |
| innodb_buffer_pool_dump_status | Dumping of buffer pool not started | Global Status | YES |
| innodb_buffer_pool_load_status | Buffer pool(s) load completed at 180510 0:55:56 | Global Status | YES |
| innodb_buffer_pool_pages_data | 1502 | Global Status | YES |
| innodb_buffer_pool_pages_dirty | 4 | Global Status | YES |
| innodb_buffer_pool_pages_flushed | 639 | Global Status | YES |
| innodb_buffer_pool_pages_free | 6679 | Global Status | YES |
| innodb_buffer_pool_pages_misc | 11 | Global Status | YES |
| innodb_buffer_pool_pages_total | 8192 | Global Status | YES |
+----------------------------------+--------------------------------------------------+---------------+---------+
MySQLサーバのメトリックを、変数、値、タイプ毎にまとめ、それらが有効かどうかを表示します。
デフォルトで、行は変数の型と名前でソートされます
SHOW VARIABLES等で確認可能な現状の設定値を確認可能です。

processlistとx$processlist
root@localhost [sys]> SELECT * FROM sys.processlist limit 1G
*************************** 1. row ***************************
thd_id: 23
conn_id: NULL
user: innodb/fts_optimize_thread
db: NULL
command: NULL
state: NULL
time: 5940
current_statement: NULL
statement_latency: NULL
progress: NULL
lock_latency: NULL
rows_examined: NULL
プロセスリスト情報を要約します。 SHOW PROCESSLISTステートメントやINFORMATION_SCHEMA
PROCESSLISTテーブルより完全な情報を提供し、非ブロック化しています。
デフォルトで、行はプロセス時間と待機時間の降順でソートされます。
SHOW PROCESSLISTより、詳細な値を確認する事が出来ます。
stateやlock_latency等も確認したい場合は、こちらを利用すると良い。

ps_check_lost_instrumentation
root@localhost [sys]> SELECT * FROM sys. ps_check_lost_instrumentation limit 1¥G
*************************** 1. row ***************************
variable_name: Performance_schema_rwlock_classes_lost
variable_value: 3
パフォーマンススキーマがすべてのランタイムデータを監視できないかどうかを示すために、
失われたパフォーマンススキーマインストゥルメントに関する情報を返します。
パフォーマンススキーマがどのランタイムデータを監視出来ていないか、
不足しているインストゥルメントを確認可能です。

schema_auto_increment_columns
root@localhost [sys]> SELECT * FROM sys.schema_auto_increment_columns limit 1G
*************************** 1. row ***************************
table_schema: APP
table_name: T_ChangeLog
column_name: id
data_type: int
column_type: int(10) unsigned
is_signed: 0
is_unsigned: 1
max_value: 4294967295
auto_increment: 13
auto_increment_ratio: 0.0000
インスタンスで利用している、auto_incrementのテーブル、列一覧を確認する事が可能です。
データ型、現在の利用率(%)なども確認可能。
インスタンスで利用されている, auto_incrementの値を確認可能です。
もし、int等ですでに上限に近い場合は、データ型を変更する等検討可能

schema_index_statisticsおよびx$schema_index_statistics
root@localhost [sys]> SELECT * FROM sys.schema_index_statistics limit 1G
*************************** 1. row ***************************
table_schema: APP
table_name: T_ChangeLog
index_name: PRIMARY
rows_selected: 22
select_latency: 598.65 us
rows_inserted: 0
insert_latency: 0 ps
rows_updated: 0
update_latency: 0 ps
rows_deleted: 0
delete_latency: 0 ps
索引統計を一覧を確認する事が可能です。
デフォルトで、索引レイテンシの合計が降順にソートされます。
インデックスのレイテンシ事にソートされている為、
時間がかかっているインデックス等を容易に確認する事が可能です。

schema_object_overview
root@localhost [sys]> SELECT * FROM sys.schema_object_overview limit 10;
+--------------------+---------------+-------+
| db | object_type | count |
+--------------------+---------------+-------+
| APP | BASE TABLE | 10 |
| APP | INDEX (BTREE) | 11 |
| information_schema | SYSTEM VIEW | 62 |
| mysql | BASE TABLE | 34 |
| mysql | INDEX (BTREE) | 79 |
| performance_schema | BASE TABLE | 102 |
| performance_schema | INDEX (HASH) | 221 |
| sys | BASE TABLE | 1 |
| sys | FUNCTION | 22 |
| sys | INDEX (BTREE) | 1 |
+--------------------+---------------+-------+
各スキーマ内のオブジェクトのタイプをカウントしてまとめたものです。
デフォルトで、行はスキーマとオブジェクトタイプによってソートされます。
スキーマ毎のオブジェクト数などを容易に確認可能です。
データベース移行時などにも、オブジェクト漏れがないか確認可能。

schema_redundant_indexesおよびx$schema_flattened_keys
root@localhost [sys]> SELECT * FROM sys.schema_redundant_indexes limit 1¥G
*************************** 1. row ***************************
table_schema: AdventureWorks2012
table_name: Address
redundant_index_name: rowguid
redundant_index_columns: rowguid
redundant_index_non_unique: 0
dominant_index_name: AK_Address_rowguid
dominant_index_columns: rowguid
dominant_index_non_unique: 0
subpart_exists: 0
sql_drop_index: ALTER TABLE `AdventureWorks2012`.`Address` DROP INDEX `rowguid`
schema_redundant_indexesビューには、重複して不要と考えられる索引が表示されます。
x$schema_flattened_keysビューは、schema_redundant_indexesのヘルパービューです。
重複しているインデックスをスキーマ・テーブル毎に確認可能です。
sql_drop_indexを実行する事で削除することが可能です。

schema_table_lock_waitsと x$schema_table_lock_waits
root@localhost [sys]> SELECT * FROM sys.schema_table_lock_waits limit 1¥G
*************************** 1. row ***************************
object_schema: world
object_name: Demo_City
waiting_thread_id: 40046
waiting_pid: 40022
waiting_account: root@localhost
waiting_lock_type: SHARED_WRITE
waiting_lock_duration: TRANSACTION
waiting_query: update Demo_City set Name = 'Japan2' where ID = 1
waiting_query_secs: 3
<SNIP>
blocking_pid: 40023
blocking_account: root@localhost
blocking_lock_type: SHARED_READ_ONLY
blocking_lock_duration: TRANSACTION
sql_kill_blocking_query: KILL QUERY 40023
sql_kill_blocking_connection: KILL 40023
どのセッションがメタデータのロックを待ってブロックされているのか?、
どの処理が原因でブロックされているのか?を表示します。
どのテーブルがどのような処理に待たされているか確認可能です。

schema_table_statisticsおよび x$schema_table_statistics
root@localhost [sys]> SELECT * FROM sys.schema_table_statistics limit 1¥G
*************************** 1. row ***************************
table_schema: world
table_name: Demo_City
total_latency: 4.55 m
rows_fetched: 40832639
fetch_latency: 4.55 m
<SNIP>
io_read: 448.79 KiB
io_read_latency: 168.89 ms
io_write_requests: 10
io_write: 160.00 KiB
io_write_latency: 2.95 ms
io_misc_requests: 21
io_misc_latency: 16.46 ms
テーブル統計を要約します。デフォルトで、行はテーブルの合計待機時間（最大の競合が最初に発生した表）
を降順にソートされます。 x$ps_schema_table_statistics_ioのヘルパービューを表示します。
テーブル毎の統計を一覧で確認する事が可能です。
特定の処理が遅い時などに、ざっくりと確認するのに使うのも良いかと。

schema_table_statistics_with_bufferおよび
x$schema_table_statistics_with_buffer
root@localhost [sys]> SELECT * FROM sys.schema_table_statistics_with_buffer limit 1¥G
*************************** 1. row ***************************
table_schema: world
table_name: Demo_City
rows_fetched: 40832639
fetch_latency: 4.55 m
rows_inserted: 0
insert_latency: 0 ps
<SNIP>
io_misc_latency: 16.46 ms
innodb_buffer_allocated: 416.00 KiB
innodb_buffer_data: 362.88 KiB
innodb_buffer_free: 53.12 KiB
innodb_buffer_pages: 26
innodb_buffer_pages_hashed: 0
innodb_buffer_pages_old: 0
innodb_buffer_rows_cached: 4104
InnoDBバッファプール統計を含むテーブル統計を要約しています。
デフォルトで、行は合計待機時間（最大の競合が最初に発生した表）を降順にソート。
テーブルのデータがどれだけInnoDB Buffer Poolを利用しているか?
待機処理が発生しているかなど確認する事が出来ます。

schema_unused_indexes
root@localhost [sys]> SELECT * FROM sys.schema_unused_indexes limit 3¥G
*************************** 1. row ***************************
object_schema: AdventureWorks2012
object_name: Address
index_name: IX_Address_AddressLine1_AddressLine2_City_StateProvinceID_Post13
*************************** 2. row ***************************
index_name: AK_Address_rowguid
*************************** 3. row ***************************
index_name: rowguid
使用されたイベントが、存在しないインデックス(使用されないインデックス)がリスト表示されます。
デフォルトでは、行はスキーマとテーブルによってソートされます。
起動してから、一度も利用されていないインデックスを確認する事が
可能です。MySQL8.0から実装されたInvisible Indexと合わせて利用
すると、運用しやすくなるかもしれません。

sessionとx$session
root@localhost [sys]> SELECT * FROM sys.session limit 1G
*************************** 1. row ***************************
thd_id: 52
conn_id: 15
user: admin@192.168.56.1
<SNIP>
lock_latency: 723.00 us
rows_examined: 892
rows_sent: 270
rows_affected: 0
tmp_tables: 1
<SNIP>
trx_latency: 1.56 ms
trx_state: COMMITTED
trx_autocommit: YES
pid: 12824
program_name: MySQLWorkbench
processlistとx $ processlistに似ていますが、
バックグラウンド・プロセスを除外しユーザー・セッションのみを表示します。
ユーザー処理に絞って処理を確認する事が出来るので、
システムのスレッドが多すぎてフィルターしたい場合などに便利。

session_ssl_status
root@localhost [sys]> SELECT * FROM sys.session_ssl_status limit 3;
+-----------+-------------+--------------------+---------------------+
| thread_id | ssl_version | ssl_cipher | ssl_sessions_reused |
+-----------+-------------+--------------------+---------------------+
| 45 | | | 0 |
| 52 | TLSv1.1 | DHE-RSA-AES256-SHA | 0 |
| 53 | TLSv1.1 | DHE-RSA-AES256-SHA | 0 |
+-----------+-------------+--------------------+---------------------+
各接続ごとに、SSLバージョン、暗号、および再使用されたSSLセッションの数が表示されます。
ユーザーごとに利用されている、SSLセッションを確認可能。
ユーザー接続が暗号化されているか確認したい場合は便利。

statement_analysisとx$statement_analysis
root@localhost [sys]> SELECT * FROM sys.statement_analysis limit 1¥G
*************************** 1. row ***************************
query: SELECT LANGUAGE , COUNT ( LANG ... ROUP BY LANGUAGE LIMIT ?, ...
db: world
full_scan: *
exec_count: 10000
err_count: 0
warn_count: 0
<SNIP>
rows_sorted: 100000
sort_merge_passes: 0
digest: 41d00de8eda848e48552d7282da0e4b6
first_seen: 2018-03-09 13:58:39
last_seen: 2018-03-09 14:01:27
統計を集計し、正規化されたステートメントをリストします。
このコンテンツは、MySQL Enterprise Monitor Query Analysisビューに似ています。
デフォルトでは、行は合計レイテンシを降順にソートされます。
重いクエリー、インデックスを利用していないクエリー、
ソートバッファーに収まらない処理等いろいろと確認する事が可能!!
このビューが一番、便利かもしれません。

statements_with_errors_or_warningsおよび
x$statements_with_errors_or_warnings
root@localhost [sys]> SELECT * FROM sys.statements_with_errors_or_warnings limit 1¥G
*************************** 1. row ***************************
query: SELECT `r` . `trx_wait_started ... k_id` , `bl` . `lock_mode` AS
db: sys
exec_count: 2
errors: 0
error_pct: 0.0000
warnings: 6
warning_pct: 300.0000
first_seen: 2018-03-09 13:27:43
last_seen: 2018-03-09 13:30:07
digest: c45b5b6253e8459b144890f2fc813688
エラーまたは警告を生成したステートメントを正規化し表示します。
デフォルトで、行はエラーと警告数の降順によってソートされます。
エラー若しくは警告が発生したステートメントを確認可能です。
exec_count、warningsを確認してみてください。

statements_with_full_table_scansおよび
x$statements_with_full_table_scans
root@localhost [sys]> SELECT * FROM sys.statements_with_full_table_scans limit 1¥G
*************************** 1. row ***************************
query: SELECT COUNT (?) AS `cnt` , `r ... _by_digest` GROUP BY `avg_us`
db: myosm
exec_count: 4
no_index_used_count: 4
no_good_index_used_count: 0
no_index_used_pct: 100
rows_sent: 36
rows_examined: 36
rows_sent_avg: 9
rows_examined_avg: 9
first_seen: 2018-03-09 12:54:54
last_seen: 2018-03-09 12:54:54
digest: c8e66a8fed8ba76991dbc223e5781b6f
フル・テーブル・スキャンを行ったステートメントが正規化され表示されます。
デフォルトで、フルスキャンが完了した時点のレイテンシ合計を降順にソートします。
フルスキャンが発生しているクエリーを確認する事が可能です。
インデックスを利用した方が当然早いので、対応を検討してください。

statements_with_runtimes_in_95th_percentileおよび
x$statements_with_runtimes_in_95th_percentile
root@localhost [sys]> SELECT * FROM sys.statements_with_runtimes_in_95th_percentile limit 1¥G
*************************** 1. row ***************************
query: UPDATE `Demo_City` SET NAME = ? WHERE `ID` = ?
db: world
full_scan:
exec_count: 6
err_count: 0
warn_count: 0
max_latency: 51.27 s
avg_latency: 14.31 s
rows_sent: 0
rows_sent_avg: 0
rows_examined: 24474
rows_examined_avg: 4079
first_seen: 2018-03-09 13:30:02
last_seen: 2018-03-09 14:46:47
digest: 2f1b0052c8ecff3f76fb0b2682de295a
フル・テーブル・スキャンを行ったステートメントが正規化され表示されます。
デフォルトで、フルスキャンが完了した時間の割合、合計レイテンシが降順にソートされます。
マイクロ秒単位の平均実行時間が上位95パーセンタイルにあるすべて
のステートメントがリストアップされているので、こちらも平均実行時間
が遅いクエリーを改善検討するのに利用可能です。

statements_with_sortingおよび x$statements_with_sorting
root@localhost [sys]> SELECT * FROM sys.statements_with_sorting limit 1¥G
*************************** 1. row ***************************
query: SELECT LANGUAGE , COUNT ( LANG ... ROUP BY LANGUAGE LIMIT ?, ...
db: world
exec_count: 10000
sort_merge_passes: 0
avg_sort_merges: 0
sorts_using_scans: 10000
sort_using_range: 0
rows_sorted: 100000
avg_rows_sorted: 10
first_seen: 2018-03-09 13:58:39
last_seen: 2018-03-09 14:01:27
digest: 41d00de8eda848e48552d7282da0e4b6
ソートを実行したステートメントを正規化しリストします。
ソート処理を実行したクエリーを遅い順に確認出来る為、Order by,
Group byでインデックスが利用されているか確認する事が可能。

statements_with_temp_tablesおよび
x$statements_with_temp_tables
root@localhost [sys]> SELECT * FROM sys.statements_with_temp_tables limit 1G
*************************** 1. row ***************************
query: ( SELECT `lower` ( `performanc ... ) AND ( `performance_schema` .
db: sys
exec_count: 11
memory_tmp_tables: 33
disk_tmp_tables: 22
avg_tmp_tables_per_query: 3
tmp_tables_to_disk_pct: 67
first_seen: 2018-05-10 02:20:40.974650
last_seen: 2018-05-10 02:33:01.085611
digest: c1b11eeca3b83a765d6624f04ef957154ffda0bb8bdf45dca86e82730d33ef40
一時表を使用したステートメントが正規化されリストされます。デフォルトで、使用されるディスク上の
一時テーブルの数、使用されるメモリ内の一時テーブルが降順で行がソートされます。
tempテーブル、tempテーブルサイズが不足していて、
ディスク処理されたクエリー等を確認する事が可能です。

user_summaryとx$user_summaryのビュー
root@localhost [sys]> SELECT * FROM sys.user_summary limit 1G
*************************** 1. row ***************************
user: root
statements: 21305
statement_latency: 1.67 s
statement_avg_latency: 78.36 us
table_scans: 69
file_ios: 489
file_io_latency: 385.18 ms
current_connections: 1
total_connections: 1
unique_hosts: 1
current_memory: 3.45 MiB
total_memory_allocated: 521.85 MiB
ユーザー毎にステートメントのアクティビティ、ファイルI/O、および接続を要約します。
どのアプリケーションユーザーの処理が重いのか?
どれだけメモリーを利用しているのか?等を確認する事が可能です。

user_summary_by_file_ioと x$user_summary_by_file_io
root@localhost [sys]> SELECT * FROM sys.user_summary_by_file_io limit 4;
+------------+------+------------+
| user | ios | io_latency |
+------------+------+------------+
| background | 2350 | 1.87 s |
| root | 501 | 385.29 ms |
| app_user | 24 | 1.88 ms |
| admin | 5 | 47.14 us |
+------------+------+------------+
ファイルI/Oをユーザー別にまとめたものです。
デフォルトで、ファイルI/O全体のレイテンシが降順にソートされます。
どれだけI/O処理を発生させているのか?等を確認する事が可能です。

user_summary_by_file_io_typeとx$user_summary_by_file_io_type
root@localhost [sys]> SELECT * FROM sys.user_summary_by_file_io_type limit 5;
+------------+--------------------------------------+-------+----------+-------------+
| user | event_name | total | latency | max_latency |
+------------+--------------------------------------+-------+----------+-------------+
| admin | wait/io/file/csv/data | 4 | 28.87 us | 18.40 us |
| admin | wait/io/file/sql/slow_log | 1 | 18.27 us | 18.27 us |
| app_user | wait/io/file/innodb/innodb_data_file | 24 | 1.88 ms | 293.34 us |
| background | wait/io/file/innodb/innodb_data_file | 2201 | 1.79 s | 106.12 ms |
| background | wait/io/file/innodb/innodb_log_file | 61 | 62.38 ms | 18.18 ms |
+------------+--------------------------------------+-------+----------+-------------+
ファイルI / Oをユーザーとイベントのタイプ別にまとめたものです。
デフォルトで、行はユーザーと合計レイテンシの降順でソートされます。
どれだけI/O処理を発生させているのか?
またどのようなI/O処理イベントでレイテンシが発生していのか?

user_summary_by_stagesと x$user_summary_by_stages
root@localhost [sys]> SELECT * FROM sys.user_summary_by_stages limit 2¥G
*************************** 1. row ***************************
user: admin
event_name: stage/sql/updating
total: 4
total_latency: 13.13 w
avg_latency: 18.53 w
*************************** 2. row ***************************
user: admin
event_name: stage/sql/Sending data
total: 3898
avg_latency: 1.42 ms
ユーザー別にグループ化されたステージを要約します。
デフォルトで、行はユーザーごとに並べ替えられ、ステージの合計レイテンシが降順で並べ替えられます。
ユーザー毎のイベント処理をレイテンシ順に確認する事が可能です。
どんなイベントで特定のユーザーにレイテンシが発生しているのか?、
確認する事が可能です。

user_summary_by_statement_latencyと
x$user_summary_by_statement_latency
root@localhost [sys]> SELECT * FROM sys.user_summary_by_statement_latency limit 3;
+----------+-------+---------------+-------------+--------------+-----------+---------------+---------------+------------+
| user | total | total_latency | max_latency | lock_latency | rows_sent | rows_examined | rows_affected | full_scans |
+----------+-------+---------------+-------------+--------------+-----------+---------------+---------------+------------+
| root | 21865 | 1.72 s | 469.07 ms | 1.61 s | 428 | 350230 | 0 | 80 |
| admin | 113 | 436.98 ms | 241.30 ms | 353.66 ms | 995 | 16467 | 0 | 26 |
| app_user | 55 | 9.77 ms | 2.98 ms | 87.00 us | 32 | 32 | 0 | 0 |
+----------+-------+---------------+-------------+--------------+-----------+---------------+---------------+------------+
ユーザーごとにグループ化された、全体的なステートメント統計を要約します。
ユーザー毎にステートメント全体のレイテンシ状況を確認する事が可能
です。細かく調べる前に、ある程度目星を付けるのに利用すると良さそう。

user_summary_by_statement_typeおよび
x$user_summary_by_statement_type
root@localhost [sys]> SELECT * FROM sys.user_summary_by_statement_type limit 1G
*************************** 1. row ***************************
user: admin
statement: show_keys
total: 4
lock_latency: 198.28 ms
rows_sent: 4
rows_examined: 66
rows_affected: 0
full_scans: 0
実行されたステートメントに関する情報を、ユーザーおよびステートメントタイプごとにまとめたものです。
デフォルトで、行はユーザーと合計レイテンシの降順でソートされます。
ユーザー毎のステートメントタイプ毎に、レイテンシ状況を確認する事が
可能です。細かく調べる前に、どんな処理で遅延が発生しているのかを、
深堀していくのに使えそうです。

version
root@localhost [sys]> SELECT * FROM sys.version limit 1;
+-------------+---------------+
| sys_version | mysql_version |
+-------------+---------------+
| 2.0.0 | 8.0.11 |
+-------------+---------------+
現在のsysスキーマとMySQLサーバのバージョンが表示されます。
あまり使いどころは無いかもしれませんが、バージョンを確認する事が
可能なので、運用・管理ツールから、バージョンを確認するような場面で
使えるかもしれません。

wait_classes_global_by_avg_latencyおよび
x$wait_classes_global_by_avg_latency
root@localhost [sys]> SELECT * FROM sys.wait_classes_global_by_avg_latency limit 3;
+-----------------+-------+---------------+-------------+-------------+-------------+
| event_class | total | total_latency | min_latency | avg_latency | max_latency |
+-----------------+-------+---------------+-------------+-------------+-------------+
| wait/io/table | 51 | 111.56 ms | 48.67 us | 2.19 ms | 107.93 ms |
| wait/io/file | 3029 | 2.40 s | 0 ps | 790.90 us | 327.28 ms |
| wait/lock/table | 20 | 427.28 us | 71.17 ns | 21.36 us | 302.72 us |
+-----------------+-------+---------------+-------------+-------------+-------------+
平均クラス待機時間を、イベントクラス毎にまとめたものです。
デフォルトで、行は平均待ち時間の降順でソートされます。 idleイベントは無視されます。
各イベントクラス毎の合計、最小、平均、最大レイテンシを確認する事が
可能です。インスタンス全体でどんなイベントでレイテンシが発生してい
るか確認して、対応策を検討するのに使う事が出来るかな。

wait_classes_global_by_latencyおよび
x$wait_classes_global_by_latency
root@localhost [sys]> SELECT * FROM sys.wait_classes_global_by_latency limit 2;
+---------------+-------+---------------+-------------+-------------+-------------+
| event_class | total | total_latency | min_latency | avg_latency | max_latency |
+---------------+-------+---------------+-------------+-------------+-------------+
| wait/io/file | 3036 | 2.40 s | 0 ps | 789.22 us | 327.28 ms |
| wait/io/table | 51 | 111.56 ms | 48.67 us | 2.19 ms | 107.93 ms |
+---------------+-------+---------------+-------------+-------------+-------------+
待機クラスの合計待ち時間をイベントクラス別にまとめたものです。
デフォルトで、行は合計レイテンシを降順にソートされます。idleイベントは無視されます。
基本的には、wait_classes_global_by_avg_latencyと同じように、
イベントクラス毎の待機イベントを確認する事が可能です。

waits_by_host_by_latencyと x$waits_by_host_by_latency
root@localhost [sys]> SELECT * FROM sys.waits_by_host_by_latency limit 10;
+--------------+--------------------------------------+-------+---------------+-------------+-------------+
| host | event | total | total_latency | avg_latency | max_latency |
+--------------+--------------------------------------+-------+---------------+-------------+-------------+
| 192.168.56.1 | wait/io/table/sql/handler | 13 | 107.99 ms | 8.31 ms | 107.93 ms |
| 192.168.56.1 | wait/io/file/innodb/innodb_data_file | 6 | 107.65 ms | 17.94 ms | 103.46 ms |
| 192.168.56.1 | wait/io/file/csv/data | 31 | 636.74 us | 20.54 us | 299.98 us |
| 192.168.56.1 | wait/io/file/sql/slow_log | 9 | 199.41 us | 22.16 us | 59.83 us |
| 192.168.56.1 | wait/lock/table/sql/handler | 2 | 2.81 us | 1.40 us | 1.70 us |
| background | wait/io/file/innodb/innodb_data_file | 2243 | 1.80 s | 803.06 us | 106.12 ms |
| background | wait/io/file/innodb/innodb_log_file | 70 | 77.49 ms | 1.11 ms | 18.18 ms |
| background | wait/io/file/sql/binlog | 28 | 18.17 ms | 648.85 us | 15.91 ms |
| background | wait/io/file/sql/binlog_index | 25 | 2.44 ms | 97.73 us | 1.28 ms |
| background | wait/io/file/sql/casetest | 15 | 858.12 us | 57.21 us | 690.04 us |
+--------------+--------------------------------------+-------+---------------+-------------+-------------+
ホストおよびイベントによってグループ化された待機イベントを要約します。
デフォルトで、行はホストごとにソートされ、合計レイテンシは降順にソートされidleイベントは無視されます。
各ホスト、各イベント毎にレイテンシを確認する事が可能です。
サービス遅延が発生したときに、ホスト毎に深堀する必要がある場合に
イベント詳細を調べていくのに使えそうです。

waits_by_user_by_latencyと x$waits_by_user_by_latency
root@localhost [sys]> SELECT * FROM sys.waits_by_user_by_latency limit 10;
+----------+--------------------------------------+-------+---------------+-------------+-------------+
| user | event | total | total_latency | avg_latency | max_latency |
+----------+--------------------------------------+-------+---------------+-------------+-------------+
| admin | wait/io/table/sql/handler | 13 | 107.99 ms | 8.31 ms | 107.93 ms |
| admin | wait/io/file/innodb/innodb_data_file | 6 | 107.65 ms | 17.94 ms | 103.46 ms |
| admin | wait/io/file/csv/data | 31 | 636.74 us | 20.54 us | 299.98 us |
| admin | wait/io/file/sql/slow_log | 9 | 199.41 us | 22.16 us | 59.83 us |
| admin | wait/lock/table/sql/handler | 2 | 2.81 us | 1.40 us | 1.70 us |
| app_user | wait/io/table/sql/handler | 75 | 2.43 ms | 32.44 us | 582.35 us |
| app_user | wait/io/file/innodb/innodb_data_file | 24 | 1.88 ms | 78.38 us | 293.34 us |
| app_user | wait/lock/table/sql/handler | 11 | 14.22 us | 1.29 us | 2.77 us |
| root | wait/io/file/innodb/innodb_data_file | 60 | 368.29 ms | 6.14 ms | 327.28 ms |
| root | wait/io/file/csv/metadata | 62 | 10.57 ms | 170.41 us | 1.06 ms |
+----------+--------------------------------------+-------+---------------+-------------+-------------+
ユーザーおよびイベントごとにグループ化された待機イベントを要約します。
デフォルトで、行はユーザーと合計レイテンシの降順でソートされます。idleイベントは無視されます。
各ユーザー、各イベント毎にレイテンシを確認する事が可能です。
サービス遅延が発生したときに、ユーザー毎に深堀する必要がある場合
にイベント詳細を調べていくのに使えそうです。

waits_global_by_latencyと x$waits_global_by_latency
root@localhost [sys]> SELECT * FROM sys.waits_global_by_latency limit 5;
+--------------------------------------+-------+---------------+-------------+-------------+
| events | total | total_latency | avg_latency | max_latency |
+--------------------------------------+-------+---------------+-------------+-------------+
| wait/io/file/innodb/innodb_data_file | 2333 | 2.28 s | 976.89 us | 327.28 ms |
| wait/io/table/sql/handler | 94 | 111.86 ms | 1.19 ms | 107.93 ms |
| wait/io/file/innodb/innodb_log_file | 70 | 77.49 ms | 1.11 ms | 18.18 ms |
| wait/io/file/sql/binlog | 28 | 18.17 ms | 648.85 us | 15.91 ms |
| wait/io/file/csv/metadata | 62 | 10.57 ms | 170.41 us | 1.06 ms |
+--------------------------------------+-------+---------------+-------------+-------------+
イベントごとにグループ化された待機イベントを要約します。
デフォルトで、行は合計レイテンシを降順にソートされます。idleイベントは無視されます。
各イベント毎にレイテンシを確認する事が可能です。
サービス遅延が発生したときに、イベント毎に深堀する必要がある場合
にイベント詳細を調べていくのに使えそうです。

create_synonym_db（）
root@localhost [sys]> SHOW DATABASES like 'info%';
+--------------------+
| Database (info%) |
+--------------------+
| information_schema |
+--------------------+
root@localhost [sys]> CALL create_synonym_db('INFORMATION_SCHEMA', 'info');
+-----------------------------------------+
| summary |
+-----------------------------------------+
| Created 62 views in the `info` database |
+-----------------------------------------+
root@localhost [sys]> SHOW DATABASES like 'info%';
+--------------------+
| Database (info%) |
+--------------------+
| info |
| information_schema |
+--------------------+
スキーマ名を指定すると、元のスキーマ内のすべての表およびビューを参照するビューを含む同義語スキー
マが作成されます。これは、たとえば、長い名前のスキーマ（INFORMATION_SCHEMAではなくinfoなど）を参
照する短い名前を作成できます。
スキーマを別名で呼び出す場合に使えます。
①　短い名前や分かりやすい名前でスキーマのシノニムを作成
②　特定スキーマを参照するVIEWをまとめて作りたい場合
※　DROP DATABASE, DROP SCHEMAで削除

diagnostics（）
[admin@GA01 ~]$ mysql -u root -ppassword -e "CALL sys.diagnostics(10,5,'current')“
<SNIP>
Delta host_summary_by_stages
host event_name total total_latency avg_latency
192.168.56.1 stage/sql/Sending data 4 5.85 ms 1.46 ms
192.168.56.1 stage/sql/freeing items 2 1.96 ms 981.06 us
192.168.56.1 stage/sql/starting 4 745.09 us 186.27 us
192.168.56.1 stage/sql/init 2 261.54 us 130.77 us
192.168.56.1 stage/sql/Opening tables 2 58.09 us 29.04 us
192.168.56.1 stage/sql/query end 2 53.44 us 26.72 us
<SNIP>
診断の目的で、現在のサーバー状態のレポートを作成します。
call sys.diagnostics(最大実行時間,間隔秒 ,'current')
デフォルトはそれぞれ60, 30, currentとなっており,30秒ごとに最大で60秒,つまり2回の出力を行う。
#current: 現在有効な計器とコンシューマーからのみデータの採取を行う
#medium: いくつかの計器とコンシューマーを有効にして、データの採取を行う
#full: すべての計器とコンシューマーを有効にして、データの採取を行う
OracleのSTATS PACKのように定期的に診断して、
パフォーマンスデータを残しておきたい場合に利用可能です。
使いどころは様々なので、状況に応じて定期的にパフォーマンス
診断しておきたい場合は利用すると良いかもしれません。

ps_trace_statement_digest()
root@localhost [sys]> CALL ps_trace_statement_digest('41d00de8eda848e48552d7282da0e4b6', 10, 0.1, TRUE, TRUE);
+-------------------+
| summary |
+-------------------+
| Disabled 1 thread |
+-------------------+
<SNIP>
+------------+-----------+-----------+-----------+---------------+---------------+------------+------------+
| executions | exec_time | lock_time | rows_sent | rows_affected | rows_examined | tmp_tables | full_scans |
+------------+-----------+-----------+-----------+---------------+---------------+------------+------------+
| 294 | 44.41 s | 44.37 s | 2940 | 0 | 2204118 | 588 | 294 |
+------------+-----------+-----------+-----------+---------------+---------------+------------+------------+
特定ステートメントダイジェストの全てのパフォーマンススキーマインストゥルメンテーションをトレースします。
パフォーマンス・スキーマのevents_statements_summary_by_digest表内で関心のある文を見つけた場合は、
このプロシージャーのDIGEST列MD5値を指定し、ポーリングの期間と間隔を指定します。結果は、その期間
のダイジェストのパフォーマンススキーマ内で追跡されたすべての統計情報のレポートです。
特定のステートメントに関しての、パフォーマンスを全体的に調べたい時に
使えそうです。ダイジェストの値は、他のVIEWやevents_statements_current
等から確認する事も可能です。SELECT MD5('xxx')も使えるかと。

ps_trace_thread（）
[sys]> CALL ps_trace_thread(28, CONCAT('/usr/local/mysql/mysql-files/stack-', REPLACE(NOW(), ' ', '-'), '.dot'), NULL, NULL, TRUE, TRUE, TRUE);
+-------------------+
| summary |
+-------------------+
| Disabled 1 thread |
+-------------------+
<SNIP>
+-----------------------------------------------------------------------------------+
| Info |
+-----------------------------------------------------------------------------------+
| Stack trace written to /usr/local/mysql/mysql-files/stack-2018-05-10-05:03:16.dot |
+-----------------------------------------------------------------------------------+
<SNIP>
+-------------------------------------------------------------------------------------------+
| Convert to PNG |
+-------------------------------------------------------------------------------------------+
| dot -Tpng -o /tmp/stack_28.png /usr/local/mysql/mysql-files/stack-2018-05-10-05:03:16.dot |
+-------------------------------------------------------------------------------------------+
<SNIP>
+------------------+
| summary |
+------------------+
| Enabled 1 thread |
+------------------+
計測されたスレッドのすべてのパフォーマンススキーマデータをDOT形式のグラフファイル（DOTグラフ記述言
語用）にダンプします。プロシージャから返される各結果セットは、完全なグラフに使用する必要があります。
計測されたパフォーマンスデータをグラフィカルに表現する為に使えます。
但し、データが多いので確認するには使いずらいかもしれません。
資料を作成する場合などには、便利な機能かと思います。

ps_truncate_all_tables()
root@localhost [sys]> CALL sys.ps_truncate_all_tables(FALSE);
+---------------------+
| summary |
+---------------------+
| Truncated 49 tables |
+---------------------+
Query OK, 0 rows affected (0.10 sec)
すべてのパフォーマンス・スキーマのサマリー表をTruncateして、集計されたすべての計測をスナップショット
としてリセットします。いくつのテーブルが切り捨てられたかを示す結果セットを生成します。
任意のクエリーのパフォーマンスを確認する直前に実行すると、容易にパフォーマンスを確認する事が可能。
※　FALSEの代わりに、TRUEにすると結果セットのみで無く各TRUNCATE実行コマンドが表示される。
※　MySQL5.7までは、”Truncated 44 tables”でしたが、MySQL8.0からは5つ対象テーブルが増えています。
特定のステートメントのパフォーマンスを調べたい時に、
予めこのコマンドでデータをTruncateしておくと分かりやすいので、
開発環境で調査するには便利です。

ファンクション例:
root@localhost [sys]> SELECT VERSION(), version_major();
+-----------+-----------------+
| VERSION() | version_major() |
+-----------+-----------------+
| 8.0.11 | 8 |
+-----------+-----------------+
root@localhost [sys]> SELECT format_bytes(512), format_bytes(18446644073709551615);
+-------------------+------------------------------------+
| format_bytes(512) | format_bytes(18446644073709551615) |
+-------------------+------------------------------------+
| 512 bytes | 16383.91 PiB |
+-------------------+------------------------------------+
以下のように、メジャーバージョンを表示したり、バイトを KiB (kibibytes), MiB (mebibytes), GiB (gibibytes), TiB
(tebibytes), or PiB (pebibytes)等に変換したりするヘルパー的なファンクションが多い。
ファンクションはヘルパー的なものが多いので、
各利用者の環境に応じて、必要に応じて使うのがよさそうです。

MySQL8.0 SYS スキーマ概要

More Related Content

What's hot

Similar to MySQL8.0 SYS スキーマ概要

More from Shinya Sugiyama

MySQL8.0 SYS スキーマ概要