SlideShare una empresa de Scribd logo
1 de 65
Descargar para leer sin conexión
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
((((`information_schema`.`innodb_lock_waits` `w`
JOIN `information_schema`.`innodb_trx` `b` ON ((`b`.`trx_id` = `w`.`blocking_trx_id`)))
JOIN `information_schema`.`innodb_trx` `r` ON ((`r`.`trx_id` = `w`.`requesting_trx_id`)))
JOIN `information_schema`.`innodb_locks` `bl` ON ((`bl`.`lock_id` = `w`.`blocking_lock_id`)))
JOIN `information_schema`.`innodb_locks` `rl` ON ((`rl`.`lock_id` = `w`.`requested_lock_id`)))
ORDER BY `r`.`trx_wait_started`
FROM
((((`performance_schema`.`data_lock_waits` `w`
JOIN `information_schema`.`INNODB_TRX` `b` ON ((CONVERT( `b`.`trx_id` USING UTF8MB4) = CAST(`w`.`BLOCKING_ENGINE_TRANSACTION_ID` AS CHAR CHARSET UTF8MB4))))
JOIN `information_schema`.`INNODB_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`.`ENGINE_LOCK_ID` = `w`.`BLOCKING_ENGINE_LOCK_ID`)))
JOIN `performance_schema`.`data_locks` `rl` ON ((`rl`.`ENGINE_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
1 row in set (0.02 sec)
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
3 rows in set (0.00 sec)
root@localhost [sys]>
ファイル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
max_latency: 18.18 ms
2 rows in set (0.00 sec)
root@localhost [sys]>
ファイル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
total_latency: 21.87 ms
avg_latency: 21.87 ms
1 row in set (0.00 sec)
root@localhost [sys]>
ステートメントのステージをホストごとにまとめたものです。
デフォルトで、行はホストごとにソートされ、合計レイテンシは降順にソートされます。
ステートメントがどのような状態にあるか、ホスト毎に確認可能です。
処理に時間がかかっている処理順にソートされているため、
ステージ毎に重い処理を特定することが可能です。
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
total_latency: 147.37 ms
max_latency: 22.52 ms
lock_latency: 101.21 ms
rows_sent: 118
rows_examined: 2758
rows_affected: 0
full_scans: 5
1 row in set (0.00 sec)
root@localhost [sys]>
ホストごとにサマライズされた、全体的なステートメント統計を要約します。
デフォルトで、行は合計レイテンシを降順にソートされます。
ホスト毎にステートメントの遅延状態を確認する事が可能です。
処理に時間がかかっているステートメント順にソートされているため、
時間のかかっているステートメントを容易に特定することが可能です。
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
1 row in set (0.00 sec)
root@localhost [sys]>
実行されたステートメントに関する情報を、ホストおよびステートメントタイプ別にグループ化して要約し
たものです。 デフォルトでは、行はホストごとにソートされ、合計レイテンシは降順にソートされます。
ホスト毎のステートメント種類毎にレイテンシを確認可能です。
参照処理が特に重い場合は、メモリー設定やインデックス等を見直して
みるのも良いかもしれません。
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
2 rows in set (0.03 sec)
スキーマごとにグループ化された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_schema: mysql
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_schema: mysql
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
total_latency: 120.04 ms
min_latency: 35.58 ns
avg_latency: 333.45 us
max_latency: 19.09 ms
thread_id: 1
processlist_id: NULL
1 row in set (0.01 sec)
root@localhost [sys]>
スレッドごとにグループ化された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 ***************************
file: @@basedir/data/undo_002
total: 390
total_latency: 598.68 ms
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 ***************************
file: @@basedir/data/undo_001
total: 397
total_latency: 526.48 ms
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
total_latency: 1.70 s
min_latency: 0 ps
avg_latency: 860.51 us
max_latency: 81.06 ms
count_read: 1251
total_read: 21.70 MiB
avg_read: 17.76 KiB
count_write: 536
total_written: 20.39 MiB
avg_written: 38.96 KiB
total_requested: 42.09 MiB
1 row in set (0.01 sec)
root@localhost [sys]>
グローバルI/Oコンシューマを要約し、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
total_latency: 1.70 s
avg_latency: 860.51 us
max_latency: 81.06 ms
read_latency: 1.67 s
write_latency: 26.17 ms
misc_latency: 2.42 ms
count_read: 1251
total_read: 21.70 MiB
avg_read: 17.76 KiB
count_write: 536
total_written: 20.39 MiB
avg_written: 38.96 KiB
1 row in set (0.00 sec)
グローバルI/Oコンシューマを要約し、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_count_used: 530
current_allocated: 1.92 MiB
current_avg_alloc: 3.70 KiB
current_max_alloc: 1012.80 KiB
total_allocated: 208.39 MiB
2 rows in set (0.00 sec)
root@localhost [sys]>
ホストごとにグループ化されたメモリー使用量を要約します。
デフォルトで、行は使用されたメモリ量の降順でソートされます。
現在、どのホストがメモリーを多く、使用しているか確認する事が可能。
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
current_count_used: 301
current_allocated: 1.33 MiB
current_avg_alloc: 4.53 KiB
current_max_alloc: 1012.80 KiB
total_allocated: 206.70 MiB
*************************** 2. row ***************************
thread_id: 42
user: sql/event_scheduler
current_count_used: 3
current_allocated: 16.18 KiB
current_avg_alloc: 5.39 KiB
current_max_alloc: 16.01 KiB
total_allocated: 16.18 KiB
2 rows in set (0.03 sec)
スレッドごとにグループ化されたメモリー使用量を要約します。
デフォルトで、行は使用されたメモリ量の降順でソートされます。
現在、どのスレッドがメモリーを多く、使用しているか確認する事が可能。
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_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 ***************************
user: root
current_count_used: 294
current_allocated: 1.33 MiB
current_avg_alloc: 4.62 KiB
current_max_alloc: 1012.80 KiB
total_allocated: 214.53 MiB
2 rows in set (0.01 sec)
root@localhost [sys]>
ユーザーごとにグループ化されたメモリー使用量を要約します。
デフォルトで、行は使用されたメモリ量の降順でソートされます。
現在、どのユーザーがメモリーを多く、使用しているか確認する事が可能。
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
current_avg_alloc: 136.26 KiB
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
2 rows in set (0.00 sec)
割り当てられたタイプ(イベント別)毎にグループ化されたメモリー使用量を要約します。  
デフォルトで、行は使用されたメモリ量の降順でソートされます。
現在、どのイベントがメモリーを多く、使用しているか確認する事が可能。
memory_global_totalおよびx$memory_global_total
root@localhost [sys]> SELECT * FROM sys.memory_global_total limit 2G
*************************** 1. row ***************************
total_allocated: 251.08 MiB
1 row in set (0.00 sec)
root@localhost [sys]>
サーバー内の合計メモリー使用量を要約します。
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 |
+----------------------------------+--------------------------------------------------+---------------+---------+
10 rows in set (0.01 sec)
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
1 row in set (0.00 sec)
パフォーマンススキーマがすべてのランタイムデータを監視できないかどうかを示すために、
失われたパフォーマンススキーマインストゥルメントに関する情報を返します。
パフォーマンススキーマがどのランタイムデータを監視出来ていないか、
不足しているインストゥルメントを確認可能です。
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
1 row in set (0.01 sec)
root@localhost [sys]>
インスタンスで利用している、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
1 row in set (0.00 sec)
root@localhost [sys]>
索引統計を一覧を確認する事が可能です。
デフォルトで、索引レイテンシの合計が降順にソートされます。
インデックスのレイテンシ事にソートされている為、
時間がかかっているインデックス等を容易に確認する事が可能です。
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 |
+--------------------+---------------+-------+
10 rows in set (0.02 sec)
各スキーマ内のオブジェクトのタイプをカウントしてまとめたものです。
デフォルトで、行はスキーマとオブジェクトタイプによってソートされます。
スキーマ毎のオブジェクト数などを容易に確認可能です。
データベース移行時などにも、オブジェクト漏れがないか確認可能。
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`
1 row in set (0.36 sec)
root@localhost [sys]>
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 ***************************
object_schema: AdventureWorks2012
object_name: Address
index_name: AK_Address_rowguid
*************************** 3. row ***************************
object_schema: AdventureWorks2012
object_name: Address
index_name: rowguid
3 rows in set (0.04 sec)
root@localhost [sys]>
使用されたイベントが、存在しないインデックス(使用されないインデックス)がリスト表示されます。
デフォルトでは、行はスキーマとテーブルによってソートされます。
起動してから、一度も利用されていないインデックスを確認する事が
可能です。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 |
+-----------+-------------+--------------------+---------------------+
3 rows in set (0.00 sec)
root@localhost [sys]>
各接続ごとに、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
total_latency: 13.91 m
max_latency: 723.74 ms
<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
1 row in set (0.01 sec)
root@localhost [sys]>
エラーまたは警告を生成したステートメントを正規化し表示します。
デフォルトで、行はエラーと警告数の降順によってソートされます。
エラー若しくは警告が発生したステートメントを確認可能です。
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
total_latency: 9.47 ms
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
total_latency: 1.43 m
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
total_latency: 13.91 m
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
1 row in set (0.01 sec)
ソートを実行したステートメントを正規化しリストします。
デフォルトで、行は合計レイテンシを降順にソートされます。
ソート処理を実行したクエリーを遅い順に確認出来る為、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
total_latency: 171.71 ms
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
1 row in set (0.00 sec)
root@localhost [sys]>
一時表を使用したステートメントが正規化されリストされます。 デフォルトで、使用されるディスク上の
一時テーブルの数、使用されるメモリ内の一時テーブルが降順で行がソートされます。
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
1 row in set (0.02 sec)
root@localhost [sys]>
ユーザー毎にステートメントのアクティビティ、ファイル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 |
+------------+------+------------+
4 rows in set (0.00 sec)
root@localhost [sys]>
ファイル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 |
+------------+--------------------------------------+-------+----------+-------------+
5 rows in set (0.00 sec)
root@localhost [sys]>
ファイル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
total_latency: 5.53 s
avg_latency: 1.42 ms
2 rows in set (0.01 sec)
ユーザー別にグループ化されたステージを要約します。
デフォルトで、行はユーザーごとに並べ替えられ、ステージの合計レイテンシが降順で並べ替えられます。
ユーザー毎のイベント処理をレイテンシ順に確認する事が可能です。
どんなイベントで特定のユーザーにレイテンシが発生しているのか?、
確認する事が可能です。
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 |
+----------+-------+---------------+-------------+--------------+-----------+---------------+---------------+------------+
3 rows in set (0.01 sec)
root@localhost [sys]>
ユーザーごとにグループ化された、全体的なステートメント統計を要約します。
デフォルトで、行は合計レイテンシを降順にソートされます。
ユーザー毎にステートメント全体のレイテンシ状況を確認する事が可能
です。細かく調べる前に、ある程度目星を付けるのに利用すると良さそう。
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
total_latency: 201.18 ms
max_latency: 100.26 ms
lock_latency: 198.28 ms
rows_sent: 4
rows_examined: 66
rows_affected: 0
full_scans: 0
1 row in set (0.01 sec)
root@localhost [sys]>
実行されたステートメントに関する情報を、ユーザーおよびステートメントタイプごとにまとめたものです。
デフォルトで、行はユーザーと合計レイテンシの降順でソートされます。
ユーザー毎のステートメントタイプ毎に、レイテンシ状況を確認する事が
可能です。細かく調べる前に、どんな処理で遅延が発生しているのかを、
深堀していくのに使えそうです。
version
root@localhost [sys]> SELECT * FROM sys.version limit 1;
+-------------+---------------+
| sys_version | mysql_version |
+-------------+---------------+
| 2.0.0 | 8.0.11 |
+-------------+---------------+
1 row in set (0.00 sec)
root@localhost [sys]>
現在の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 |
+-----------------+-------+---------------+-------------+-------------+-------------+
3 rows in set (0.01 sec)
平均クラス待機時間を、イベントクラス毎にまとめたものです。
デフォルトで、行は平均待ち時間の降順でソートされます。 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 |
+---------------+-------+---------------+-------------+-------------+-------------+
2 rows in set (0.01 sec)
待機クラスの合計待ち時間をイベントクラス別にまとめたものです。
デフォルトで、行は合計レイテンシを降順にソートされます。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 |
+--------------+--------------------------------------+-------+---------------+-------------+-------------+
10 rows in set (0.00 sec)
ホストおよびイベントによってグループ化された待機イベントを要約します。
デフォルトで、行はホストごとにソートされ、合計レイテンシは降順にソートされ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 |
+----------+--------------------------------------+-------+---------------+-------------+-------------+
10 rows in set (0.00 sec)
ユーザーおよびイベントごとにグループ化された待機イベントを要約します。
デフォルトで、行はユーザーと合計レイテンシの降順でソートされます。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 |
+--------------------------------------+-------+---------------+-------------+-------------+
5 rows in set (0.00 sec)
root@localhost [sys]>
イベントごとにグループ化された待機イベントを要約します。
デフォルトで、行は合計レイテンシを降順にソートされます。idleイベントは無視されます。
各イベント毎にレイテンシを確認する事が可能です。
サービス遅延が発生したときに、イベント毎に深堀する必要がある場合
にイベント詳細を調べていくのに使えそうです。
プロシジャー
プロシジャーの種類 root@localhost [sys]> SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
-> FROM information_schema.ROUTINES WHERE ROUTINE_TYPE = 'PROCEDURE';
+----------------+-------------------------------------+--------------+
| ROUTINE_SCHEMA | ROUTINE_NAME | ROUTINE_TYPE |
+----------------+-------------------------------------+--------------+
| sys | create_synonym_db | PROCEDURE |
| sys | execute_prepared_stmt | PROCEDURE |
| sys | diagnostics | PROCEDURE |
| sys | ps_statement_avg_latency_histogram | PROCEDURE |
| sys | ps_trace_statement_digest | PROCEDURE |
| sys | ps_trace_thread | PROCEDURE |
| sys | ps_setup_disable_background_threads | PROCEDURE |
| sys | ps_setup_disable_consumer | PROCEDURE |
| sys | ps_setup_disable_instrument | PROCEDURE |
| sys | ps_setup_disable_thread | PROCEDURE |
| sys | ps_setup_enable_background_threads | PROCEDURE |
| sys | ps_setup_enable_consumer | PROCEDURE |
| sys | ps_setup_enable_instrument | PROCEDURE |
| sys | ps_setup_enable_thread | PROCEDURE |
| sys | ps_setup_reload_saved | PROCEDURE |
| sys | ps_setup_reset_to_default | PROCEDURE |
| sys | ps_setup_save | PROCEDURE |
| sys | ps_setup_show_disabled | PROCEDURE |
| sys | ps_setup_show_disabled_consumers | PROCEDURE |
| sys | ps_setup_show_disabled_instruments | PROCEDURE |
| sys | ps_setup_show_enabled | PROCEDURE |
| sys | ps_setup_show_enabled_consumers | PROCEDURE |
| sys | ps_setup_show_enabled_instruments | PROCEDURE |
| sys | ps_truncate_all_tables | PROCEDURE |
| sys | statement_performance_analyzer | PROCEDURE |
| sys | table_exists | PROCEDURE |
+----------------+-------------------------------------+--------------+
https://dev.mysql.com/doc/refman/5.7/en/sys-
schema-procedures.html
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 |
+-------------------+
1 row in set (0.01 sec)
<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 |
+------------+-----------+-----------+-----------+---------------+---------------+------------+------------+
1 row in set (9.67 sec)
特定ステートメントダイジェストの全てのパフォーマンススキーマインストゥルメンテーションをトレースします。
パフォーマンス・スキーマの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 |
+---------------------+
1 row in set (0.10 sec)
Query OK, 0 rows affected (0.10 sec)
root@localhost [sys]>
すべてのパフォーマンス・スキーマのサマリー表をTruncateして、集計されたすべての計測をスナップショット
としてリセットします。いくつのテーブルが切り捨てられたかを示す結果セットを生成します。
任意のクエリーのパフォーマンスを確認する直前に実行すると、容易にパフォーマンスを確認する事が可能。
※ FALSEの代わりに、TRUEにすると結果セットのみで無く各TRUNCATE実行コマンドが表示される。
※ MySQL5.7までは、”Truncated 44 tables”でしたが、MySQL8.0からは5つ対象テーブルが増えています。
特定のステートメントのパフォーマンスを調べたい時に、
予めこのコマンドでデータをTruncateしておくと分かりやすいので、
開発環境で調査するには便利です。
ファンクション
ファンクションの種類
root@localhost [sys]> SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
-> FROM information_schema.ROUTINES WHERE ROUTINE_TYPE = 'FUNCTION';
+----------------+----------------------------------+--------------+
| ROUTINE_SCHEMA | ROUTINE_NAME | ROUTINE_TYPE |
+----------------+----------------------------------+--------------+
| sys | extract_schema_from_file_name | FUNCTION |
| sys | extract_table_from_file_name | FUNCTION |
| sys | format_bytes | FUNCTION |
| sys | format_path | FUNCTION |
| sys | format_statement | FUNCTION |
| sys | format_time | FUNCTION |
| sys | list_add | FUNCTION |
| sys | list_drop | FUNCTION |
| sys | ps_is_account_enabled | FUNCTION |
| sys | ps_is_consumer_enabled | FUNCTION |
| sys | ps_is_instrument_default_enabled | FUNCTION |
| sys | ps_is_instrument_default_timed | FUNCTION |
| sys | ps_is_thread_instrumented | FUNCTION |
| sys | ps_thread_id | FUNCTION |
| sys | ps_thread_account | FUNCTION |
| sys | ps_thread_stack | FUNCTION |
| sys | ps_thread_trx_info | FUNCTION |
| sys | quote_identifier | FUNCTION |
| sys | sys_get_config | FUNCTION |
| sys | version_major | FUNCTION |
| sys | version_minor | FUNCTION |
| sys | version_patch | FUNCTION |
+----------------+----------------------------------+--------------+
https://dev.mysql.com/doc/refman/5.7/en/sys-schema-
functions.html
ファンクション例:
root@localhost [sys]> SELECT VERSION(), version_major();
+-----------+-----------------+
| VERSION() | version_major() |
+-----------+-----------------+
| 8.0.11 | 8 |
+-----------+-----------------+
1 row in set (0.00 sec)
root@localhost [sys]> SELECT format_bytes(512), format_bytes(18446644073709551615);
+-------------------+------------------------------------+
| format_bytes(512) | format_bytes(18446644073709551615) |
+-------------------+------------------------------------+
| 512 bytes | 16383.91 PiB |
+-------------------+------------------------------------+
1 row in set (0.00 sec)
root@localhost [sys]>
以下のように、メジャーバージョンを表示したり、バイトを KiB (kibibytes), MiB (mebibytes), GiB (gibibytes), TiB
(tebibytes), or PiB (pebibytes)等に変換したりするヘルパー的なファンクションが多い。
ファンクションはヘルパー的なものが多いので、
各利用者の環境に応じて、必要に応じて使うのがよさそうです。

Más contenido relacionado

La actualidad más candente

PostgreSQL 15の新機能を徹底解説
PostgreSQL 15の新機能を徹底解説PostgreSQL 15の新機能を徹底解説
PostgreSQL 15の新機能を徹底解説Masahiko Sawada
 
Let's scale-out PostgreSQL using Citus (Japanese)
Let's scale-out PostgreSQL using Citus (Japanese)Let's scale-out PostgreSQL using Citus (Japanese)
Let's scale-out PostgreSQL using Citus (Japanese)Noriyoshi Shinoda
 
Oracle Database / Exadata Cloud 技術情報(Oracle Cloudウェビナーシリーズ: 2020年7月9日)
Oracle Database / Exadata Cloud 技術情報(Oracle Cloudウェビナーシリーズ: 2020年7月9日)Oracle Database / Exadata Cloud 技術情報(Oracle Cloudウェビナーシリーズ: 2020年7月9日)
Oracle Database / Exadata Cloud 技術情報(Oracle Cloudウェビナーシリーズ: 2020年7月9日)オラクルエンジニア通信
 
バッチ処理にバインド変数はもうやめません? ~|バッチ処理の突発遅延を題材にして考えてみる~
バッチ処理にバインド変数はもうやめません? ~|バッチ処理の突発遅延を題材にして考えてみる~バッチ処理にバインド変数はもうやめません? ~|バッチ処理の突発遅延を題材にして考えてみる~
バッチ処理にバインド変数はもうやめません? ~|バッチ処理の突発遅延を題材にして考えてみる~Ryota Watabe
 
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...NTT DATA Technology & Innovation
 
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...NTT DATA Technology & Innovation
 
まずやっとくPostgreSQLチューニング
まずやっとくPostgreSQLチューニングまずやっとくPostgreSQLチューニング
まずやっとくPostgreSQLチューニングKosuke Kida
 
行ロックと「LOG: process 12345 still waiting for ShareLock on transaction 710 afte...
行ロックと「LOG:  process 12345 still waiting for ShareLock on transaction 710 afte...行ロックと「LOG:  process 12345 still waiting for ShareLock on transaction 710 afte...
行ロックと「LOG: process 12345 still waiting for ShareLock on transaction 710 afte...Masahiko Sawada
 
もしOracleDBAがMySQLを管理することになったときの注意点など
もしOracleDBAがMySQLを管理することになったときの注意点などもしOracleDBAがMySQLを管理することになったときの注意点など
もしOracleDBAがMySQLを管理することになったときの注意点などKentaro Kitagawa
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションMasahiko Sawada
 
大規模CSVをMySQLに入れる
大規模CSVをMySQLに入れる大規模CSVをMySQLに入れる
大規模CSVをMySQLに入れるShuhei Iitsuka
 
OpenLineage による Airflow のデータ来歴の収集と可視化(Airflow Meetup Tokyo #3 発表資料)
OpenLineage による Airflow のデータ来歴の収集と可視化(Airflow Meetup Tokyo #3 発表資料)OpenLineage による Airflow のデータ来歴の収集と可視化(Airflow Meetup Tokyo #3 発表資料)
OpenLineage による Airflow のデータ来歴の収集と可視化(Airflow Meetup Tokyo #3 発表資料)NTT DATA Technology & Innovation
 
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...NTT DATA Technology & Innovation
 
[Postgre sql9.4新機能]レプリケーション・スロットの活用
[Postgre sql9.4新機能]レプリケーション・スロットの活用[Postgre sql9.4新機能]レプリケーション・スロットの活用
[Postgre sql9.4新機能]レプリケーション・スロットの活用Kosuke Kida
 
Oracle Database performance tuning using oratop
Oracle Database performance tuning using oratopOracle Database performance tuning using oratop
Oracle Database performance tuning using oratopSandesh Rao
 
Oracleのソース・ターゲットエンドポイントとしての利用
Oracleのソース・ターゲットエンドポイントとしての利用Oracleのソース・ターゲットエンドポイントとしての利用
Oracleのソース・ターゲットエンドポイントとしての利用QlikPresalesJapan
 
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~Miki Shimogai
 

La actualidad más candente (20)

Vacuum徹底解説
Vacuum徹底解説Vacuum徹底解説
Vacuum徹底解説
 
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
 
PostgreSQL 15の新機能を徹底解説
PostgreSQL 15の新機能を徹底解説PostgreSQL 15の新機能を徹底解説
PostgreSQL 15の新機能を徹底解説
 
Let's scale-out PostgreSQL using Citus (Japanese)
Let's scale-out PostgreSQL using Citus (Japanese)Let's scale-out PostgreSQL using Citus (Japanese)
Let's scale-out PostgreSQL using Citus (Japanese)
 
Oracle Database / Exadata Cloud 技術情報(Oracle Cloudウェビナーシリーズ: 2020年7月9日)
Oracle Database / Exadata Cloud 技術情報(Oracle Cloudウェビナーシリーズ: 2020年7月9日)Oracle Database / Exadata Cloud 技術情報(Oracle Cloudウェビナーシリーズ: 2020年7月9日)
Oracle Database / Exadata Cloud 技術情報(Oracle Cloudウェビナーシリーズ: 2020年7月9日)
 
バッチ処理にバインド変数はもうやめません? ~|バッチ処理の突発遅延を題材にして考えてみる~
バッチ処理にバインド変数はもうやめません? ~|バッチ処理の突発遅延を題材にして考えてみる~バッチ処理にバインド変数はもうやめません? ~|バッチ処理の突発遅延を題材にして考えてみる~
バッチ処理にバインド変数はもうやめません? ~|バッチ処理の突発遅延を題材にして考えてみる~
 
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
オンライン物理バックアップの排他モードと非排他モードについて ~PostgreSQLバージョン15対応版~(第34回PostgreSQLアンカンファレンス...
 
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
 
使ってみませんか?pg_hint_plan
使ってみませんか?pg_hint_plan使ってみませんか?pg_hint_plan
使ってみませんか?pg_hint_plan
 
まずやっとくPostgreSQLチューニング
まずやっとくPostgreSQLチューニングまずやっとくPostgreSQLチューニング
まずやっとくPostgreSQLチューニング
 
行ロックと「LOG: process 12345 still waiting for ShareLock on transaction 710 afte...
行ロックと「LOG:  process 12345 still waiting for ShareLock on transaction 710 afte...行ロックと「LOG:  process 12345 still waiting for ShareLock on transaction 710 afte...
行ロックと「LOG: process 12345 still waiting for ShareLock on transaction 710 afte...
 
もしOracleDBAがMySQLを管理することになったときの注意点など
もしOracleDBAがMySQLを管理することになったときの注意点などもしOracleDBAがMySQLを管理することになったときの注意点など
もしOracleDBAがMySQLを管理することになったときの注意点など
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
 
大規模CSVをMySQLに入れる
大規模CSVをMySQLに入れる大規模CSVをMySQLに入れる
大規模CSVをMySQLに入れる
 
OpenLineage による Airflow のデータ来歴の収集と可視化(Airflow Meetup Tokyo #3 発表資料)
OpenLineage による Airflow のデータ来歴の収集と可視化(Airflow Meetup Tokyo #3 発表資料)OpenLineage による Airflow のデータ来歴の収集と可視化(Airflow Meetup Tokyo #3 発表資料)
OpenLineage による Airflow のデータ来歴の収集と可視化(Airflow Meetup Tokyo #3 発表資料)
 
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
PostgreSQLモニタリングの基本とNTTデータが追加したモニタリング新機能(Open Source Conference 2021 Online F...
 
[Postgre sql9.4新機能]レプリケーション・スロットの活用
[Postgre sql9.4新機能]レプリケーション・スロットの活用[Postgre sql9.4新機能]レプリケーション・スロットの活用
[Postgre sql9.4新機能]レプリケーション・スロットの活用
 
Oracle Database performance tuning using oratop
Oracle Database performance tuning using oratopOracle Database performance tuning using oratop
Oracle Database performance tuning using oratop
 
Oracleのソース・ターゲットエンドポイントとしての利用
Oracleのソース・ターゲットエンドポイントとしての利用Oracleのソース・ターゲットエンドポイントとしての利用
Oracleのソース・ターゲットエンドポイントとしての利用
 
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
 

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

5 古雷my sql源碼與資料庫規範
5 古雷my sql源碼與資料庫規範5 古雷my sql源碼與資料庫規範
5 古雷my sql源碼與資料庫規範Ivan Tu
 
MySQLとPostgreSQLの基本的な実行プラン比較
MySQLとPostgreSQLの基本的な実行プラン比較MySQLとPostgreSQLの基本的な実行プラン比較
MySQLとPostgreSQLの基本的な実行プラン比較Shinya Sugiyama
 
MySQLとPostgreSQLの基本的なレプリケーション設定比較
MySQLとPostgreSQLの基本的なレプリケーション設定比較MySQLとPostgreSQLの基本的なレプリケーション設定比較
MySQLとPostgreSQLの基本的なレプリケーション設定比較Shinya Sugiyama
 
HandlerSocket plugin for MySQL
HandlerSocket plugin for MySQLHandlerSocket plugin for MySQL
HandlerSocket plugin for MySQLakirahiguchi
 
MySQLとPostgreSQLにおける基本的なアカウント管理
MySQLとPostgreSQLにおける基本的なアカウント管理MySQLとPostgreSQLにおける基本的なアカウント管理
MySQLとPostgreSQLにおける基本的なアカウント管理Shinya Sugiyama
 
Introduction of Oracle Database Architecture
Introduction of Oracle Database ArchitectureIntroduction of Oracle Database Architecture
Introduction of Oracle Database ArchitectureRyota Watabe
 
Maatkit で MySQL チューニング
Maatkit で MySQL チューニングMaatkit で MySQL チューニング
Maatkit で MySQL チューニングKensuke Nagae
 
MySQLとPostgreSQLの基本的なパラメータ比較
MySQLとPostgreSQLの基本的なパラメータ比較MySQLとPostgreSQLの基本的なパラメータ比較
MySQLとPostgreSQLの基本的なパラメータ比較Shinya Sugiyama
 
Handlersocket 20110517
Handlersocket 20110517Handlersocket 20110517
Handlersocket 20110517akirahiguchi
 
PostgreSQL13 新機能紹介
PostgreSQL13 新機能紹介PostgreSQL13 新機能紹介
PostgreSQL13 新機能紹介Satoshi Hirata
 
db tech showcase 2019 D10 Oracle Database New Features
db tech showcase 2019 D10 Oracle Database New Featuresdb tech showcase 2019 D10 Oracle Database New Features
db tech showcase 2019 D10 Oracle Database New FeaturesNoriyoshi Shinoda
 
MySQL 5.7が魅せる新しい運用の形
MySQL 5.7が魅せる新しい運用の形MySQL 5.7が魅せる新しい運用の形
MySQL 5.7が魅せる新しい運用の形yoku0825
 
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -onozaty
 
KOF2015 PostgreSQL 9.5
KOF2015 PostgreSQL 9.5KOF2015 PostgreSQL 9.5
KOF2015 PostgreSQL 9.5Toshi Harada
 
Mobageの技術を体験(MyDNS編)
Mobageの技術を体験(MyDNS編)Mobageの技術を体験(MyDNS編)
Mobageの技術を体験(MyDNS編)Daisuke Ikeda
 
MariaDB Columnstore 使いこなそう
MariaDB Columnstore 使いこなそうMariaDB Columnstore 使いこなそう
MariaDB Columnstore 使いこなそうKAWANO KAZUYUKI
 
20090107 Postgre Sqlチューニング(Sql編)
20090107 Postgre Sqlチューニング(Sql編)20090107 Postgre Sqlチューニング(Sql編)
20090107 Postgre Sqlチューニング(Sql編)Hiromu Shioya
 
MariaDB migration from commercial database
MariaDB migration from commercial databaseMariaDB migration from commercial database
MariaDB migration from commercial databaseGOTO Satoru
 
MySQL clients
MySQL clientsMySQL clients
MySQL clientsyoku0825
 

Similar a MySQL8.0 SYS スキーマ概要 (20)

5 古雷my sql源碼與資料庫規範
5 古雷my sql源碼與資料庫規範5 古雷my sql源碼與資料庫規範
5 古雷my sql源碼與資料庫規範
 
MySQLとPostgreSQLの基本的な実行プラン比較
MySQLとPostgreSQLの基本的な実行プラン比較MySQLとPostgreSQLの基本的な実行プラン比較
MySQLとPostgreSQLの基本的な実行プラン比較
 
MySQLとPostgreSQLの基本的なレプリケーション設定比較
MySQLとPostgreSQLの基本的なレプリケーション設定比較MySQLとPostgreSQLの基本的なレプリケーション設定比較
MySQLとPostgreSQLの基本的なレプリケーション設定比較
 
HandlerSocket plugin for MySQL
HandlerSocket plugin for MySQLHandlerSocket plugin for MySQL
HandlerSocket plugin for MySQL
 
MySQLとPostgreSQLにおける基本的なアカウント管理
MySQLとPostgreSQLにおける基本的なアカウント管理MySQLとPostgreSQLにおける基本的なアカウント管理
MySQLとPostgreSQLにおける基本的なアカウント管理
 
Introduction of Oracle Database Architecture
Introduction of Oracle Database ArchitectureIntroduction of Oracle Database Architecture
Introduction of Oracle Database Architecture
 
Maatkit で MySQL チューニング
Maatkit で MySQL チューニングMaatkit で MySQL チューニング
Maatkit で MySQL チューニング
 
MySQLとPostgreSQLの基本的なパラメータ比較
MySQLとPostgreSQLの基本的なパラメータ比較MySQLとPostgreSQLの基本的なパラメータ比較
MySQLとPostgreSQLの基本的なパラメータ比較
 
Handlersocket 20110517
Handlersocket 20110517Handlersocket 20110517
Handlersocket 20110517
 
PostgreSQL13 新機能紹介
PostgreSQL13 新機能紹介PostgreSQL13 新機能紹介
PostgreSQL13 新機能紹介
 
db tech showcase 2019 D10 Oracle Database New Features
db tech showcase 2019 D10 Oracle Database New Featuresdb tech showcase 2019 D10 Oracle Database New Features
db tech showcase 2019 D10 Oracle Database New Features
 
MySQL 5.7が魅せる新しい運用の形
MySQL 5.7が魅せる新しい運用の形MySQL 5.7が魅せる新しい運用の形
MySQL 5.7が魅せる新しい運用の形
 
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
今からでも遅くないDBマイグレーション - Flyway と SchemaSpy の紹介 -
 
Mysql charset
Mysql charsetMysql charset
Mysql charset
 
KOF2015 PostgreSQL 9.5
KOF2015 PostgreSQL 9.5KOF2015 PostgreSQL 9.5
KOF2015 PostgreSQL 9.5
 
Mobageの技術を体験(MyDNS編)
Mobageの技術を体験(MyDNS編)Mobageの技術を体験(MyDNS編)
Mobageの技術を体験(MyDNS編)
 
MariaDB Columnstore 使いこなそう
MariaDB Columnstore 使いこなそうMariaDB Columnstore 使いこなそう
MariaDB Columnstore 使いこなそう
 
20090107 Postgre Sqlチューニング(Sql編)
20090107 Postgre Sqlチューニング(Sql編)20090107 Postgre Sqlチューニング(Sql編)
20090107 Postgre Sqlチューニング(Sql編)
 
MariaDB migration from commercial database
MariaDB migration from commercial databaseMariaDB migration from commercial database
MariaDB migration from commercial database
 
MySQL clients
MySQL clientsMySQL clients
MySQL clients
 

Más de Shinya Sugiyama

MySQLとPostgreSQLの基本的なバックアップ比較
MySQLとPostgreSQLの基本的なバックアップ比較MySQLとPostgreSQLの基本的なバックアップ比較
MySQLとPostgreSQLの基本的なバックアップ比較Shinya Sugiyama
 
Locondo 20190703@inno db_cluster
Locondo 20190703@inno db_clusterLocondo 20190703@inno db_cluster
Locondo 20190703@inno db_clusterShinya Sugiyama
 
Locondo 20190215@ec tech_group
Locondo 20190215@ec tech_groupLocondo 20190215@ec tech_group
Locondo 20190215@ec tech_groupShinya Sugiyama
 
DB tech showcase_tokyo2018_LOCONDO
DB tech showcase_tokyo2018_LOCONDODB tech showcase_tokyo2018_LOCONDO
DB tech showcase_tokyo2018_LOCONDOShinya Sugiyama
 
Oracle Cloud MySQL Service
Oracle Cloud MySQL ServiceOracle Cloud MySQL Service
Oracle Cloud MySQL ServiceShinya Sugiyama
 
MySQL InnoDB Clusterによる高可用性構成(DB Tech Showcase 2017)
MySQL InnoDB Clusterによる高可用性構成(DB Tech Showcase 2017)MySQL InnoDB Clusterによる高可用性構成(DB Tech Showcase 2017)
MySQL InnoDB Clusterによる高可用性構成(DB Tech Showcase 2017)Shinya Sugiyama
 
MySQLデータ暗号化と暗号鍵のローテーション
MySQLデータ暗号化と暗号鍵のローテーションMySQLデータ暗号化と暗号鍵のローテーション
MySQLデータ暗号化と暗号鍵のローテーションShinya Sugiyama
 
Power of SQL and NoSQL with MySQL5.7
Power of SQL and NoSQL with MySQL5.7Power of SQL and NoSQL with MySQL5.7
Power of SQL and NoSQL with MySQL5.7Shinya Sugiyama
 
Multi thread slave_performance_on_opc
Multi thread slave_performance_on_opcMulti thread slave_performance_on_opc
Multi thread slave_performance_on_opcShinya Sugiyama
 
db tech showcase2016 - MySQLドキュメントストア
db tech showcase2016 - MySQLドキュメントストアdb tech showcase2016 - MySQLドキュメントストア
db tech showcase2016 - MySQLドキュメントストアShinya Sugiyama
 
MySQL57 Update@OSC Fukuoka 20151003
MySQL57 Update@OSC Fukuoka 20151003MySQL57 Update@OSC Fukuoka 20151003
MySQL57 Update@OSC Fukuoka 20151003Shinya Sugiyama
 
No sql with mysql cluster (MyNA・JPUG合同DB勉強会)
No sql with mysql cluster (MyNA・JPUG合同DB勉強会)No sql with mysql cluster (MyNA・JPUG合同DB勉強会)
No sql with mysql cluster (MyNA・JPUG合同DB勉強会)Shinya Sugiyama
 
MySQL 5.7とレプリケーションにおける改良
MySQL 5.7とレプリケーションにおける改良MySQL 5.7とレプリケーションにおける改良
MySQL 5.7とレプリケーションにおける改良Shinya Sugiyama
 
MySQL 5.7 Technical Update (日本語)
MySQL 5.7 Technical Update (日本語)MySQL 5.7 Technical Update (日本語)
MySQL 5.7 Technical Update (日本語)Shinya Sugiyama
 
MySQL Fabric with OpenStack Nova
MySQL Fabric with OpenStack NovaMySQL Fabric with OpenStack Nova
MySQL Fabric with OpenStack NovaShinya Sugiyama
 
My sql security (暗号化)
My sql security (暗号化) My sql security (暗号化)
My sql security (暗号化) Shinya Sugiyama
 

Más de Shinya Sugiyama (18)

MySQLとPostgreSQLの基本的なバックアップ比較
MySQLとPostgreSQLの基本的なバックアップ比較MySQLとPostgreSQLの基本的なバックアップ比較
MySQLとPostgreSQLの基本的なバックアップ比較
 
Locondo 20190703@inno db_cluster
Locondo 20190703@inno db_clusterLocondo 20190703@inno db_cluster
Locondo 20190703@inno db_cluster
 
Locondo 20190215@ec tech_group
Locondo 20190215@ec tech_groupLocondo 20190215@ec tech_group
Locondo 20190215@ec tech_group
 
DB tech showcase_tokyo2018_LOCONDO
DB tech showcase_tokyo2018_LOCONDODB tech showcase_tokyo2018_LOCONDO
DB tech showcase_tokyo2018_LOCONDO
 
MySQL Partition Engine
MySQL Partition EngineMySQL Partition Engine
MySQL Partition Engine
 
Oracle Cloud MySQL Service
Oracle Cloud MySQL ServiceOracle Cloud MySQL Service
Oracle Cloud MySQL Service
 
MySQL InnoDB Clusterによる高可用性構成(DB Tech Showcase 2017)
MySQL InnoDB Clusterによる高可用性構成(DB Tech Showcase 2017)MySQL InnoDB Clusterによる高可用性構成(DB Tech Showcase 2017)
MySQL InnoDB Clusterによる高可用性構成(DB Tech Showcase 2017)
 
MySQL8.0 in COSCUP2017
MySQL8.0 in COSCUP2017MySQL8.0 in COSCUP2017
MySQL8.0 in COSCUP2017
 
MySQLデータ暗号化と暗号鍵のローテーション
MySQLデータ暗号化と暗号鍵のローテーションMySQLデータ暗号化と暗号鍵のローテーション
MySQLデータ暗号化と暗号鍵のローテーション
 
Power of SQL and NoSQL with MySQL5.7
Power of SQL and NoSQL with MySQL5.7Power of SQL and NoSQL with MySQL5.7
Power of SQL and NoSQL with MySQL5.7
 
Multi thread slave_performance_on_opc
Multi thread slave_performance_on_opcMulti thread slave_performance_on_opc
Multi thread slave_performance_on_opc
 
db tech showcase2016 - MySQLドキュメントストア
db tech showcase2016 - MySQLドキュメントストアdb tech showcase2016 - MySQLドキュメントストア
db tech showcase2016 - MySQLドキュメントストア
 
MySQL57 Update@OSC Fukuoka 20151003
MySQL57 Update@OSC Fukuoka 20151003MySQL57 Update@OSC Fukuoka 20151003
MySQL57 Update@OSC Fukuoka 20151003
 
No sql with mysql cluster (MyNA・JPUG合同DB勉強会)
No sql with mysql cluster (MyNA・JPUG合同DB勉強会)No sql with mysql cluster (MyNA・JPUG合同DB勉強会)
No sql with mysql cluster (MyNA・JPUG合同DB勉強会)
 
MySQL 5.7とレプリケーションにおける改良
MySQL 5.7とレプリケーションにおける改良MySQL 5.7とレプリケーションにおける改良
MySQL 5.7とレプリケーションにおける改良
 
MySQL 5.7 Technical Update (日本語)
MySQL 5.7 Technical Update (日本語)MySQL 5.7 Technical Update (日本語)
MySQL 5.7 Technical Update (日本語)
 
MySQL Fabric with OpenStack Nova
MySQL Fabric with OpenStack NovaMySQL Fabric with OpenStack Nova
MySQL Fabric with OpenStack Nova
 
My sql security (暗号化)
My sql security (暗号化) My sql security (暗号化)
My sql security (暗号化)
 

MySQL8.0 SYS スキーマ概要

  • 1. MySQL8.0 SYS Schema概要 MySQL SYS Schemaによるパフォーマンスモニタリング Updated: 2018/05/10 @RDBMS URL: http://variable.jp
  • 2. 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
  • 4. 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
  • 5. 例: VIEWの変更箇所 (innodb_lock_waits) FROM ((((`information_schema`.`innodb_lock_waits` `w` JOIN `information_schema`.`innodb_trx` `b` ON ((`b`.`trx_id` = `w`.`blocking_trx_id`))) JOIN `information_schema`.`innodb_trx` `r` ON ((`r`.`trx_id` = `w`.`requesting_trx_id`))) JOIN `information_schema`.`innodb_locks` `bl` ON ((`bl`.`lock_id` = `w`.`blocking_lock_id`))) JOIN `information_schema`.`innodb_locks` `rl` ON ((`rl`.`lock_id` = `w`.`requested_lock_id`))) ORDER BY `r`.`trx_wait_started` FROM ((((`performance_schema`.`data_lock_waits` `w` JOIN `information_schema`.`INNODB_TRX` `b` ON ((CONVERT( `b`.`trx_id` USING UTF8MB4) = CAST(`w`.`BLOCKING_ENGINE_TRANSACTION_ID` AS CHAR CHARSET UTF8MB4)))) JOIN `information_schema`.`INNODB_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`.`ENGINE_LOCK_ID` = `w`.`BLOCKING_ENGINE_LOCK_ID`))) JOIN `performance_schema`.`data_locks` `rl` ON ((`rl`.`ENGINE_LOCK_ID` = `w`.`REQUESTING_ENGINE_LOCK_ID`))) ORDER BY `r`.`trx_wait_started` MySQL5.7.21 MySQL8.0.11
  • 6. 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 1 row in set (0.02 sec) root@localhost [sys]> SQLステートメントのアクティビティ、ファイルI / O、および接続をホスト別にまとめたものです。 データベースに接続してSQLステートメントを実行しているホストが、 ファイルI/Oやメモリーをどれだけ発生させているか確認出来ます。 どのホスト処理が負荷をかけているか容易に確認可能です。
  • 7. 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 3 rows in set (0.00 sec) root@localhost [sys]> ファイルI/Oをホストごとにまとめたものです。 デフォルトでは、ファイルI/O全体のレイテンシが降順に並べ替えられて行がソートされます。 データベースに接続しているホストが、ファイルI/Oをどれだけ発生させ ているか確認出来ます。どのホスト処理がI/O負荷をかけているか容易 に確認可能です。
  • 8. 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 max_latency: 18.18 ms 2 rows in set (0.00 sec) root@localhost [sys]> ファイルI/Oをホストとイベントのタイプ別にまとめたものです。 デフォルトでは、行はホストごとにソートされ、合計I/Oレイテンシは降順にソートされます。 データベースに接続しているホストが、ファイルI/Oをどれだけ発生させて いるか確認出来ます。EVENT_NAMEは計測された値を示しています。
  • 9. 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 total_latency: 21.87 ms avg_latency: 21.87 ms 1 row in set (0.00 sec) root@localhost [sys]> ステートメントのステージをホストごとにまとめたものです。 デフォルトで、行はホストごとにソートされ、合計レイテンシは降順にソートされます。 ステートメントがどのような状態にあるか、ホスト毎に確認可能です。 処理に時間がかかっている処理順にソートされているため、 ステージ毎に重い処理を特定することが可能です。
  • 10. 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 total_latency: 147.37 ms max_latency: 22.52 ms lock_latency: 101.21 ms rows_sent: 118 rows_examined: 2758 rows_affected: 0 full_scans: 5 1 row in set (0.00 sec) root@localhost [sys]> ホストごとにサマライズされた、全体的なステートメント統計を要約します。 デフォルトで、行は合計レイテンシを降順にソートされます。 ホスト毎にステートメントの遅延状態を確認する事が可能です。 処理に時間がかかっているステートメント順にソートされているため、 時間のかかっているステートメントを容易に特定することが可能です。
  • 11. 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 1 row in set (0.00 sec) root@localhost [sys]> 実行されたステートメントに関する情報を、ホストおよびステートメントタイプ別にグループ化して要約し たものです。 デフォルトでは、行はホストごとにソートされ、合計レイテンシは降順にソートされます。 ホスト毎のステートメント種類毎にレイテンシを確認可能です。 参照処理が特に重い場合は、メモリー設定やインデックス等を見直して みるのも良いかもしれません。
  • 12. 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 2 rows in set (0.03 sec) スキーマごとにグループ化されたINFORMATION_SCHEMA INNODB_BUFFER_PAGE表の情報を要約します。 デフォルトで、行はバッファサイズの降順でソートされます。 スキーマ毎にInnoDB Buffer Poolの利用状況を確認する事が出来る為、 メモリーを多く利用しすぎている場合などは、インデックスなどが適切に利 用されているか確認してみると良いかもしれません。
  • 13. 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_schema: mysql 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_schema: mysql 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の利用状況を確認する事が出来る為、 メモリーを多く利用しすぎている場合などは、インデックスなどが適切に  利用されているか確認してみると良いかもしれません。
  • 14. 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でブロックしている処理を停止、 させる事も可能です。
  • 15. 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 total_latency: 120.04 ms min_latency: 35.58 ns avg_latency: 333.45 us max_latency: 19.09 ms thread_id: 1 processlist_id: NULL 1 row in set (0.01 sec) root@localhost [sys]> スレッドごとにグループ化されたI/O待機時間を表示するためにI/Oコンシューマを要約します。 デフォルトで、行は合計I/O待機時間を降順にソートされます。 どのスレッド処理がI/Oを多く発生させているか確認できます。 合計だけでなく、平均、最大、最小も確認出来るので、 一時的なものなのか? 等確認する事が出来ます。
  • 16. 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バイトが多く発生しているか確認出来る 為、ファイルのパスを変更する等の検討材料にも利用可能です。
  • 17. 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 *************************** file: @@basedir/data/undo_002 total: 390 total_latency: 598.68 ms 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 *************************** file: @@basedir/data/undo_001 total: 397 total_latency: 526.48 ms 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領域の負荷が高い場合
  • 18. 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 total_latency: 1.70 s min_latency: 0 ps avg_latency: 860.51 us max_latency: 81.06 ms count_read: 1251 total_read: 21.70 MiB avg_read: 17.76 KiB count_write: 536 total_written: 20.39 MiB avg_written: 38.96 KiB total_requested: 42.09 MiB 1 row in set (0.01 sec) root@localhost [sys]> グローバルI/Oコンシューマを要約し、I/O量と待機時間をイベント別にグループ化して表示。 デフォルトで、行は合計I/O(読み書きされたバイト数)を降順にソートされます。 どのデータベースファイルにI/O遅延が多く発生しているか確認出来る 為、ファイルのパスを変更する等の検討材料にも利用可能です。 特定のテーブルの場合、インデックス等も検討してみると良さそうです。
  • 19. 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 total_latency: 1.70 s avg_latency: 860.51 us max_latency: 81.06 ms read_latency: 1.67 s write_latency: 26.17 ms misc_latency: 2.42 ms count_read: 1251 total_read: 21.70 MiB avg_read: 17.76 KiB count_write: 536 total_written: 20.39 MiB avg_written: 38.96 KiB 1 row in set (0.00 sec) グローバルI/Oコンシューマを要約し、I/O量と待機時間をイベント別にグループ化して表示します。 デフォルトで、行は合計レイテンシを降順にソートされます。 どのデータベースファイルにI/O遅延が多く発生しているか確認出来る 為、ファイルのパスを変更する等の検討材料にも利用可能です。 特定のテーブルの場合、インデックス等も検討してみると良さそうです。
  • 20. 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_count_used: 530 current_allocated: 1.92 MiB current_avg_alloc: 3.70 KiB current_max_alloc: 1012.80 KiB total_allocated: 208.39 MiB 2 rows in set (0.00 sec) root@localhost [sys]> ホストごとにグループ化されたメモリー使用量を要約します。 デフォルトで、行は使用されたメモリ量の降順でソートされます。 現在、どのホストがメモリーを多く、使用しているか確認する事が可能。
  • 21. 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 current_count_used: 301 current_allocated: 1.33 MiB current_avg_alloc: 4.53 KiB current_max_alloc: 1012.80 KiB total_allocated: 206.70 MiB *************************** 2. row *************************** thread_id: 42 user: sql/event_scheduler current_count_used: 3 current_allocated: 16.18 KiB current_avg_alloc: 5.39 KiB current_max_alloc: 16.01 KiB total_allocated: 16.18 KiB 2 rows in set (0.03 sec) スレッドごとにグループ化されたメモリー使用量を要約します。 デフォルトで、行は使用されたメモリ量の降順でソートされます。 現在、どのスレッドがメモリーを多く、使用しているか確認する事が可能。
  • 22. 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_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 *************************** user: root current_count_used: 294 current_allocated: 1.33 MiB current_avg_alloc: 4.62 KiB current_max_alloc: 1012.80 KiB total_allocated: 214.53 MiB 2 rows in set (0.01 sec) root@localhost [sys]> ユーザーごとにグループ化されたメモリー使用量を要約します。 デフォルトで、行は使用されたメモリ量の降順でソートされます。 現在、どのユーザーがメモリーを多く、使用しているか確認する事が可能。
  • 23. 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 current_avg_alloc: 136.26 KiB 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 2 rows in set (0.00 sec) 割り当てられたタイプ(イベント別)毎にグループ化されたメモリー使用量を要約します。   デフォルトで、行は使用されたメモリ量の降順でソートされます。 現在、どのイベントがメモリーを多く、使用しているか確認する事が可能。
  • 24. memory_global_totalおよびx$memory_global_total root@localhost [sys]> SELECT * FROM sys.memory_global_total limit 2G *************************** 1. row *************************** total_allocated: 251.08 MiB 1 row in set (0.00 sec) root@localhost [sys]> サーバー内の合計メモリー使用量を要約します。 MySQL全体で利用しているメモリー量の合計を確認出来ます。 搭載されているメモリーと合わせて調整してみてください。
  • 25. 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 | +----------------------------------+--------------------------------------------------+---------------+---------+ 10 rows in set (0.01 sec) MySQLサーバのメトリックを、変数、値、タイプ毎にまとめ、それらが有効かどうかを 表示します。 デフォルトで、行は変数の型と名前でソートされます SHOW VARIABLES等で確認可能な現状の設定値を確認可能です。
  • 26. 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等も確認したい場合は、こちらを利用すると良い。
  • 27. 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 1 row in set (0.00 sec) パフォーマンススキーマがすべてのランタイムデータを監視できないかどうかを示すために、 失われたパフォーマンススキーマインストゥルメントに関する情報を返します。 パフォーマンススキーマがどのランタイムデータを監視出来ていないか、 不足しているインストゥルメントを確認可能です。
  • 28. 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 1 row in set (0.01 sec) root@localhost [sys]> インスタンスで利用している、auto_incrementのテーブル、列一覧を確認する事が可能です。 データ型、現在の利用率(%)なども確認可能。 インスタンスで利用されている, auto_incrementの値を確認可能です。 もし、int等ですでに上限に近い場合は、データ型を変更する等検討可能
  • 29. 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 1 row in set (0.00 sec) root@localhost [sys]> 索引統計を一覧を確認する事が可能です。 デフォルトで、索引レイテンシの合計が降順にソートされます。 インデックスのレイテンシ事にソートされている為、 時間がかかっているインデックス等を容易に確認する事が可能です。
  • 30. 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 | +--------------------+---------------+-------+ 10 rows in set (0.02 sec) 各スキーマ内のオブジェクトのタイプをカウントしてまとめたものです。 デフォルトで、行はスキーマとオブジェクトタイプによってソートされます。 スキーマ毎のオブジェクト数などを容易に確認可能です。 データベース移行時などにも、オブジェクト漏れがないか確認可能。
  • 31. 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` 1 row in set (0.36 sec) root@localhost [sys]> schema_redundant_indexesビューには、重複して不要と考えられる索引が表示されます。 x$schema_flattened_keysビューは、schema_redundant_indexesのヘルパービューです。 重複しているインデックスをスキーマ・テーブル毎に確認可能です。 sql_drop_indexを実行する事で削除することが可能です。
  • 32. 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 どのセッションがメタデータのロックを待ってブロックされているのか?、 どの処理が原因でブロックされているのか?を表示します。 どのテーブルがどのような処理に待たされているか確認可能です。
  • 33. 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のヘルパービューを表示します。 テーブル毎の統計を一覧で確認する事が可能です。 特定の処理が遅い時などに、ざっくりと確認するのに使うのも良いかと。
  • 34. 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を利用しているか? 待機処理が発生しているかなど確認する事が出来ます。
  • 35. 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 *************************** object_schema: AdventureWorks2012 object_name: Address index_name: AK_Address_rowguid *************************** 3. row *************************** object_schema: AdventureWorks2012 object_name: Address index_name: rowguid 3 rows in set (0.04 sec) root@localhost [sys]> 使用されたイベントが、存在しないインデックス(使用されないインデックス)がリスト表示されます。 デフォルトでは、行はスキーマとテーブルによってソートされます。 起動してから、一度も利用されていないインデックスを確認する事が 可能です。MySQL8.0から実装されたInvisible Indexと合わせて利用 すると、運用しやすくなるかもしれません。
  • 36. 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に似ていますが、 バックグラウンド・プロセスを除外しユーザー・セッションのみを表示します。 ユーザー処理に絞って処理を確認する事が出来るので、 システムのスレッドが多すぎてフィルターしたい場合などに便利。
  • 37. 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 | +-----------+-------------+--------------------+---------------------+ 3 rows in set (0.00 sec) root@localhost [sys]> 各接続ごとに、SSLバージョン、暗号、および再使用されたSSLセッションの数が表示されます。 ユーザーごとに利用されている、SSLセッションを確認可能。 ユーザー接続が暗号化されているか確認したい場合は便利。
  • 38. 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 total_latency: 13.91 m max_latency: 723.74 ms <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ビューに似ています。 デフォルトでは、行は合計レイテンシを降順にソートされます。 重いクエリー、インデックスを利用していないクエリー、 ソートバッファーに収まらない処理等いろいろと確認する事が可能!! このビューが一番、便利かもしれません。 
  • 39. 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 1 row in set (0.01 sec) root@localhost [sys]> エラーまたは警告を生成したステートメントを正規化し表示します。 デフォルトで、行はエラーと警告数の降順によってソートされます。 エラー若しくは警告が発生したステートメントを確認可能です。 exec_count、warningsを確認してみてください。
  • 40. 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 total_latency: 9.47 ms 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 フル・テーブル・スキャンを行ったステートメントが正規化され表示されます。 デフォルトで、フルスキャンが完了した時点のレイテンシ合計を降順にソートします。 フルスキャンが発生しているクエリーを確認する事が可能です。 インデックスを利用した方が当然早いので、対応を検討してください。
  • 41. 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 total_latency: 1.43 m 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パーセンタイルにあるすべて のステートメントがリストアップされているので、こちらも平均実行時間 が遅いクエリーを改善検討するのに利用可能です。
  • 42. 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 total_latency: 13.91 m 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 1 row in set (0.01 sec) ソートを実行したステートメントを正規化しリストします。 デフォルトで、行は合計レイテンシを降順にソートされます。 ソート処理を実行したクエリーを遅い順に確認出来る為、Order by, Group byでインデックスが利用されているか確認する事が可能。
  • 43. 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 total_latency: 171.71 ms 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 1 row in set (0.00 sec) root@localhost [sys]> 一時表を使用したステートメントが正規化されリストされます。 デフォルトで、使用されるディスク上の 一時テーブルの数、使用されるメモリ内の一時テーブルが降順で行がソートされます。 tempテーブル、tempテーブルサイズが不足していて、 ディスク処理されたクエリー等を確認する事が可能です。
  • 44. 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 1 row in set (0.02 sec) root@localhost [sys]> ユーザー毎にステートメントのアクティビティ、ファイルI/O、および接続を要約します。 デフォルトで、行は合計レイテンシを降順にソートされます。 どのアプリケーションユーザーの処理が重いのか? どれだけメモリーを利用しているのか?等を確認する事が可能です。
  • 45. 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 | +------------+------+------------+ 4 rows in set (0.00 sec) root@localhost [sys]> ファイルI/Oをユーザー別にまとめたものです。 デフォルトで、ファイルI/O全体のレイテンシが降順にソートされます。 どのアプリケーションユーザーの処理が重いのか? どれだけI/O処理を発生させているのか?等を確認する事が可能です。
  • 46. 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 | +------------+--------------------------------------+-------+----------+-------------+ 5 rows in set (0.00 sec) root@localhost [sys]> ファイルI / Oをユーザーとイベントのタイプ別にまとめたものです。 デフォルトで、行はユーザーと合計レイテンシの降順でソートされます。 どのアプリケーションユーザーの処理が重いのか? どれだけI/O処理を発生させているのか? またどのようなI/O処理イベントでレイテンシが発生していのか?
  • 47. 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 total_latency: 5.53 s avg_latency: 1.42 ms 2 rows in set (0.01 sec) ユーザー別にグループ化されたステージを要約します。 デフォルトで、行はユーザーごとに並べ替えられ、ステージの合計レイテンシが降順で並べ替えられます。 ユーザー毎のイベント処理をレイテンシ順に確認する事が可能です。 どんなイベントで特定のユーザーにレイテンシが発生しているのか?、 確認する事が可能です。
  • 48. 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 | +----------+-------+---------------+-------------+--------------+-----------+---------------+---------------+------------+ 3 rows in set (0.01 sec) root@localhost [sys]> ユーザーごとにグループ化された、全体的なステートメント統計を要約します。 デフォルトで、行は合計レイテンシを降順にソートされます。 ユーザー毎にステートメント全体のレイテンシ状況を確認する事が可能 です。細かく調べる前に、ある程度目星を付けるのに利用すると良さそう。
  • 49. 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 total_latency: 201.18 ms max_latency: 100.26 ms lock_latency: 198.28 ms rows_sent: 4 rows_examined: 66 rows_affected: 0 full_scans: 0 1 row in set (0.01 sec) root@localhost [sys]> 実行されたステートメントに関する情報を、ユーザーおよびステートメントタイプごとにまとめたものです。 デフォルトで、行はユーザーと合計レイテンシの降順でソートされます。 ユーザー毎のステートメントタイプ毎に、レイテンシ状況を確認する事が 可能です。細かく調べる前に、どんな処理で遅延が発生しているのかを、 深堀していくのに使えそうです。
  • 50. version root@localhost [sys]> SELECT * FROM sys.version limit 1; +-------------+---------------+ | sys_version | mysql_version | +-------------+---------------+ | 2.0.0 | 8.0.11 | +-------------+---------------+ 1 row in set (0.00 sec) root@localhost [sys]> 現在のsysスキーマとMySQLサーバのバージョンが表示されます。 あまり使いどころは無いかもしれませんが、バージョンを確認する事が 可能なので、運用・管理ツールから、バージョンを確認するような場面で 使えるかもしれません。
  • 51. 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 | +-----------------+-------+---------------+-------------+-------------+-------------+ 3 rows in set (0.01 sec) 平均クラス待機時間を、イベントクラス毎にまとめたものです。 デフォルトで、行は平均待ち時間の降順でソートされます。 idleイベントは無視されます。 各イベントクラス毎の合計、最小、平均、最大レイテンシを確認する事が 可能です。インスタンス全体でどんなイベントでレイテンシが発生してい るか確認して、対応策を検討するのに使う事が出来るかな。
  • 52. 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 | +---------------+-------+---------------+-------------+-------------+-------------+ 2 rows in set (0.01 sec) 待機クラスの合計待ち時間をイベントクラス別にまとめたものです。 デフォルトで、行は合計レイテンシを降順にソートされます。idleイベントは無視されます。 基本的には、wait_classes_global_by_avg_latencyと同じように、 イベントクラス毎の待機イベントを確認する事が可能です。
  • 53. 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 | +--------------+--------------------------------------+-------+---------------+-------------+-------------+ 10 rows in set (0.00 sec) ホストおよびイベントによってグループ化された待機イベントを要約します。 デフォルトで、行はホストごとにソートされ、合計レイテンシは降順にソートされidleイベントは無視されます。 各ホスト、各イベント毎にレイテンシを確認する事が可能です。 サービス遅延が発生したときに、ホスト毎に深堀する必要がある場合に イベント詳細を調べていくのに使えそうです。
  • 54. 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 | +----------+--------------------------------------+-------+---------------+-------------+-------------+ 10 rows in set (0.00 sec) ユーザーおよびイベントごとにグループ化された待機イベントを要約します。 デフォルトで、行はユーザーと合計レイテンシの降順でソートされます。idleイベントは無視されます。 各ユーザー、各イベント毎にレイテンシを確認する事が可能です。 サービス遅延が発生したときに、ユーザー毎に深堀する必要がある場合 にイベント詳細を調べていくのに使えそうです。
  • 55. 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 | +--------------------------------------+-------+---------------+-------------+-------------+ 5 rows in set (0.00 sec) root@localhost [sys]> イベントごとにグループ化された待機イベントを要約します。 デフォルトで、行は合計レイテンシを降順にソートされます。idleイベントは無視されます。 各イベント毎にレイテンシを確認する事が可能です。 サービス遅延が発生したときに、イベント毎に深堀する必要がある場合 にイベント詳細を調べていくのに使えそうです。
  • 57. プロシジャーの種類 root@localhost [sys]> SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE -> FROM information_schema.ROUTINES WHERE ROUTINE_TYPE = 'PROCEDURE'; +----------------+-------------------------------------+--------------+ | ROUTINE_SCHEMA | ROUTINE_NAME | ROUTINE_TYPE | +----------------+-------------------------------------+--------------+ | sys | create_synonym_db | PROCEDURE | | sys | execute_prepared_stmt | PROCEDURE | | sys | diagnostics | PROCEDURE | | sys | ps_statement_avg_latency_histogram | PROCEDURE | | sys | ps_trace_statement_digest | PROCEDURE | | sys | ps_trace_thread | PROCEDURE | | sys | ps_setup_disable_background_threads | PROCEDURE | | sys | ps_setup_disable_consumer | PROCEDURE | | sys | ps_setup_disable_instrument | PROCEDURE | | sys | ps_setup_disable_thread | PROCEDURE | | sys | ps_setup_enable_background_threads | PROCEDURE | | sys | ps_setup_enable_consumer | PROCEDURE | | sys | ps_setup_enable_instrument | PROCEDURE | | sys | ps_setup_enable_thread | PROCEDURE | | sys | ps_setup_reload_saved | PROCEDURE | | sys | ps_setup_reset_to_default | PROCEDURE | | sys | ps_setup_save | PROCEDURE | | sys | ps_setup_show_disabled | PROCEDURE | | sys | ps_setup_show_disabled_consumers | PROCEDURE | | sys | ps_setup_show_disabled_instruments | PROCEDURE | | sys | ps_setup_show_enabled | PROCEDURE | | sys | ps_setup_show_enabled_consumers | PROCEDURE | | sys | ps_setup_show_enabled_instruments | PROCEDURE | | sys | ps_truncate_all_tables | PROCEDURE | | sys | statement_performance_analyzer | PROCEDURE | | sys | table_exists | PROCEDURE | +----------------+-------------------------------------+--------------+ https://dev.mysql.com/doc/refman/5.7/en/sys- schema-procedures.html
  • 58. 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で削除
  • 59. 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のように定期的に診断して、 パフォーマンスデータを残しておきたい場合に利用可能です。 使いどころは様々なので、状況に応じて定期的にパフォーマンス 診断しておきたい場合は利用すると良いかもしれません。
  • 60. ps_trace_statement_digest() root@localhost [sys]> CALL ps_trace_statement_digest('41d00de8eda848e48552d7282da0e4b6', 10, 0.1, TRUE, TRUE); +-------------------+ | summary | +-------------------+ | Disabled 1 thread | +-------------------+ 1 row in set (0.01 sec) <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 | +------------+-----------+-----------+-----------+---------------+---------------+------------+------------+ 1 row in set (9.67 sec) 特定ステートメントダイジェストの全てのパフォーマンススキーマインストゥルメンテーションをトレースします。 パフォーマンス・スキーマのevents_statements_summary_by_digest表内で関心のある文を見つけた場合は、 このプロシージャーのDIGEST列MD5値を指定し、ポーリングの期間と間隔を指定します。 結果は、その期間 のダイジェストのパフォーマンススキーマ内で追跡されたすべての統計情報のレポートです。 特定のステートメントに関しての、パフォーマンスを全体的に調べたい時に 使えそうです。ダイジェストの値は、他のVIEWやevents_statements_current 等から確認する事も可能です。SELECT MD5('xxx')も使えるかと。
  • 61. 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グラフ記述言 語用)にダンプします。 プロシージャから返される各結果セットは、完全なグラフに使用する必要があります。 計測されたパフォーマンスデータをグラフィカルに表現する為に使えます。 但し、データが多いので確認するには使いずらいかもしれません。 資料を作成する場合などには、便利な機能かと思います。
  • 62. ps_truncate_all_tables() root@localhost [sys]> CALL sys.ps_truncate_all_tables(FALSE); +---------------------+ | summary | +---------------------+ | Truncated 49 tables | +---------------------+ 1 row in set (0.10 sec) Query OK, 0 rows affected (0.10 sec) root@localhost [sys]> すべてのパフォーマンス・スキーマのサマリー表をTruncateして、集計されたすべての計測をスナップショット としてリセットします。いくつのテーブルが切り捨てられたかを示す結果セットを生成します。 任意のクエリーのパフォーマンスを確認する直前に実行すると、容易にパフォーマンスを確認する事が可能。 ※ FALSEの代わりに、TRUEにすると結果セットのみで無く各TRUNCATE実行コマンドが表示される。 ※ MySQL5.7までは、”Truncated 44 tables”でしたが、MySQL8.0からは5つ対象テーブルが増えています。 特定のステートメントのパフォーマンスを調べたい時に、 予めこのコマンドでデータをTruncateしておくと分かりやすいので、 開発環境で調査するには便利です。
  • 64. ファンクションの種類 root@localhost [sys]> SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE -> FROM information_schema.ROUTINES WHERE ROUTINE_TYPE = 'FUNCTION'; +----------------+----------------------------------+--------------+ | ROUTINE_SCHEMA | ROUTINE_NAME | ROUTINE_TYPE | +----------------+----------------------------------+--------------+ | sys | extract_schema_from_file_name | FUNCTION | | sys | extract_table_from_file_name | FUNCTION | | sys | format_bytes | FUNCTION | | sys | format_path | FUNCTION | | sys | format_statement | FUNCTION | | sys | format_time | FUNCTION | | sys | list_add | FUNCTION | | sys | list_drop | FUNCTION | | sys | ps_is_account_enabled | FUNCTION | | sys | ps_is_consumer_enabled | FUNCTION | | sys | ps_is_instrument_default_enabled | FUNCTION | | sys | ps_is_instrument_default_timed | FUNCTION | | sys | ps_is_thread_instrumented | FUNCTION | | sys | ps_thread_id | FUNCTION | | sys | ps_thread_account | FUNCTION | | sys | ps_thread_stack | FUNCTION | | sys | ps_thread_trx_info | FUNCTION | | sys | quote_identifier | FUNCTION | | sys | sys_get_config | FUNCTION | | sys | version_major | FUNCTION | | sys | version_minor | FUNCTION | | sys | version_patch | FUNCTION | +----------------+----------------------------------+--------------+ https://dev.mysql.com/doc/refman/5.7/en/sys-schema- functions.html
  • 65. ファンクション例: root@localhost [sys]> SELECT VERSION(), version_major(); +-----------+-----------------+ | VERSION() | version_major() | +-----------+-----------------+ | 8.0.11 | 8 | +-----------+-----------------+ 1 row in set (0.00 sec) root@localhost [sys]> SELECT format_bytes(512), format_bytes(18446644073709551615); +-------------------+------------------------------------+ | format_bytes(512) | format_bytes(18446644073709551615) | +-------------------+------------------------------------+ | 512 bytes | 16383.91 PiB | +-------------------+------------------------------------+ 1 row in set (0.00 sec) root@localhost [sys]> 以下のように、メジャーバージョンを表示したり、バイトを KiB (kibibytes), MiB (mebibytes), GiB (gibibytes), TiB (tebibytes), or PiB (pebibytes)等に変換したりするヘルパー的なファンクションが多い。 ファンクションはヘルパー的なものが多いので、 各利用者の環境に応じて、必要に応じて使うのがよさそうです。