第 22 章 MySQL パフォーマンススキーマ

目次

22.1 パフォーマンススキーマクイックスタート
22.2 パフォーマンススキーマ構成
22.2.1 パフォーマンススキーマビルド構成
22.2.2 パフォーマンススキーマ起動構成
22.2.3 パフォーマンススキーマ実行時構成
22.3 パフォーマンススキーマクエリー
22.4 パフォーマンススキーマインストゥルメント命名規則
22.5 パフォーマンススキーマステータスモニタリング
22.6 パフォーマンススキーマの原子的および分子的イベント
22.7 パフォーマンススキーマステートメントダイジェスト
22.8 パフォーマンススキーマの一般的なテーブル特性
22.9 パフォーマンススキーマテーブルの説明
22.9.1 パフォーマンススキーマテーブルインデックス
22.9.2 パフォーマンススキーマセットアップテーブル
22.9.3 パフォーマンススキーマインスタンステーブル
22.9.4 パフォーマンススキーマ待機イベントテーブル
22.9.5 パフォーマンススキーマステージイベントテーブル
22.9.6 パフォーマンススキーマステートメントイベントテーブル
22.9.7 パフォーマンススキーマ接続テーブル
22.9.8 パフォーマンススキーマ接続属性テーブル
22.9.9 パフォーマンススキーマサマリーテーブル
22.9.10 パフォーマンススキーマのその他のテーブル
22.10 パフォーマンススキーマオプションおよび変数リファレンス
22.11 パフォーマンススキーマコマンドオプション
22.12 パフォーマンススキーマシステム変数
22.13 パフォーマンススキーマステータス変数
22.14 パフォーマンススキーマとプラグイン
22.15 問題を診断するためのパフォーマンススキーマの使用

MySQL パフォーマンススキーマは低レベルで MySQL サーバーの実行をモニタリングするための機能です。パフォーマンススキーマには、これらの特性があります。

パフォーマンススキーマは、サーバーパフォーマンスに与える影響を最小にしながら、サーバー実行に関する有益な情報へのアクセスを提供することを目的としています。実装はこれらの設計目標に従います。

22.1 パフォーマンススキーマクイックスタート

このセクションでは、その使用方法を示す例によって、パフォーマンススキーマについて簡単に紹介します。追加の例については、セクション22.15「問題を診断するためのパフォーマンススキーマの使用」を参照してください。

パフォーマンススキーマを使用できるようにするには、MySQL の構築時にそのサポートが構成されている必要があります。これが当てはまるかどうかは、サーバーのヘルプ出力をチェックして確認できます。パフォーマンススキーマを使用できる場合、出力に、performance_schema で始まる名前の付いたいくつかの変数が示されます。

shell> mysqld --verbose --help... --performance_schema Enable the performance schema. --performance_schema_events_waits_history_long_size=# Number of rows in events_waits_history_long.
...

そのような変数が出力に表示されない場合、サーバーはパフォーマンススキーマをサポートするように構築されていません。この場合は、セクション22.2「パフォーマンススキーマ構成」を参照してください。

パフォーマンススキーマを使用できるものとして、MySQL 5.6.6 以降、それはデフォルトで有効にされます。5.6.6 より前では、それはデフォルトで無効にされます。それを明示的に有効または無効にするには、performance_schema 変数を適切な値に設定して、サーバーを起動します。たとえば、my.cnf ファイルでこれらの行を使用します。

[mysqld]
performance_schema=on

サーバーは起動すると、performance_schema を確認し、パフォーマンススキーマの初期化を試みます。初期化の成功を確認するには、このステートメントを使用します。

mysql> SHOW VARIABLES LIKE 'performance_schema';+--------------------+-------+
| Variable_name | Value |
+--------------------+-------+
| performance_schema | ON |
+--------------------+-------+

ON の値はパフォーマンススキーマが正常に初期化され、使用する準備ができていることを意味します。OFF の値は何らかのエラーが発生していることを意味します。何に異常が発生したかに関する情報については、サーバーエラーログをチェックしてください。

パフォーマンススキーマはストレージエンジンとして実装されます。このエンジンを使用できる場合 (先にすでにチェックしているはずです)、INFORMATION_SCHEMA.ENGINES テーブルまたは SHOW ENGINES ステートメントからの出力に、SUPPORT 値が YES でそれが表示されていることでわかるはずです。

mysql> SELECT * FROM INFORMATION_SCHEMA.ENGINES -> WHERE ENGINE='PERFORMANCE_SCHEMA'\G*************************** 1. row *************************** ENGINE: PERFORMANCE_SCHEMA SUPPORT: YES COMMENT: Performance Schema
TRANSACTIONS: NO XA: NO SAVEPOINTS: NO
mysql> SHOW ENGINES\G... Engine: PERFORMANCE_SCHEMA Support: YES Comment: Performance Schema
Transactions: NO XA: NO Savepoints: NO
...

PERFORMANCE_SCHEMA ストレージエンジンは、performance_schema データベース内のテーブルを操作します。そのテーブルへの参照をデータベース名で修飾する必要がないように、performance_schema をデフォルトのデータベースにすることができます。

mysql> USE performance_schema;

この章の多くの例では、performance_schema がデフォルトのデータベースであるとしています。

パフォーマンススキーマテーブルは performance_schema データベースに格納されます。このデータベースとそのテーブルの構造に関する情報を取得するには、ほかのすべてのデータベースのように、INFORMATION_SCHEMA データベースから選択するか、SHOW ステートメントを使用します。たとえば、どのパフォーマンススキーマテーブルが存在するか確認するには、これらのいずれかのステートメントを使用します。

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES -> WHERE TABLE_SCHEMA = 'performance_schema';+----------------------------------------------------+
| TABLE_NAME |
+----------------------------------------------------+
| accounts |
| cond_instances |
| events_stages_current |
| events_stages_history |
| events_stages_history_long |
| events_stages_summary_by_account_by_event_name |
| events_stages_summary_by_host_by_event_name |
| events_stages_summary_by_thread_by_event_name |
| events_stages_summary_by_user_by_event_name |
| events_stages_summary_global_by_event_name |
| events_statements_current |
| events_statements_history |
| events_statements_history_long |
...
| file_instances |
| file_summary_by_event_name |
| file_summary_by_instance |
| host_cache |
| hosts |
| mutex_instances |
| objects_summary_global_by_type |
| performance_timers |
| rwlock_instances |
| session_account_connect_attrs |
| session_connect_attrs |
| setup_actors |
| setup_consumers |
| setup_instruments |
| setup_objects |
| setup_timers |
| socket_instances |
| socket_summary_by_event_name |
| socket_summary_by_instance |
| table_io_waits_summary_by_index_usage |
| table_io_waits_summary_by_table |
| table_lock_waits_summary_by_table |
| threads |
| users |
+----------------------------------------------------+
mysql> SHOW TABLES FROM performance_schema;+----------------------------------------------------+
| Tables_in_performance_schema |
+----------------------------------------------------+
| accounts |
| cond_instances |
| events_stages_current |
| events_stages_history |
| events_stages_history_long |
...

パフォーマンススキーマテーブルの数は、追加のインストゥルメンテーションの実装が進行するにつれて、時間とともに増加することが予想されます。

performance_schema データベースの名前は小文字で、その中のテーブルの名前も同様です。クエリーでは名前を小文字で指定してください。

個々のテーブルの構造を表示するには、SHOW CREATE TABLE を使用します。

mysql> SHOW CREATE TABLE setup_timers\G*************************** 1. row *************************** Table: setup_timers
Create Table: CREATE TABLE `setup_timers` ( `NAME` varchar(64) NOT NULL, `TIMER_NAME` enum('CYCLE','NANOSECOND','MICROSECOND','MILLISECOND','TICK') NOT NULL
) ENGINE=PERFORMANCE_SCHEMA DEFAULT CHARSET=utf8

テーブル構造は、INFORMATION_SCHEMA.COLUMNS などのテーブルから選択するか、SHOW COLUMNS などのステートメントを使用して取得することもできます。

performance_schema データベース内のテーブルはそれらの中の情報の種類 (現在のイベント、イベント履歴およびサマリー、オブジェクトインスタンス、およびセットアップ (構成) 情報) に従ってグループ化できます。次の例に、これらのテーブルのいくつかの使用方法を示します。各グループのテーブルに関する詳細については、セクション22.9「パフォーマンススキーマテーブルの説明」を参照してください。

最初に、すべてのインストゥルメントとコンシューマが有効にされていないため、パフォーマンススキーマはすべてのイベントを収集しません。これらのすべてをオンにし、イベントタイミングを有効にするには、2 つのステートメントを実行します (行のカウントは MySQL バージョンによって異なることがあります)。

mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES';Query OK, 338 rows affected (0.12 sec)
mysql> UPDATE setup_consumers SET ENABLED = 'YES';Query OK, 8 rows affected (0.00 sec)

現在サーバーが何を行なっているかを確認するには、events_waits_current テーブルを調査します。それには、スレッドごとに、各スレッドの最新のモニターされたイベントを示す 1 行が含まれます。

mysql> SELECT * FROM events_waits_current\G*************************** 1. row *************************** THREAD_ID: 0 EVENT_ID: 5523 EVENT_NAME: wait/synch/mutex/mysys/THR_LOCK::mutex SOURCE: thr_lock.c:525 TIMER_START: 201660494489586 TIMER_END: 201660494576112 TIMER_WAIT: 86526 SPINS: NULL OBJECT_SCHEMA: NULL OBJECT_NAME: NULL OBJECT_TYPE: NULL
OBJECT_INSTANCE_BEGIN: 142270668 NESTING_EVENT_ID: NULL OPERATION: lock NUMBER_OF_BYTES: NULL FLAGS: 0
...

このイベントは、スレッド 0 が THR_LOCK::mutex のロック、mysys サブシステム内の相互排他ロックを獲得するために、86,526 ピコ秒待機していたことを示しています。最初のいくつかのカラムは次の情報を提供します。

  • ID カラムはイベントの発生元のスレッドとイベント番号を示します。

  • EVENT_NAME はインストゥルメントされたものを示し、SOURCE は、インストゥルメントされたコードを含むソースファイルを示します。

  • タイマーカラムはイベントが開始および停止したタイミングとそれにかかった時間を示します。イベントがまだ進行中の場合は、TIMER_ENDTIMER_WAIT の値が NULL になります。タイマー値は概算で、ピコ秒で表されます。タイマーおよびイベント時間コレクションについては、セクション22.2.3.1「パフォーマンススキーマイベントタイミング」を参照してください。

履歴テーブルには、現在のイベントテーブルと同じ種類の行が含まれますが、ほかの行もあり、サーバーが現在ではなく、最近何を実行していたかが示されます。events_waits_history および events_waits_history_long テーブルにはスレッドごとに最新の 10 イベントと最新の 10,000 イベントがそれぞれ含まれます。たとえば、スレッド 13 によって生成された最新イベントの情報を表示するには、次を実行します。

mysql> SELECT EVENT_ID, EVENT_NAME, TIMER_WAIT -> FROM events_waits_history WHERE THREAD_ID = 13 -> ORDER BY EVENT_ID;+----------+-----------------------------------------+------------+
| EVENT_ID | EVENT_NAME | TIMER_WAIT |
+----------+-----------------------------------------+------------+
| 86 | wait/synch/mutex/mysys/THR_LOCK::mutex | 686322 |
| 87 | wait/synch/mutex/mysys/THR_LOCK_malloc | 320535 |
| 88 | wait/synch/mutex/mysys/THR_LOCK_malloc | 339390 |
| 89 | wait/synch/mutex/mysys/THR_LOCK_malloc | 377100 |
| 90 | wait/synch/mutex/sql/LOCK_plugin | 614673 |
| 91 | wait/synch/mutex/sql/LOCK_open | 659925 |
| 92 | wait/synch/mutex/sql/THD::LOCK_thd_data | 494001 |
| 93 | wait/synch/mutex/mysys/THR_LOCK_malloc | 222489 |
| 94 | wait/synch/mutex/mysys/THR_LOCK_malloc | 214947 |
| 95 | wait/synch/mutex/mysys/LOCK_alarm | 312993 |
+----------+-----------------------------------------+------------+

履歴テーブルに新しいイベントが追加されると、テーブルがいっぱいである場合、古いイベントが破棄されます。

サマリーテーブルは、時間をかけてすべてのイベントについて集計された情報を提供します。このグループのテーブルには、さまざまな方法で、イベントデータが要約されます。もっとも多くの回数実行されたか、またはもっとも待機時間がかかったインストゥルメントを確認するには、COUNT_STAR または SUM_TIMER_WAIT カラムで events_waits_summary_global_by_event_name テーブルをソートします。これらのカラムはすべてのイベント全体で計算された、COUNT(*) または SUM(TIMER_WAIT) 値にそれぞれ対応します。

mysql> SELECT EVENT_NAME, COUNT_STAR -> FROM events_waits_summary_global_by_event_name -> ORDER BY COUNT_STAR DESC LIMIT 10;+---------------------------------------------------+------------+
| EVENT_NAME | COUNT_STAR |
+---------------------------------------------------+------------+
| wait/synch/mutex/mysys/THR_LOCK_malloc | 6419 |
| wait/io/file/sql/FRM | 452 |
| wait/synch/mutex/sql/LOCK_plugin | 337 |
| wait/synch/mutex/mysys/THR_LOCK_open | 187 |
| wait/synch/mutex/mysys/LOCK_alarm | 147 |
| wait/synch/mutex/sql/THD::LOCK_thd_data | 115 |
| wait/io/file/myisam/kfile | 102 |
| wait/synch/mutex/sql/LOCK_global_system_variables | 89 |
| wait/synch/mutex/mysys/THR_LOCK::mutex | 89 |
| wait/synch/mutex/sql/LOCK_open | 88 |
+---------------------------------------------------+------------+
mysql> SELECT EVENT_NAME, SUM_TIMER_WAIT -> FROM events_waits_summary_global_by_event_name -> ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;+----------------------------------------+----------------+
| EVENT_NAME | SUM_TIMER_WAIT |
+----------------------------------------+----------------+
| wait/io/file/sql/MYSQL_LOG | 1599816582 |
| wait/synch/mutex/mysys/THR_LOCK_malloc | 1530083250 |
| wait/io/file/sql/binlog_index | 1385291934 |
| wait/io/file/sql/FRM | 1292823243 |
| wait/io/file/myisam/kfile | 411193611 |
| wait/io/file/myisam/dfile | 322401645 |
| wait/synch/mutex/mysys/LOCK_alarm | 145126935 |
| wait/io/file/sql/casetest | 104324715 |
| wait/synch/mutex/sql/LOCK_plugin | 86027823 |
| wait/io/file/sql/pid | 72591750 |
+----------------------------------------+----------------+

これらの結果には、THR_LOCK_malloc 相互排他ロックが、その使用される頻度とスレッドがそれを獲得しようとして待機する時間の量の両方に関して、ホットであることが示されます。

注記

THR_LOCK_malloc 相互排他ロックはデバッグビルドでのみ使用されます。本番ビルドでは、それが存在しないため、ホットではありません。

インスタンステーブルは、インストゥルメントされたオブジェクトの種類を記述します。インストゥルメントされたオブジェクトは、サーバーによって使われると、イベントを生成します。これらのテーブルは、イベント名と説明のメモまたはステータス情報を提供します。たとえば、file_instances テーブルは、ファイル I/O 操作のインストゥルメントのインスタンスとそれらに関連付けられたファイルを一覧表示します。

mysql> SELECT * FROM file_instances\G*************************** 1. row *************************** FILE_NAME: /opt/mysql-log/60500/binlog.000007
EVENT_NAME: wait/io/file/sql/binlog
OPEN_COUNT: 0
*************************** 2. row *************************** FILE_NAME: /opt/mysql/60500/data/mysql/tables_priv.MYI
EVENT_NAME: wait/io/file/myisam/kfile
OPEN_COUNT: 1
*************************** 3. row *************************** FILE_NAME: /opt/mysql/60500/data/mysql/columns_priv.MYI
EVENT_NAME: wait/io/file/myisam/kfile
OPEN_COUNT: 1
...

セットアップテーブルは、モニタリング特性の構成と表示に使われます。たとえば、選択されているイベントタイマーを表示するには、setup_timers テーブルをクエリーします。

mysql> SELECT * FROM setup_timers;+-----------+-------------+
| NAME | TIMER_NAME |
+-----------+-------------+
| idle | MICROSECOND |
| wait | CYCLE |
| stage | NANOSECOND |
| statement | NANOSECOND |
+-----------+-------------+

setup_instruments は、イベントを収集できる一連のインストゥルメントを一覧表示し、それらのうちどれが有効にされているかを示します。

mysql> SELECT * FROM setup_instruments;+------------------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+------------------------------------------------------------+---------+-------+
...
| wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES |
| wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES |
| wait/synch/mutex/sql/LOCK_lock_db | YES | YES |
| wait/synch/mutex/sql/LOCK_manager | YES | YES |
...
| wait/synch/rwlock/sql/LOCK_grant | YES | YES |
| wait/synch/rwlock/sql/LOGGER::LOCK_logger | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_connect | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_slave | YES | YES |
...
| wait/io/file/sql/binlog | YES | YES |
| wait/io/file/sql/binlog_index | YES | YES |
| wait/io/file/sql/casetest | YES | YES |
| wait/io/file/sql/dbopt | YES | YES |
...

インストゥルメント名の解釈方法を理解するには、セクション22.4「パフォーマンススキーマインストゥルメント命名規則」を参照してください。

インストゥルメントのイベントを収集するかどうかを制御するには、その ENABLED 値を YES または NO に設定します。例:

mysql> UPDATE setup_instruments SET ENABLED = 'NO' -> WHERE NAME = 'wait/synch/mutex/sql/LOCK_mysql_create_db';

パフォーマンススキーマは収集されたイベントを使用して、イベント情報のコンシューマとして機能する performance_schema データベース内のテーブルを更新します。setup_consumers テーブルは、使用可能なコンシューマとどれが有効にされているかを示します。

mysql> SELECT * FROM setup_consumers;+--------------------------------+---------+
| NAME | ENABLED |
+--------------------------------+---------+
| events_stages_current | NO |
| events_stages_history | NO |
| events_stages_history_long | NO |
| events_statements_current | YES |
| events_statements_history | NO |
| events_statements_history_long | NO |
| events_waits_current | NO |
| events_waits_history | NO |
| events_waits_history_long | NO |
| global_instrumentation | YES |
| thread_instrumentation | YES |
| statements_digest | YES |
+--------------------------------+---------+

パフォーマンススキーマがコンシューマをイベント情報の宛先として保守するかどうかを制御するには、その ENABLED 値を設定します。

セットアップテーブルについてとそれらを使用して、イベント収集を制御する詳細については、セクション22.2.3.2「パフォーマンススキーマイベントフィルタリング」を参照してください。

先述のグループのいずれにも分類されないその他のテーブルがいくつかあります。たとえば、performance_timers は、使用可能なイベントタイマーとそれらの特性を一覧表示します。タイマーの詳細については、セクション22.2.3.1「パフォーマンススキーマイベントタイミング」を参照してください。

22.2 パフォーマンススキーマ構成

MySQL パフォーマンススキーマを使用するには、これらの構成の考慮事項が適用されます。

22.2.1 パフォーマンススキーマビルド構成

パフォーマンススキーマを使用できるようにするには、構築時に MySQL サーバーにそれを構成する必要があります。Oracle Corporation によって提供されているバイナリ MySQL 配布は、パフォーマンススキーマをサポートするように構成されています。別のプロバイダのバイナリ MySQL 配布を使用する場合は、プロバイダに、配布が適切に構成されているかどうかを確認してください。

ソース配布から MySQL を構築する場合は、WITH_PERFSCHEMA_STORAGE_ENGINE オプションを有効にして、CMake を実行し、パフォーマンススキーマを有効にします。

shell> cmake . -DWITH_PERFSCHEMA_STORAGE_ENGINE=1

-DWITHOUT_PERFSCHEMA_STORAGE_ENGINE=1 オプションを使用して MySQL を構成すると、パフォーマンススキーマが含まれないため、それを含める場合は、このオプションを使用しないでください。セクション2.9.4「MySQL ソース構成オプション」を参照してください。

パフォーマンススキーマなし (または現在のすべてのテーブルを含まない可能性がある古いバージョンのパフォーマンススキーマ) で構成された以前のインストールに MySQL をインストールする場合は、サーバーの起動後に mysql_upgrade を実行して、すべての現在のテーブルを使用して performance_schema データベースが存在するようにしてください。次に、サーバーを再起動します。これを行う必要があることを示す 1 つの兆候は、エラーログ内に次のようなメッセージが存在することです。

[ERROR] Native table 'performance_schema'.'events_waits_history'
has the wrong structure
[ERROR] Native table 'performance_schema'.'events_waits_history_long'
has the wrong structure
...

サーバーにパフォーマンススキーマのサポートが組み込まれているかどうかを確認するには、そのヘルプ出力をチェックします。パフォーマンススキーマを使用できる場合、出力に、performance_schema で始まる名前の付いたいくつかの変数が示されます。

shell> mysqld --verbose --help... --performance_schema Enable the performance schema. --performance_schema_events_waits_history_long_size=# Number of rows in events_waits_history_long.
...

サーバーに接続し、SHOW ENGINES からの出力で PERFORMANCE_SCHEMA ストレージエンジンの名前が挙げられた行を探すこともできます。

mysql> SHOW ENGINES\G... Engine: PERFORMANCE_SCHEMA Support: YES Comment: Performance Schema
Transactions: NO XA: NO Savepoints: NO
...

構築時にサーバーにパフォーマンススキーマが構成されていない場合、SHOW ENGINES からの出力に、PERFORMANCE_SCHEMA の行が表示されません。SHOW DATABASES からの出力に、performance_schema が示されていることもありますが、それにはテーブルがなく、それを使用することはできません。

SHOW ENGINES 出力の PERFORMANCE_SCHEMA の行は、パフォーマンススキーマを使用できることを意味し、それが有効にされていることを意味しているわけではありません。それを有効にするには、次のセクションで説明するように、サーバーの起動時にそうする必要があります。

22.2.2 パフォーマンススキーマ起動構成

パフォーマンススキーマを使用できるものとして、MySQL 5.6.6 以降、それはデフォルトで有効にされます。5.6.6 より前では、それはデフォルトで無効にされます。それを明示的に有効または無効にするには、performance_schema 変数を適切な値に設定して、サーバーを起動します。たとえば、my.cnf ファイルでこれらの行を使用します。

[mysqld]
performance_schema=on

パフォーマンススキーマの初期化時に、サーバーが内部バッファーを割り当てることができない場合、パフォーマンススキーマは自動的に無効になり、performance_schemaOFF に設定して、サーバーがインストゥルメンテーションなしで実行します。

MySQL 5.6.4 以降、パフォーマンススキーマは、サーバー起動時のインストゥルメントおよびコンシューマの構成を許可します。これは、以前 setup_instruments および setup_consumers テーブルに UPDATE ステートメントを使用して、実行時にのみ可能でした。この変更は、サーバーの起動時にすでに初期化されているインストゥルメントを、実行時の構成で無効にするには遅すぎるために行われました。たとえば、wait/synch/mutex/sql/LOCK_open 相互排他ロックはサーバー起動時に 1 回初期化されるため、実行時に対応するインストゥルメントを無効にする試みは無効です。

サーバー起動時のインストゥルメントを制御するには、この形式のオプションを使用します。

--performance-schema-instrument='instrument_name=value'

ここで instrument_namewait/synch/mutex/sql/LOCK_open などのインストゥルメント名で、value はこれらのいずれかの値です。

  • offfalse、または 0: インストゥルメントを無効にします

  • ontrue、または 1: インストゥルメントを有効にして時間を測定します

  • counted: インストゥルメントを有効にしてカウント (時間測定ではなく) します

--performance-schema-instrument オプションではインストゥルメント名を 1 つしか指定できませんが、オプションの複数のインスタンスを指定して、複数のインストゥルメントを構成できます。さらに、インストゥルメント名にパターンを使用でき、パターンに一致するインストゥルメントを構成します。すべての条件同期インストゥルメントを有効で、カウント対象として構成するには、次のオプションを使用します。

--performance-schema-instrument='wait/synch/cond/%=counted'

すべてのインストゥルメントを無効にするには、次のオプションを使用します。

--performance-schema-instrument='%=off'

長いインストゥルメント名文字列は、順序に関係なく、短いパターン名より優先されます。インストゥルメントを選択するためのパターンの指定については、セクション22.2.3.4「フィルタリング操作のインストゥルメントまたはコンシューマの指定」を参照してください。

認識されないインストゥルメント名は無視されます。あとでインストールされたプラグインによってインストゥルメントを作成することは可能で、そのときに名前が認識され、構成されます。

サーバー起動時のコンシューマを制御するには、この形式のオプションを使用します。

--performance-schema-consumer-consumer_name=value

ここで、consumer_nameevents_waits_history などのコンシューマ名で、value はこれらのいずれかです。

  • offfalse、または 0: コンシューマのイベントを収集しません

  • ontrue、または 1: コンシューマのイベントを収集します

たとえば、events_waits_history コンシューマを有効にするには、次のオプションを使用します。

--performance-schema-consumer-events-waits-history=on

許可されるコンシューマ名は、setup_consumers テーブルを調べるとわかります。パターンは許可されません。setup_consumers テーブル内のコンシューマ名は下線が使われますが、起動時に設定されたコンシューマでは、名前の中のダッシュと下線は同等です。

パフォーマンススキーマには、構成情報を提供するいくつかのシステム変数が含まれます。

mysql> SHOW VARIABLES LIKE 'perf%';+--------------------------------------------------------+---------+
| Variable_name | Value |
+--------------------------------------------------------+---------+
| performance_schema | ON |
| performance_schema_accounts_size | 100 |
| performance_schema_digests_size | 200 |
| performance_schema_events_stages_history_long_size | 10000 |
| performance_schema_events_stages_history_size | 10 |
| performance_schema_events_statements_history_long_size | 10000 |
| performance_schema_events_statements_history_size | 10 |
| performance_schema_events_waits_history_long_size | 10000 |
| performance_schema_events_waits_history_size | 10 |
| performance_schema_hosts_size | 100 |
| performance_schema_max_cond_classes | 80 |
| performance_schema_max_cond_instances | 1000 |
...

performance_schema 変数は ON または OFF で、パフォーマンススキーマが有効か無効かを示します。ほかの変数はテーブルサイズ (行数) やメモリー割り当て値を示します。

注記

パフォーマンススキーマが有効にされている場合、パフォーマンススキーマインスタンスの数は、おそらく大きくサーバーメモリーフットプリントに影響します。パフォーマンススキーマのシステム変数の値をチューニングして、インストゥルメントの不足と過剰なメモリー消費のバランスをとるインスタンスの数を見つける必要がある可能性があります。

パフォーマンススキーマシステム変数の値を変更するには、それらをサーバー起動時に設定します。たとえば、my.cnf ファイルに、履歴テーブルのサイズを変更するために次の行を入れます。

[mysqld]
performance_schema
performance_schema_events_waits_history_size=20
performance_schema_events_waits_history_long_size=15000

MySQL 5.6.6 以降、パフォーマンススキーマは、そのパラメータのいくつかの値を、それらが明示的に設定されていない場合に、サーバーの起動時に自動的にサイズ設定します。たとえば、それはイベント待機テーブルのサイズを制御するパラメータをこのようにサイズ設定します。どのパラメータがこのポリシーでサイズ設定されるかを確認するには、mysqld --verbose --help を使用し、−1 のデフォルト値を持つものを探すか、セクション22.12「パフォーマンススキーマシステム変数」を参照してください。

サーバー起動時に設定されていない (または −1 に設定されている) 自動サイズ設定される各パラメータについて、パフォーマンススキーマは、次のシステム変数の値に基づいてその値を設定する方法を判断します。それらは、MySQL サーバーをどのように構成しているかに関するヒントとみなされます。

max_connections
open_files_limit
table_definition_cache
table_open_cache

特定のパラメータの自動サイズ設定をオーバーライドするには、起動時にそれに −1 以外の値を設定します。この場合、パフォーマンススキーマはそれに指定された値を割り当てます。

実行時に、SHOW VARIABLES では、自動サイズ設定されたパラメータに設定されていた実際の値が表示されます。

パフォーマンススキーマが無効にされている場合、その自動サイズ設定されたパラメータは −1 に設定されたままになり、SHOW VARIABLES では −1 が表示されます。

22.2.3 パフォーマンススキーマ実行時構成

パフォーマンススキーマセットアップテーブルには、モニタリング構成に関する情報が含まれます。

mysql> SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES -> WHERE TABLE_SCHEMA = 'performance_schema' -> AND TABLE_NAME LIKE 'setup%';+-------------------+
| TABLE_NAME |
+-------------------+
| setup_actors |
| setup_consumers |
| setup_instruments |
| setup_objects |
| setup_timers |
+-------------------+

これらのテーブルの内容を調査して、パフォーマンススキーマのモニタリング特性に関する情報を取得できます。UPDATE 権限を持っている場合は、セットアップテーブルを変更して、モニタリングが行われる方法に影響するパフォーマンススキーマ操作を変更できます。これらのテーブルの追加の詳細については、セクション22.9.2「パフォーマンススキーマセットアップテーブル」を参照してください。

選択されているイベントタイマーを表示するには、setup_timers テーブルをクエリーします。

mysql> SELECT * FROM setup_timers;+-----------+-------------+
| NAME | TIMER_NAME |
+-----------+-------------+
| idle | MICROSECOND |
| wait | CYCLE |
| stage | NANOSECOND |
| statement | NANOSECOND |
+-----------+-------------+

NAME 値はタイマーが適用されるインストゥルメントの種類を示し、TIMER_NAME はそれらのインストゥルメントに適用されるタイマーを示します。タイマーは、名前が NAME 値に一致するコンポーネントから始まるインストゥルメントに適用されます。

タイマーを変更するには、NAME 値を更新します。たとえば、wait タイマーに NANOSECOND タイマーを使用するには:

mysql> UPDATE setup_timers SET TIMER_NAME = 'NANOSECOND' -> WHERE NAME = 'wait';mysql> SELECT * FROM setup_timers;+-----------+-------------+
| NAME | TIMER_NAME |
+-----------+-------------+
| idle | MICROSECOND |
| wait | NANOSECOND |
| stage | NANOSECOND |
| statement | NANOSECOND |
+-----------+-------------+

タイマーの説明については、セクション22.2.3.1「パフォーマンススキーマイベントタイミング」を参照してください。

setup_instruments および setup_consumers テーブルは、イベントを収集できるインストゥルメントと、イベント情報が実際に収集されるコンシューマの種類をそれぞれ一覧表示します。その他のセットアップテーブルにより、モニタリング構成をさらに変更できます。セクション22.2.3.2「パフォーマンススキーマイベントフィルタリング」では、イベントコレクションに影響するように、これらのテーブルをどのように変更できるかについて説明しています。

実行時に SQL ステートメントを使用して行う必要があるパフォーマンススキーマ構成の変更があり、これらの変更をサーバーが起動するたびに有効になるようにする場合、ファイルにステートメントを入れ、--init-file=file_name オプションを使用してサーバーを起動します。この戦略は、簡易サーバーヘルスモニタリング、インシデント調査、アプリケーション動作のトラブルシューティングなど、さまざまな種類のモニタリングを生成するようにそれぞれカスタマイズされている複数のモニタリング構成がある場合にも役に立つ可能性があります。各モニタリング構成のステートメントをそれらの固有のファイルに入れ、サーバーの起動時に --init-file 引数として、該当するファイルを指定します。

22.2.3.1 パフォーマンススキーマイベントタイミング

イベントは、サーバーソースコードに追加されたインストゥルメンテーションを使用して収集されます。インストゥルメントはイベントの時間を測定しますが、これはパフォーマンススキーマがイベントにどれくらいの時間がかかるかを知らせる方法です。タイミング情報を収集しないようにインストゥルメントを構成することもできます。このセクションでは、使用可能なタイマーとそれらの特性、およびイベント内のタイミング値を表す方法について説明します。

2 つのテーブルはタイマー情報を提供します。

  • performance_timers は、使用可能なタイマーとそれらの特性を一覧表示します。

  • setup_timers は、どのタイマーがどのインストゥルメントに使用されるかを示します。

setup_timers 内の各タイマー行は、performance_timers に示されているいずれかのタイマーを表している必要があります。

タイマーの精度とそれらに伴うオーバーヘッドの量はさまざまに異なります。使用可能なタイマーとそれらの特性を確認するには、performance_timers テーブルをチェックしてください。

mysql> SELECT * FROM performance_timers;+-------------+-----------------+------------------+----------------+
| TIMER_NAME | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+-------------+-----------------+------------------+----------------+
| CYCLE | 2389029850 | 1 | 72 |
| NANOSECOND | NULL | NULL | NULL |
| MICROSECOND | 1000000 | 1 | 585 |
| MILLISECOND | 1035 | 1 | 738 |
| TICK | 101 | 1 | 630 |
+-------------+-----------------+------------------+----------------+

TIMER_NAME カラムには使用可能なタイマーの名前が表示されます。CYCLE は CPU (プロセッサ) サイクルカウンタに基づいたタイマーを表します。特定のタイマーに関連付けられた値が NULL の場合、そのタイマーはプラットフォームでサポートされていません。NULLのない行は、setup_timers で使用できるタイマーを示しています。

TIMER_FREQUENCY は、1 秒あたりのタイマー単位数を示します。サイクルタイマーの場合、頻度は一般に CPU 速度に関連します。示された値は、2.4GHz プロセッサを搭載するシステムで取得されました。ほかのタイマーは固定の数秒に基づきます。TICK の場合、頻度はプラットフォームごとに異なることがあります (たとえば、100 ティック/秒を使用するものや、1000 ティック/秒を使用するものがあります)。

TIMER_RESOLUTION は、タイマー値が一度に増加するタイマー単位数を示します。タイマーの分解能が 10 の場合、その値は毎回 10 ずつ増加します。

TIMER_OVERHEAD は特定のタイマーで 1 つのタイミングを取得するためのオーバーヘッドの最小サイクル数です。タイマーはイベントの開始と終了で呼び出されるため、イベントあたりのオーバーヘッドは表示される値の 2 倍になります。

有効なタイマーを確認し、タイマーを変更するには、setup_timers テーブルにアクセスします。

mysql> SELECT * FROM setup_timers;+-----------+-------------+
| NAME | TIMER_NAME |
+-----------+-------------+
| idle | MICROSECOND |
| wait | NANOSECOND |
| stage | NANOSECOND |
| statement | NANOSECOND |
+-----------+-------------+
mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND' -> WHERE NAME = 'wait';mysql> SELECT * FROM setup_timers;+-----------+-------------+
| NAME | TIMER_NAME |
+-----------+-------------+
| idle | MICROSECOND |
| wait | MICROSECOND |
| stage | NANOSECOND |
| statement | NANOSECOND |
+-----------+-------------+

デフォルトで、パフォーマンススキーマは各インストゥルメントの種類で使用可能な最高のタイマーを使用しますが、ユーザーが別のものを選択することもできます。

待機の時間を測定する場合、もっとも重要な基準は、タイマーの精度を犠牲にする可能性があっても、オーバーヘッドを削減することであるため、CYCLE タイマーを使用することがもっとも適切です。

ステートメント (またはステージ) の実行にかかる時間は、一般に単一の待機の実行にかかる時間より桁違いに大きくなります。ステートメントの時間を測定するために、もっとも重要な基準は、プロセッサの周波数の変更に影響を受けない正確な測定基準を設定することであるため、サイクルに基づいていないタイマーを使用することがもっとも適切です。ステートメントのデフォルトのタイマーは NANOSECOND です。タイマーを 2 回呼び出す (ステートメントの起動時に 1 回、その終了時に 1 回) ことによって発生するオーバーヘッドは、ステートメント自体の実行に使用される CPU 時間と比較して桁違いに小さいため、サイクルタイマーと比較した追加のオーバーヘッドは大きくありません。CYCLE タイマーを使用することにはメリットがなく、欠点だけです。

サイクルカウンタによって提供される精度はプロセッサ速度によって異なります。プロセッサが 1 GHz (10 億サイクル/秒) 以上で実行する場合、サイクルカウンタはナノ秒未満の精度を実現します。サイクルカウンタを使用することは、実際の時間を取得するより、はるかに負荷が小さくなります。たとえば、標準 gettimeofday() 関数は数百サイクルかかる可能性があり、これは 1 秒あたり数千または数百万回発生する可能性のあるデータ収集では、許容できないオーバーヘッドです。

サイクルカウンタには欠点もあります。

  • エンドユーザーは、何分の 1 秒などの時計の単位でタイミングを知ることを期待します。サイクルから秒に変換することは大きな負荷がかかる可能性があります。このため、変換はすばやいかなり概算的な乗算演算です。

  • ラップトップが節電モードになったときや熱の生成を抑えるために、CPU の速度が低下したときなどに、プロセッササイクルレートが変わることがあります。プロセッサのサイクルレートが変動した場合、サイクルから実時間単位への変換でエラーが発生することがあります。

  • サイクルカウンタは、プロセッサやオペレーティングシステムによって、信頼できない場合や使用できない場合があります。たとえば、Pentium では、命令は RDTSC (C 命令ではなくアセンブリ言語) であり、理論上オペレーティングシステムはユーザーモードプログラムのその使用を妨げることができます。

  • 異常実行またはマルチプロセッサ同期に関する一部のプロセッサの詳細により、カウンタが最大 1000 サイクルごとに高速になったり、低速になったりするように見えることがあります。

現在、MySQL は、x386 (Windows、OS X、Linux、Solaris、およびその他の Unix フレーバー)、PowerPC、および IA-64 のサイクルカウンタと連携します。

setup_instruments テーブルにはイベントを収集するインストゥルメントを示す ENABLED カラムがあります。このテーブルには、時間が測定されるインストゥルメントを示す TIMED カラムもあります。インストゥルメントが有効にされていない場合、イベントを生成しません。有効にされているインストゥルメントの時間が測定されない場合、インストゥルメントによって生成されたイベントの TIMER_STARTTIMER_END、および TIMER_WAIT タイマー値が NULL になります。これによって、サマリーテーブルの合計、最小、最大、および平均の時間値の計算時に、それらの値が無視されます。

イベント内で、イベントのタイミングの開始時に、有効なタイマーによって指定された単位で時間が保存されます。表示には、選択されたタイマーに関係なく、時間は標準単位に正規化するために、ピコ秒 (1 兆分の 1 秒) で示されます。

setup_timers テーブルへの変更はただちにモニタリングに影響します。すでに進行中のイベントは、開始時間に元のタイマーを使用し、終了時間に新しいタイマーを使用する可能性があるため、予測不可能な結果に至る場合があります。タイマーを変更した場合、TRUNCATE TABLE を使用して、パフォーマンススキーマの統計をリセットする必要がある場合があります。

サーバー起動時のパフォーマンススキーマの初期化で、タイマーベースライン (時間ゼロ) が発生します。イベント内の TIMER_START および TIMER_END 値はベースライン以降のピコ秒を表します。TIMER_WAIT 値はピコ秒での期間です。

イベント内のピコ秒値は概算です。それらの精度は、ある単位から別の単位への変換に伴う通常の誤差の形式に左右されます。CYCLE タイマーが使われ、プロセッサのレートがさまざまに異なる場合、ドリフトが発生することがあります。このため、サーバーの起動から経過した時間の正確な測定基準として、イベントの TIMER_START 値を見ることは妥当ではありません。一方、開始時間や期間によって、イベントを順序付けるために、ORDER BY 句に TIMER_START 値または TIMER_WAIT 値を使用することは適切です。

イベントでマイクロ秒などの値ではなく、ピコ秒を選択したことには、パフォーマンス上の根拠があります。1 つの実装目標は、タイマーに関係なく、統一された時間単位で結果を表示することでした。理想の世界では、この時間単位は時計の単位のように見え、適度に正確である、つまりマイクロ秒です。ただし、サイクルまたはナノ秒をマイクロ秒に変換するには、すべてのインストゥルメンテーションで除算を実行する必要がある場合があります。除算は多くのプラットフォームで高い負荷がかかります。乗算は負荷が高くないため、それを使用しています。そのため、時間単位は、大きな精度の損失がないように十分に大きな乗数を使用した、可能なかぎり最大の TIMER_FREQUENCY 値の整数の倍数です。その結果、時間単位がピコ秒になります。この精度は疑似ですが、この決定によりオーバーヘッドを最小にすることができます。

22.2.3.2 パフォーマンススキーマイベントフィルタリング

イベントはプロデューサ/コンシューマ方式で処理されます。

  • インストゥルメントされたコードは、イベントのソースで、収集されるイベントを生成します。setup_instruments テーブルは、イベントを収集できるインストゥルメント、それらが有効にされているかどうか、および (有効にされているインストゥルメントの場合) タイミング情報を収集するかどうかを一覧表示します。

    mysql> SELECT * FROM setup_instruments;+------------------------------------------------------------+---------+-------+
    | NAME | ENABLED | TIMED |
    +------------------------------------------------------------+---------+-------+
    ...
    | wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES |
    | wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES |
    | wait/synch/mutex/sql/LOCK_lock_db | YES | YES |
    | wait/synch/mutex/sql/LOCK_manager | YES | YES |
    ...

    setup_instruments テーブルはイベント生成のもっとも基本的な制御の形式を提供します。モニターされるオブジェクトやスレッドの種類に基づいて、イベント生成をさらに絞り込むには、セクション22.2.3.3「イベントの事前フィルタリング」に説明するように、ほかのテーブルを使用できます。

  • パフォーマンススキーマテーブルは、イベントの宛先で、イベントを消費します。setup_consumers テーブルは、イベント情報を送信できるコンシューマの種類とそれらが有効にされているかどうかを一覧表示します。

    mysql> SELECT * FROM setup_consumers;+--------------------------------+---------+
    | NAME | ENABLED |
    +--------------------------------+---------+
    | events_stages_current | NO |
    | events_stages_history | NO |
    | events_stages_history_long | NO |
    | events_statements_current | YES |
    | events_statements_history | NO |
    | events_statements_history_long | NO |
    | events_waits_current | NO |
    | events_waits_history | NO |
    | events_waits_history_long | NO |
    | global_instrumentation | YES |
    | thread_instrumentation | YES |
    | statements_digest | YES |
    +--------------------------------+---------+

フィルタリングはパフォーマンスモニタリングのさまざまなステージで実行できます。

  • 事前フィルタリング。これは、プロデューサから特定の種類のイベントのみが収集され、収集されたイベントが特定のコンシューマのみを更新するように、パフォーマンススキーマ構成を変更することによって行われます。これを実行するには、インストゥルメントまたはコンシューマを有効または無効にします。事前フィルタリングは、パフォーマンススキーマによって行われ、すべてのユーザーに適用されるグローバルな効果を持ちます。

    事前フィルタリングを使用する理由:

    • オーバーヘッドを削減するため。パフォーマンススキーマのオーバーヘッドは、すべてのインストゥルメントを有効にしていても最小であるはずですが、さらに縮小したいと考える可能性があります。または、タイミングイベントに関心がなく、タイミングオーバーヘッドを解消するために、タイミングコードを無効にしたいと考えます。

    • 関心のないイベントの現在のイベントまたは履歴テーブルへの入力を妨げるため。事前フィルタリングにより、これらのテーブル内に、有効なインストゥルメントの種類の行のインスタンス用に多くの空きを残します。事前フィルタリングでファイルインストゥルメントのみを有効にしている場合、非ファイルインストゥルメントの行は収集されません。事後フィルタリングで、非ファイルイベントが収集され、ファイルイベントの少ない行が残されます。

    • 特定の種類のイベントテーブルの保守を回避するため。コンシューマを無効にすると、サーバーはそのコンシューマの宛先の保守に時間を費やさなくなります。たとえば、イベント履歴に関心がない場合、履歴テーブルコンシューマを無効にして、パフォーマンスを向上できます。

  • 事後フィルタリング。これには、クエリー内で、パフォーマンススキーマテーブルから情報を選択する WHERE 句を使用して、使用可能なイベントのうち表示したいものを指定することが含まれます。事後フィルタリングは、各ユーザーが使用可能なイベントのうち関心のあるものを選択するため、ユーザー単位で実行されます。

    事後フィルタリングを使用する理由:

    • 関心のあるイベント情報に関して、個々のユーザーの決断を避けるため。

    • 事前フィルタリングの使用に課せられる制限が前もってわからない場合に、パフォーマンススキーマを使用して、パフォーマンスの問題を調査するため。

次のセクションでは、事前フィルタリングの詳細を説明し、フィルタリング操作でインストゥルメントやコンシューマを指定するためのガイドラインを提供します。情報を取得するためのクエリーの書き方 (事後フィルタリング) については、セクション22.3「パフォーマンススキーマクエリー」を参照してください。

22.2.3.3 イベントの事前フィルタリング

事前フィルタリングは、パフォーマンススキーマによって行われ、すべてのユーザーに適用されるグローバルな効果を持ちます。事前フィルタリングは、イベント処理のプロデューサまたはコンシューマステージに適用できます。

  • プロデューサステージで事前フィルタリングを構成するには、いくつかのテーブルを使用できます。

    • setup_instruments は使用可能なインストゥルメントを示します。このテーブルで無効にされているインストゥルメントは、ほかの生成関連セットアップテーブルの内容に関係なく、イベントを生成しません。このテーブルで有効にされているインストゥルメントは、イベントの生成が許可され、ほかのテーブルの内容に依存します。

    • setup_objects は、パフォーマンススキーマが特定のテーブルオブジェクトをモニターするかどうかを制御します。

    • threads スレッドは各サーバースレッドでモニタリングが有効にされているかどうかを示します。

    • setup_actors は、新しいフォアグラウンドスレッドの初期モニタリング状態を決定します。

  • コンシューマステージで事前フィルタリングを構成するには、setup_consumers テーブルを変更します。これによって、イベントの送信先が決まります。setup_consumers はイベント生成にも暗黙的に影響します。特定のイベントがどの宛先にも送信されない (つまり消費されない) 場合、パフォーマンススキーマはそれを生成しません。

これらのいずれかのテーブルの変更は、setup_actors を除いて、ただちにモニタリングに影響します。setup_actors の変更は、変更後に作成されるフォアグラウンドスレッドにのみ影響します。

モニタリング構成を変更すると、パフォーマンススキーマは履歴テーブルをフラッシュしません。すでに収集されたイベントは、新しいイベントによって置き換えられるまで、現在のイベントと履歴テーブルに残ります。インストゥルメントを無効にする場合、それらのイベントが関心のある新しいイベントによって置き換えられるまで、しばらく待つ必要がある場合があります。または、TRUNCATE TABLE を使用して、履歴テーブルを空にします。

インストゥルメンテーションを変更したら、サマリーテーブルを切り捨てて、以前に収集されたイベントの集計情報をクリアする必要がある場合があります。events_statements_summary_by_digest を除き、サマリーテーブルの TRUNCATE TABLE の効果は、サマリーカラムを 0 または NULL にリセットすることで、行を削除することではありません。

次のセクションでは、特定のテーブルを使用して、パフォーマンススキーマの事前フィルタリングを制御する方法について説明します。

22.2.3.3.1 インストゥルメントによる事前フィルタリング

setup_instruments テーブルは使用可能なインストゥルメントを一覧表示します。

mysql> SELECT * FROM setup_instruments;+------------------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+------------------------------------------------------------+---------+-------+
...
| wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES |
| wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES |
| wait/synch/mutex/sql/LOCK_lock_db | YES | YES |
| wait/synch/mutex/sql/LOCK_manager | YES | YES |
...
| wait/synch/rwlock/sql/LOCK_grant | YES | YES |
| wait/synch/rwlock/sql/LOGGER::LOCK_logger | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_connect | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_slave | YES | YES |
...
| wait/io/file/sql/binlog | YES | YES |
| wait/io/file/sql/binlog_index | YES | YES |
| wait/io/file/sql/casetest | YES | YES |
| wait/io/file/sql/dbopt | YES | YES |
...

インストゥルメントを有効にするかどうかを制御するには、その ENABLED カラムを YES または NO に設定します。有効にされたインストゥルメントのタイミング情報を収集するかどうかを構成するには、その TIMED 値を YES または NO に設定します。TIMED カラムを設定すると、セクション22.2.3.1「パフォーマンススキーマイベントタイミング」に説明するように、パフォーマンススキーマテーブルの内容に影響します。

setup_instruments テーブルへの変更はただちにモニタリングに影響します。

setup_instruments テーブルはイベント生成のもっとも基本的な制御の形式を提供します。モニターされるオブジェクトやスレッドの種類に基づいて、イベント生成をさらに絞り込むには、セクション22.2.3.3「イベントの事前フィルタリング」に説明するように、ほかのテーブルを使用できます。

次の例に、setup_instruments テーブルへの可能な操作を示します。ほかの事前フィルタリング操作と同様に、これらの変更はすべてのユーザーに影響します。これらの一部のクエリーでは、LIKE 演算子とパターンマッチインストゥルメント名を使用しています。インストゥルメントを選択するためのパターンの指定に関する追加情報については、セクション22.2.3.4「フィルタリング操作のインストゥルメントまたはコンシューマの指定」を参照してください。

  • すべてのインストゥルメントを無効にします。

    mysql> UPDATE setup_instruments SET ENABLED = 'NO';

    これでイベントが収集されなくなります。

  • すべてのインストゥルメントを無効にし、それらを現在の無効にされているインストゥルメントのセットに追加します。

    mysql> UPDATE setup_instruments SET ENABLED = 'NO' -> WHERE NAME LIKE 'wait/io/file/%';
  • ファイルインストゥルメントのみを無効にし、ほかのすべてのインストゥルメントを有効にします。

    mysql> UPDATE setup_instruments -> SET ENABLED = IF(NAME LIKE 'wait/io/file/%', 'NO', 'YES');
  • mysys ライブラリ内のインストゥルメントを除くすべてのインストゥルメントを有効にします。

    mysql> UPDATE setup_instruments -> SET ENABLED = CASE WHEN NAME LIKE '%/mysys/%' THEN 'YES' ELSE 'NO' END;
  • 特定のインストゥルメントを無効にします。

    mysql> UPDATE setup_instruments SET ENABLED = 'NO' -> WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';
  • インストゥルメントの状態を切り替えるには、その ENABLED 値を反転します。

    mysql> UPDATE setup_instruments -> SET ENABLED = IF(ENABLED = 'YES', 'NO', 'YES') -> WHERE NAME = 'wait/synch/mutex/mysys/TMPDIR_mutex';
  • すべてのイベントのタイミングを無効にします。

    mysql> UPDATE setup_instruments SET TIMED = 'NO';
22.2.3.3.2 オブジェクトによる事前フィルタリング

setup_objects テーブルは、パフォーマンススキーマが特定のテーブルオブジェクトをモニターするかどうかを制御します。初期 setup_objects の内容は次のように見えます。

mysql> SELECT * FROM setup_objects;+-------------+--------------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED |
+-------------+--------------------+-------------+---------+-------+
| TABLE | mysql | % | NO | NO |
| TABLE | performance_schema | % | NO | NO |
| TABLE | information_schema | % | NO | NO |
| TABLE | % | % | YES | YES |
+-------------+--------------------+-------------+---------+-------+

setup_objects テーブルへの変更はただちにオブジェクトモニタリングに影響します。

OBJECT_TYPE カラムは行が適用されるオブジェクトの種類を示します。TABLE フィルタリングはテーブル I/O イベント (wait/io/table/sql/handler インストゥルメント) およびテーブルロックイベント (wait/lock/table/sql/handler インストゥルメント) に影響します。

OBJECT_SCHEMA および OBJECT_NAME カラムにはリテラルのスキーマまたはテーブル名、または任意の名前に一致する '%' が格納されているべきです。

ENABLED カラムは一致するオブジェクトがモニターされているかどうかを示し、TIMED はタイミング情報を収集するかどうかを示します。

デフォルトのオブジェクト構成の効果は、mysqlINFORMATION_SCHEMA、および performance_schema データベースのテーブルを除くすべてのテーブルをインストゥルメントすることです。(INFORMATION_SCHEMA データベース内のテーブルは、setup_objects の内容に関係なくインストゥルメントされず、information_schema.% の行は単にこのデフォルトを明示します。)

パフォーマンススキーマは、setup_objects の一致をチェックする場合、まずより詳細な一致を見つけようとします。たとえば、テーブル db1.t1 では、'db1''t1'、次に 'db1''%'、次に '%''%' の一致を検索します。さまざまな一致する setup_objects 行はさまざまな ENABLED 値と TIMED 値を持つ可能性があるため、一致が発生する順序が重要です。

テーブル関連イベントの場合、パフォーマンススキーマは setup_objects の内容と setup_instruments を組み合わせて、インストゥルメントを有効にするかどうか、および有効にされているインストゥルメントの時間を測定するかどうかを判断します。

  • setup_objects 内の行に一致するテーブルでは、テーブルインストゥルメントは、setup_instrumentssetup_objects の両方で、ENABLEDYES である場合にのみイベントを生成します。

  • 両方の値が YES の場合にのみ、タイミング情報が収集されるように、2 つのテーブル内の TIMED 値が組み合わされます。

setup_objects には、db1db2、および db3 に適用される次の行が含まれるとします。

+-------------+---------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED |
+-------------+---------------+-------------+---------+-------+
| TABLE | db1 | t1 | YES | YES |
| TABLE | db1 | t2 | NO | NO |
| TABLE | db2 | % | YES | YES |
| TABLE | db3 | % | NO | NO |
| TABLE | % | % | YES | YES |
+-------------+---------------+-------------+---------+-------+

setup_instruments のテーブル関連インストゥルメントに NOENABLED 値がある場合、オブジェクトのイベントはモニターされません。ENABLED 値が YES の場合、イベントモニタリングは、関連 setup_objects 行内の ENABLED 値に従って行われます。

  • db1.t1 イベントはモニターされます

  • db1.t2 イベントはモニターされません

  • db2.t3 イベントはモニターされます

  • db3.t4 イベントはモニターされません

  • db4.t5 イベントはモニターされます

setup_instruments および setup_objects テーブルの TIMED カラムを組み合わせて、イベントタイミング情報を収集するかどうかを判断する場合も同様のロジックが当てはまります。

永続的テーブルと一時テーブルが同じ名前を持つ場合、setup_objects 行に対する照合が両方に対して同様に行われます。一方のテーブルのモニタリングを有効にして、他方を有効にしないことはできません。ただし、各テーブルは個別にインストゥルメントされます。

ENABLED カラムは MySQL 5.6.3 で追加されました。ENABLED カラムがない初期バージョンでは、setup_objects はテーブル内の一部の行に一致するオブジェクトのモニタリングを有効にするためにのみ使用されます。テーブルによるインストゥルメンテーションを明示的に無効にする方法はありません。

22.2.3.3.3 スレッドによる事前フィルタリング

threads テーブルは各サーバースレッドの行を格納します。各行は、スレッドに関する情報を格納し、それに対するモニタリングが有効にされているかどうかを示します。スレッドをモニターするパフォーマンススキーマの場合、これらのことが当てはまる必要があります。

  • setup_consumers テーブル内の thread_instrumentation コンシューマは YES である必要があります。

  • thread.INSTRUMENTED カラムは YES である必要があります。

  • setup_instruments テーブル内で有効にされているインストゥルメントから生成されたスレッドイベントに対してのみ、モニタリングが行われます。

threads テーブルの INSTRUMENTED カラムは各スレッドのモニタリング状態を示します。フォアグラウンドスレッド (クライアント接続の結果) では、初期 INSTRUMENTED 値は、スレッドに関連付けられているユーザーアカウントが setup_actors テーブル内のいずれかの行に一致するかどうかによって決定されます。バックグラウンドスレッドの場合、INSTRUMENTED はデフォルトで YES で、バックグラウンドスレッドに関連付けられたユーザーはないため、setup_actors は参照されません。どのスレッドでも、スレッドの有効期間の間にその INSTRUMENTED 値が変更されることがあります。

初期 setup_actors の内容は次のように見えます。

mysql> SELECT * FROM setup_actors;+------+------+------+
| HOST | USER | ROLE |
+------+------+------+
| % | % | % |
+------+------+------+

パフォーマンススキーマは HOST および USER カラムを使用し、新しい各フォアグラウンドスレッドと照合します。(ROLE は使用されません。)いずれかの行が一致した場合、スレッドの INSTRUMENTED 値は YES になり、それ以外の場合 NO になります。これにより、ホスト、ユーザー、またはホストとユーザーの組み合わせごとに、インストゥルメントが選択して適用されます。

HOST および USER カラムにはリテラルのホストまたはユーザー名、または任意の名前に一致する '%' が格納されているべきです。setup_actors テーブルには最初に HOSTUSER のどちらにも '%' を含む行が格納されるため、デフォルトで、モニタリングはすべての新しいフォアグラウンドスレッドに対して有効にされます。一部のフォアグラウンドスレッドにのみモニタリングを有効にするなど、限定された照合を実行するには、この行はいずれかの接続に一致するため、これを削除する必要があります。

次のように setup_actors を変更するとします。

DELETE FROM setup_actors;

現在 setup_actors は空であるため、着信接続に一致する可能性のある行はありません。したがって、パフォーマンススキーマは、新しいすべてのフォアグラウンドスレッドの INSTRUMENTED カラムを NO に設定します。

さらに setup_actors を変更するとします。

INSERT INTO setup_actors (HOST,USER,ROLE) VALUES('localhost','joe','%');
INSERT INTO setup_actors (HOST,USER,ROLE) VALUES('%','sam','%');

ここで、パフォーマンススキーマは、次のように新しい接続スレッドの INSTRUMENTED 値の設定方法を判断します。

  • joe がローカルホストから接続する場合、接続は最初に挿入された行に一致します。

  • joe がほかのすべてのホストから接続する場合、一致はありません。

  • sam が任意のホストから接続する場合、接続は 2 番目に挿入された行に一致します。

  • ほかのすべての接続の場合、一致はありません。

setup_actors テーブルへの変更は既存のスレッドに影響しません。

22.2.3.3.4 コンシューマによる事前フィルタリング

setup_consumers テーブルは使用可能なコンシューマの種類とどれが有効にされているかを一覧表示します。

mysql> SELECT * FROM setup_consumers;+--------------------------------+---------+
| NAME | ENABLED |
+--------------------------------+---------+
| events_stages_current | NO |
| events_stages_history | NO |
| events_stages_history_long | NO |
| events_statements_current | YES |
| events_statements_history | NO |
| events_statements_history_long | NO |
| events_waits_current | NO |
| events_waits_history | NO |
| events_waits_history_long | NO |
| global_instrumentation | YES |
| thread_instrumentation | YES |
| statements_digest | YES |
+--------------------------------+---------+

コンシューマステージで、事前フィルタリングに影響するように、setup_consumers テーブルを変更し、イベントの送信先を決定します。コンシューマを有効または無効にするには、その ENABLED 値を YES または NO に設定します。

setup_consumers テーブルへの変更はただちにモニタリングに影響します。

コンシューマを無効にすると、サーバーはそのコンシューマの宛先の保守に時間を費やさなくなります。たとえば、履歴イベント情報に関心がない場合、履歴コンシューマを無効にします。

mysql> UPDATE setup_consumers -> SET ENABLED = 'NO' WHERE NAME LIKE '%history%';

setup_consumers テーブル内のコンシューマ設定は、高いレベルから低いレベルまでの階層を形成します。次の原則が当てはまります。

  • パフォーマンススキーマがコンシューマをチェックし、コンシューマが有効にされていないかぎり、コンシューマに関連付けられている宛先はイベントを受信しません。

  • コンシューマは、それが依存するすべてのコンシューマ (ある場合) が有効にされている場合にのみチェックされます。

  • コンシューマがチェックされていない場合、またはチェックされているが無効にされている場合、それに依存するほかのコンシューマはチェックされません。

  • 依存コンシューマには独自の依存コンシューマがあることがあります。

  • イベントがどの宛先にも送信されない場合、パフォーマンススキーマはそれを生成しません。

次のリストに、使用可能なコンシューマ値を説明します。いくつかの代表的なコンシューマ構成とそれらのインストゥルメンテーションへの効果については、セクション22.2.3.3.5「コンシューマ構成の例」を参照してください。

グローバルおよびスレッドコンシューマ

  • global_instrumentation は最高レベルのコンシューマです。global_instrumentationNO の場合、それはグローバルインストゥルメンテーションを無効にします。ほかのすべての設定は低いレベルで、チェックされず、何が設定されているかは重要でありません。グローバルまたはスレッドごとに情報が保守されず、個々のイベントが現在のイベントまたはイベント履歴テーブルに収集されません。global_instrumentationYES の場合、パフォーマンススキーマはグローバル状態の情報を保守し、thread_instrumentation コンシューマもチェックします。

  • thread_instrumentationglobal_instrumentationYES の場合のみチェックされます。そうでなければ、thread_instrumentationNO の場合、スレッド固有のインストゥルメンテーションが無効になり、すべての低レベル設定が無視されます。スレッドごとに情報が保守されず、個々のイベントが現在のイベントまたはイベント履歴テーブルに収集されません。thread_instrumentationYES の場合、パフォーマンススキーマはスレッド固有の情報を保守し、events_xxx_current コンシューマもチェックします。

ステートメントダイジェストコンシューマ

このコンシューマは global_instrumentationYES である必要があり、そうでないとそれはチェックされません。ステートメントイベントコンシューマへの依存関係がないため、events_statements_current に統計を収集する必要なく、ダイジェストごとに統計を取得することができ、これはオーバーヘッドの点で有利です。逆に、ダイジェストなしで、events_statements_current で詳細ステートメントを取得できます (DIGEST および DIGEST_TEXT カラムは NULL になります)。

待機イベントコンシューマ

これらのコンシューマには global_instrumentationthread_instrumentation の両方が YES である必要があり、そうでないと、それらはチェックされません。チェックされた場合、それらは次のように動作します。

  • events_waits_currentNO の場合、events_waits_current テーブル内の個々の待機イベントの収集を無効にします。YES の場合、待機イベント収集を有効にし、パフォーマンススキーマは events_waits_history および events_waits_history_long コンシューマをチェックします。

  • events_waits_historyevent_waits_currentNO の場合にチェックされません。そうでない場合、NO または YESevents_waits_history 値は、events_waits_history テーブルへの待機イベントの収集を無効または有効にします。

  • events_waits_history_longevent_waits_currentNO の場合にチェックされません。そうでない場合、NO または YESevents_waits_history_long 値は、events_waits_history_long テーブルへの待機イベントの収集を無効または有効にします。

ステージイベントコンシューマ

これらのコンシューマには global_instrumentationthread_instrumentation の両方が YES である必要があり、そうでないと、それらはチェックされません。チェックされた場合、それらは次のように動作します。

  • events_stages_currentは、NO の場合に、events_stages_current テーブルへの個々のステージイベントの収集を無効にします。YES の場合、ステージイベント収集を有効にし、パフォーマンススキーマは events_stages_history および events_stages_history_long コンシューマをチェックします。

  • events_stages_historyevent_stages_currentNO の場合にチェックされません。そうでない場合、NO または YESevents_stages_history 値は、events_stages_history テーブルへのステージイベントの収集を無効または有効にします。

  • events_stages_history_longevent_stages_currentNO の場合にチェックされません。そうでない場合、NO または YESevents_stages_history_long 値は、events_stages_history_long テーブルへのステージイベントの収集を無効または有効にします。

ステートメントイベントコンシューマ

これらのコンシューマには global_instrumentationthread_instrumentation の両方が YES である必要があり、そうでないと、それらはチェックされません。チェックされた場合、それらは次のように動作します。

  • events_statements_currentNO の場合、events_statements_current テーブルへの個々のステートメントイベントの収集を無効にします。YES の場合、ステートメントイベント収集を有効にし、パフォーマンススキーマは events_statements_history および events_statements_history_long コンシューマをチェックします。

  • events_statements_historyevents_statements_currentNO の場合にチェックされません。そうでない場合、NO または YESevents_statements_history 値は、events_statements_history テーブルへのステートメントイベントの収集を無効または有効にします。

  • events_statements_history_longevents_statements_currentNO の場合にチェックされません。そうでない場合、NO または YESevents_statements_history_long 値は、events_statements_history_long テーブルへのステートメントイベントの収集を無効または有効にします。

22.2.3.3.5 コンシューマ構成の例

setup_consumers テーブル内のコンシューマ設定は、高いレベルから低いレベルまでの階層を形成します。次の説明では、コンシューマのしくみを説明し、コンシューマ設定が高から低に段階に有効にされたときの特定の構成とそれらの効果を示します。示されているコンシューマ値は代表的なものです。ここで説明する一般原則は、使用可能なほかのコンシューマ値に当てはまります。

構成の説明は、機能とオーバーヘッドが増加する順番で示しています。低レベルの設定を有効にして提供される情報が必要でない場合は、それらを無効にすると、パフォーマンススキーマがユーザーのために実行するコードが少なくなり、ユーザーが取捨選択する情報が少なくなります。

setup_consumers テーブルには次の値の階層が格納されます。

global_instrumentation thread_instrumentation events_waits_current events_waits_history events_waits_history_long events_stages_current events_stages_history events_stages_history_long events_statements_current events_statements_history events_statements_history_long statements_digest
注記

コンシューマ階層で、待機、ステージ、およびステートメントのコンシューマはすべて同じレベルになります。これは、待機イベントがステージイベント内にネストし、ステージイベントがステートメントイベント内にネストするイベントネスト階層とは異なります。

特定のコンシューマ設定が NO の場合、パフォーマンススキーマはコンシューマに関連付けられたインストゥルメンテーションを無効にし、すべての低レベルの設定を無視します。特定の設定が YES の場合、パフォーマンススキーマはそれに関連付けられたインストゥルメンテーションを有効にし、次の最低レベルの設定をチェックします。各コンシューマのルールの説明については、セクション22.2.3.3.4「コンシューマによる事前フィルタリング」を参照してください。

たとえば、global_instrumentation が有効にされている場合、thread_instrumentation がチェックされます。thread_instrumentation が有効にされている場合、events_xxx_current コンシューマがチェックされます。これらのうち events_waits_current が有効にされている場合、events_waits_history および events_waits_history_long がチェックされます。

次の構成の各説明は、パフォーマンススキーマがチェックするセットアップ要素と、それが保守する出力テーブル (つまり、それが情報を収集するテーブル) を示します。

インストゥルメンテーションなし

サーバー構成の状態:

mysql> SELECT * FROM setup_consumers;+---------------------------+---------+
| NAME | ENABLED |
+---------------------------+---------+
| global_instrumentation | NO |
...
+---------------------------+---------+

この構成では、何もインストゥルメントされません。

チェックされるセットアップ要素:

  • テーブル setup_consumers、コンシューマ global_instrumentation

保守される出力テーブル:

  • なし

グローバルインストゥルメンテーションのみ

サーバー構成の状態:

mysql> SELECT * FROM setup_consumers;+---------------------------+---------+
| NAME | ENABLED |
+---------------------------+---------+
| global_instrumentation | YES |
| thread_instrumentation | NO |
...
+---------------------------+---------+

この構成では、インストゥルメンテーションがグローバル状態に対してのみ保守されます。スレッドごとのインストゥルメンテーションは無効にされます。

先述の構成に関連して、チェックされる追加のセットアップ要素:

  • テーブル setup_consumers、コンシューマ thread_instrumentation

  • テーブル setup_instruments

  • テーブル setup_objects

  • テーブル setup_timers

先述の構成に関連して保守される追加の出力テーブル:

  • mutex_instances

  • rwlock_instances

  • cond_instances

  • file_instances

  • users

  • hosts

  • accounts

  • socket_summary_by_event_name

  • file_summary_by_instance

  • file_summary_by_event_name

  • objects_summary_global_by_type

  • table_lock_waits_summary_by_table

  • table_io_waits_summary_by_index_usage

  • table_io_waits_summary_by_table

  • events_waits_summary_by_instance

  • events_waits_summary_global_by_event_name

  • events_stages_summary_global_by_event_name

  • events_statements_summary_global_by_event_name

グローバルおよびスレッドインストゥルメンテーションのみ

サーバー構成の状態:

mysql> SELECT * FROM setup_consumers;+--------------------------------+---------+
| NAME | ENABLED |
+--------------------------------+---------+
| global_instrumentation | YES |
| thread_instrumentation | YES |
| events_waits_current | NO |
...
| events_stages_current | NO |
...
| events_statements_current | YES |
...
+--------------------------------+---------+

この構成では、インストゥルメンテーションがグローバルおよびスレッドごとに保守されます。現在のイベントまたはイベント履歴テーブルで、個々のイベントは収集されません。

先述の構成に関連して、チェックされる追加のセットアップ要素:

  • テーブル setup_consumers、コンシューマ events_xxx_current。ここで xxxwaitsstagesstatements です

  • テーブル setup_actors

  • カラム threads.instrumented

先述の構成に関連して保守される追加の出力テーブル:

  • events_xxx_summary_by_yyy_by_event_name。ここで xxxwaitsstagesstatements で、および yyythreaduserhostaccount です

グローバル、スレッド、および現在のイベントインストゥルメンテーション

サーバー構成の状態:

mysql> SELECT * FROM setup_consumers;+--------------------------------+---------+
| NAME | ENABLED |
+--------------------------------+---------+
| global_instrumentation | YES |
| thread_instrumentation | YES |
| events_waits_current | YES |
| events_waits_history | NO |
| events_waits_history_long | NO |
| events_stages_current | YES |
| events_stages_history | NO |
| events_stages_history_long | NO |
| events_statements_current | YES |
| events_statements_history | NO |
| events_statements_history_long | NO |
...
+--------------------------------+---------+

この構成では、インストゥルメンテーションがグローバルおよびスレッドごとに保守されます。個々のイベントが現在のイベントテーブルに収集されますが、イベント履歴テーブルには収集されません。

先述の構成に関連して、チェックされる追加のセットアップ要素:

  • コンシューマ events_xxx_history。ここで xxxwaitsstagesstatements です

  • コンシューマ events_xxx_history_long。ここで xxxwaitsstagesstatements です

先述の構成に関連して保守される追加の出力テーブル:

  • events_xxx_current。ここで xxxwaitsstagesstatements です

グローバル、スレッド、現在のイベント、およびイベント履歴インストゥルメンテーション

events_xxx_history および events_xxx_history_long コンシューマは無効にされているため、先述の構成はイベント履歴を収集しません。それらのコンシューマは個別またはまとめて有効にして、スレッドごと、グローバルに、またはその両方でイベント履歴を収集できます。

この構成はスレッドごとにイベントを収集しますが、グローバルには収集しません。

mysql> SELECT * FROM setup_consumers;+--------------------------------+---------+
| NAME | ENABLED |
+--------------------------------+---------+
| global_instrumentation | YES |
| thread_instrumentation | YES |
| events_waits_current | YES |
| events_waits_history | YES |
| events_waits_history_long | NO |
| events_stages_current | YES |
| events_stages_history | YES |
| events_stages_history_long | NO |
| events_statements_current | YES |
| events_statements_history | YES |
| events_statements_history_long | NO |
...
+--------------------------------+---------+

この構成で保守されるイベント履歴テーブル:

  • events_xxx_history。ここで xxxwaitsstagesstatements です

この構成はグローバルにイベント履歴を収集しますが、スレッドごとには収集しません。

mysql> SELECT * FROM setup_consumers;+--------------------------------+---------+
| NAME | ENABLED |
+--------------------------------+---------+
| global_instrumentation | YES |
| thread_instrumentation | YES |
| events_waits_current | YES |
| events_waits_history | NO |
| events_waits_history_long | YES |
| events_stages_current | YES |
| events_stages_history | NO |
| events_stages_history_long | YES |
| events_statements_current | YES |
| events_statements_history | NO |
| events_statements_history_long | YES |
...
+--------------------------------+---------+

この構成で保守されるイベント履歴テーブル:

  • events_xxx_history_long。ここで xxxwaitsstagesstatements です

この構成はスレッドごとおよびグローバルにイベントを収集します。

mysql> SELECT * FROM setup_consumers;+--------------------------------+---------+
| NAME | ENABLED |
+--------------------------------+---------+
| global_instrumentation | YES |
| thread_instrumentation | YES |
| events_waits_current | YES |
| events_waits_history | YES |
| events_waits_history_long | YES |
| events_stages_current | YES |
| events_stages_history | YES |
| events_stages_history_long | YES |
| events_statements_current | YES |
| events_statements_history | YES |
| events_statements_history_long | YES |
...
+--------------------------------+---------+

この構成で保守されるイベント履歴テーブル:

  • events_xxx_history。ここで xxxwaitsstagesstatements です

  • events_xxx_history_long。ここで xxxwaitsstagesstatements です

22.2.3.4 フィルタリング操作のインストゥルメントまたはコンシューマの指定

フィルタリング操作に指定する名前は、必要に応じて具体的なものでも一般的なものでも指定できます。単一のインストゥルメントまたはコンシューマを示すには、その名前を省略せずに指定します。

mysql> UPDATE setup_instruments -> SET ENABLED = 'NO' -> WHERE NAME = 'wait/synch/mutex/myisammrg/MYRG_INFO::mutex';mysql> UPDATE setup_consumers -> SET ENABLED = 'NO' WHERE NAME = 'events_waits_current';

インストゥルメントまたはコンシューマのグループを指定するには、グループメンバーに一致するパターンを使用します。

mysql> UPDATE setup_instruments -> SET ENABLED = 'NO' -> WHERE NAME LIKE 'wait/synch/mutex/%';mysql> UPDATE setup_consumers -> SET ENABLED = 'NO' WHERE NAME LIKE '%history%';

パターンを使用する場合、それは関心のあるすべての項目に一致し、ほかの項目に一致しないように、選択してください。たとえば、すべてのファイル I/O インストゥルメントを選択するには、インストゥルメント名プリフィクス全体を含むパターンを使用することをお勧めします。

... WHERE NAME LIKE 'wait/io/file/%';

'%/file/%' のパターンは、名前の任意の位置に '/file/' のコンポーネントがあるほかのインストゥルメントに一致します。パターン '%file%'wait/synch/mutex/sql/LOCK_des_key_file など、名前の任意の位置に 'file' のあるインストゥルメントに一致するため、あまり適切ではありません。

パターンに一致するインストゥルメントまたはコンシューマ名をチェックするには、簡単なテストを実行します。

mysql> SELECT NAME FROM setup_instruments WHERE NAME LIKE 'pattern';mysql> SELECT NAME FROM setup_consumers WHERE NAME LIKE 'pattern';

サポートされる名前の種類については、セクション22.4「パフォーマンススキーマインストゥルメント命名規則」を参照してください。

22.2.3.5 インストゥルメントされているものの特定

パフォーマンススキーマにどのインストゥルメントが含まれているかを特定するには、常に setup_instruments テーブルをチェックすることで可能です。たとえば、InnoDB ストレージエンジンに、どのファイル関連イベントがインストゥルメントされているかを確認するには、次のクエリーを使用します。

mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'wait/io/file/innodb/%';+--------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+--------------------------------------+---------+-------+
| wait/io/file/innodb/innodb_data_file | YES | YES |
| wait/io/file/innodb/innodb_log_file | YES | YES |
| wait/io/file/innodb/innodb_temp_file | YES | YES |
+--------------------------------------+---------+-------+

このドキュメントでは、いくつかの理由で、正確に何がインストゥルメントされるかについて詳細に説明していません。

  • 何がインストゥルメントされるかは、サーバーコードです。このコードへの変更は頻繁に行われ、インストゥルメントのセットにも影響します。

  • すべてのインストゥルメントは数百もあるため、それらを挙げることは現実的ではありません。

  • 先述のように、setup_instruments テーブルをクエリーすることによって見つけることができます。この情報は使用している MySQL のバージョンに常に最新であり、コアサーバーに含まれておらず、自動化されたツールで使用可能な、インストールしている可能性があるインストゥルメント済みのプラグインのインストゥルメンテーションも含みます。

22.3 パフォーマンススキーマクエリー

事前フィルタリングは収集されるイベント情報を制限し、特定のユーザーと関係ありません。対照的に、事後フィルタリングは、各ユーザーが、事前フィルタリングの適用後に使用可能なイベントから選択するイベント情報を制限する、適切な WHERE 句でクエリーを使用することによって実行されます。

セクション22.2.3.3「イベントの事前フィルタリング」で、ファイルインストゥルメントの事前フィルタリング方法の例を示しました。イベントテーブルにファイルと非ファイルの両方の情報が格納されている場合、事後フィルタリングはファイルイベントのみの情報を表示するもう 1 つの方法です。イベント選択を適切に制限するには、クエリーに WHERE 句を追加します。

mysql> SELECT THREAD_ID, NUMBER_OF_BYTES -> FROM events_waits_history -> WHERE EVENT_NAME LIKE 'wait/io/file/%' -> AND NUMBER_OF_BYTES IS NOT NULL;+-----------+-----------------+
| THREAD_ID | NUMBER_OF_BYTES |
+-----------+-----------------+
| 11 | 66 |
| 11 | 47 |
| 11 | 139 |
| 5 | 24 |
| 5 | 834 |
+-----------+-----------------+

22.4 パフォーマンススキーマインストゥルメント命名規則

インストゥルメント名は '/' 文字で区切られた一連のコンポーネントから構成されます。名前の例:

wait/io/file/myisam/log
wait/io/file/mysys/charset
wait/lock/table/sql/handler
wait/synch/cond/mysys/COND_alarm
wait/synch/cond/sql/BINLOG::update_cond
wait/synch/mutex/mysys/BITMAP_mutex
wait/synch/mutex/sql/LOCK_delete
wait/synch/rwlock/sql/Query_cache_query::lock
stage/sql/closing tables
stage/sql/Sorting result
statement/com/Execute
statement/com/Query
statement/sql/create_table
statement/sql/lock_tables

インストゥルメントの名前空間はツリー状の構造を持ちます。インストゥルメント名のコンポーネントは左から右に、より一般的からより具体的に進みます。名前のコンポーネント数はインストゥルメントの種類によって異なります。

名前の特定のコンポーネントの解釈は、その左側のコンポーネントによって異なります。たとえば、myisam は次の名前の両方に見られますが、最初の名前の myisam はファイル I/O に関連し、2 番目のそれは同期インストゥルメントに関連しています。

wait/io/file/myisam/log
wait/synch/cond/myisam/MI_SORT_INFO::cond

インストゥルメント名は、パフォーマンススキーマ実装によって定義された構造を持つプリフィクスと、インストゥルメントコードを実装する開発者によって定義されるサフィクスから構成されます。インストゥルメントプリフィクスのトップレベルコンポーネントはインストゥルメントの種類を示します。このコンポーネントによって、インストゥルメントに適用される setup_timers テーブル内のイベントタイマーも決まります。インストゥルメントのプリフィクス部分のトップレベルはインストゥルメントの種類を示します。

インストゥルメント名のサフィクス部分は、インストゥルメント自体のコードから生成されます。サフィクスには次のようなレベルが含まれることがあります。

  • 主要コンポーネントの名前 (myisaminnodbmysys、または sql などのサーバーモジュール) またはプラグイン名。

  • 形式 XXX (グローバル変数) または CCC::MMM (クラス CCC のメンバー MMM) でのコード内の変数の名前。例: COND_thread_cacheTHR_LOCK_myisamBINLOG::LOCK_index

トップレベルインストゥルメントコンポーネント

  • idle: インストゥルメントされたアイドルイベント。このインストゥルメントにはそれ以上のコンポーネントがありません。

  • stage: インストゥルメントされたステージイベント。

  • statement: インストゥルメントされたステートメントイベント。

  • wait: インストゥルメントされた待機イベント。

アイドルインストゥルメントコンポーネント

ステージインストゥルメントコンポーネント

ステージインストゥルメントは、形式 stage/code_area/stage_name の名前を持ちます。ここで code_areasqlmyisam などの名前で、stage_name は、Sorting resultSending data などのステートメント処理のステージを示します。ステージは SHOW PROCESSLIST によって表示されるか、または INFORMATION_SCHEMA.PROCESSLIST テーブルに表示されるスレッドの状態に対応します。

ステートメントインストゥルメントコンポーネント

  • statement/abstract/*: ステートメント操作の抽象インストゥルメント。抽象インストゥルメントは、正確なステートメントの種類が分かる前のステートメント分類の初期段階時に使用され、その後種類がわかったときに、より具体的なステートメントインストゥルメントに変更されます。このプロセスの説明については、セクション22.9.6「パフォーマンススキーマステートメントイベントテーブル」を参照してください。

  • statement/com: インストゥルメントされたコマンド操作。これらは COM_xxx 操作に対応する名前を持ちます (mysql_com.h ヘッダーファイルおよび sql/sql_parse.cc を参照してください。たとえば、statement/com/Connect および statement/com/Init DB インストゥルメントは COM_CONNECT および COM_INIT_DB コマンドに対応します。

  • statement/sql: インストゥルメントされた SQL ステートメント操作。たとえば、statement/sql/create_db および statement/sql/select インストゥルメントは CREATE DATABASE および SELECT ステートメントに使用されます。

待機インストゥルメントコンポーネント

  • wait/io

    インストゥルメントされた I/O 操作。

    • wait/io/file

      インストゥルメントされたファイル I/O 操作。ファイルの場合、待機はファイル操作の完了 (たとえば、fwrite() の呼び出し) を待機する時間です。キャッシュのため、この呼び出し内で、ディスクへの物理的なファイル I/O は行われない可能性があります。

    • wait/io/socket

      インストゥルメントされたソケット操作。ソケットインストゥルメントは形式 wait/io/socket/sql/socket_type の名前を持ちます。サーバーには、それがサポートする各ネットワークプロトコルの待機ソケットがあります。TCP/IP または Unix ソケットファイル接続の待機ソケットに関連付けられているインストゥルメントは、それぞれ server_tcpip_socket または server_unix_socketsocket_type 値を持ちます。待機ソケットが接続を検出すると、サーバーは接続を、個別のスレッドによって管理される新しいソケットに転送します。新しい接続スレッドのインストゥルメントは、client_connectionsocket_type 値を持ちます。

    • wait/io/table

      インストゥルメントされたテーブル I/O 操作。これらには、永続的ベーステーブルまたは一時テーブルへの行レベルアクセスが含まれます。行に影響する操作は、フェッチ、挿入、更新、および削除です。ビューの場合、待機はビューによって参照されるベーステーブルに関連付けられます。

      ほとんどの待機と同様、テーブル I/O の待機にはほかの待機も含まれることがあります。たとえば、テーブル I/O にはファイル I/O またはメモリー操作が含まれることがあります。そのため、テーブル I/O 待機の events_waits_current には通常 2 行あります。詳細については、セクション22.6「パフォーマンススキーマの原子的および分子的イベント」を参照してください。

      一部の行操作では、複数のテーブル I/O 待機が発生することがあります。たとえば、挿入は更新を発生させるトリガーをアクティブにすることがあります。

  • wait/lock

    インストゥルメントされたロック操作。

    • wait/lock/table

      インストゥルメントされたテーブルロック操作。

  • wait/synch

    インストゥルメントされた同期オブジェクト。同期オブジェクトでは、TIMER_WAIT 時間には、オブジェクトへのロックがある場合に、その獲得を試みている間のブロックされる時間の量が含まれます。

    • wait/synch/cond

      条件は、1 つのスレッドによって、ほかのスレッドに、それらが待機している何かが発生したことを伝えるために使用されます。単一のスレッドが条件を待機していた場合、それはウェイクアップし、その実行を再開できます。複数のスレッドが待機していた場合、それらすべてがウェイクアップし、それらが待機していたリソースを奪い合うことがあります。

    • wait/synch/mutex

      ほかのスレッドのリソースへのアクセスを妨げながら、リソース (実行可能コードのセクションなど) へのアクセスを許可するために使用される相互排他オブジェクト。

    • wait/synch/rwlock

      ほかのスレッドによるその使用を妨げながら、特定の変数のアクセスをロックするために使用される読み取り/書き込みロックオブジェクト。共有読み取りロックは複数のスレッドによって同時に獲得できます。排他的書き込みロックは、一度に 1 つのスレッドだけが獲得できます。

22.5 パフォーマンススキーマステータスモニタリング

パフォーマンススキーマに関連付けられたいくつかのステータス変数があります。

mysql> SHOW STATUS LIKE 'perf%';+-----------------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------------+-------+
| Performance_schema_accounts_lost | 0 |
| Performance_schema_cond_classes_lost | 0 |
| Performance_schema_cond_instances_lost | 0 |
| Performance_schema_digest_lost | 0 |
| Performance_schema_file_classes_lost | 0 |
| Performance_schema_file_handles_lost | 0 |
| Performance_schema_file_instances_lost | 0 |
| Performance_schema_hosts_lost | 0 |
| Performance_schema_locker_lost | 0 |
| Performance_schema_mutex_classes_lost | 0 |
| Performance_schema_mutex_instances_lost | 0 |
| Performance_schema_rwlock_classes_lost | 0 |
| Performance_schema_rwlock_instances_lost | 0 |
| Performance_schema_session_connect_attrs_lost | 0 |
| Performance_schema_socket_classes_lost | 0 |
| Performance_schema_socket_instances_lost | 0 |
| Performance_schema_stage_classes_lost | 0 |
| Performance_schema_statement_classes_lost | 0 |
| Performance_schema_table_handles_lost | 0 |
| Performance_schema_table_instances_lost | 0 |
| Performance_schema_thread_classes_lost | 0 |
| Performance_schema_thread_instances_lost | 0 |
| Performance_schema_users_lost | 0 |
+-----------------------------------------------+-------+

パフォーマンススキーマステータス変数は、メモリー制約のためロードまたは作成できなかったインストゥルメンテーションに関する情報を提供します。これらの変数の名前にはいくつかの形式があります。

  • Performance_schema_xxx_classes_lost は、種類 xxx のロードできなかったインストゥルメントの数を示します。

  • Performance_schema_xxx_instances_lost は、オブジェクトの種類 xxx の作成できなかったインストゥルメントの数を示します。

  • Performance_schema_xxx_handles_lost は、オブジェクトの種類 xxx のオープンできなかったインストゥルメントの数を示します。

  • Performance_schema_locker_lost は、失われたか、または記録されなかったイベント数を示します。

たとえば、相互排他ロックがサーバーソースにインストゥルメントされているが、サーバーが実行時にインストゥルメンテーション用のメモリーを割り当てることができない場合、それは Performance_schema_mutex_classes_lost を増分します。相互排他ロックは、まだ同期オブジェクトとして機能します (つまり、サーバーは正常に機能し続けます) が、そのパフォーマンスデータは収集されません。インストゥルメントを割り当てることができる場合、それはインストゥルメントされた相互排他ロックインスタンスの初期化に使用できます。グローバル相互排他ロックなどのシングルトン相互排他ロックの場合、1 つのインスタンスだけが存在します。その他の相互排他ロックは、接続あたり、または各種キャッシュおよびデータバッファー内のページあたりに 1 つのインスタンスを持つため、インスタンスの数は時間の経過とともに変わります。接続の最大数または一部のバッファーの最大サイズを増やすと、一度に割り当てることができるインスタンスの最大数が増えます。サーバーが特定のインストゥルメントされた相互排他ロックインスタンスを作成できない場合、それは Performance_schema_mutex_instances_lost を増分します。

次の条件が維持されているとします。

  • サーバーは --performance_schema_max_mutex_classes=200 オプションを使用して起動されているため、200 相互排他ロックインストゥルメントのための空きがあります。

  • 150 相互排他ロックインストゥルメントはすでにロードされています。

  • plugin_a という名前のプラグインには 40 相互排他ロックインストゥルメントが含まれます。

  • plugin_b という名前のプラグインには 20 相互排他ロックインストゥルメントが含まれます。

サーバーは、次の一連のステートメントに示すように、プラグインに、それらが必要とする数と使用可能な数に応じて、相互排他ロックインストゥルメントを割り当てます。

INSTALL PLUGIN plugin_a

現在サーバーには 150+40 = 190 相互排他ロックインストゥルメントがあります。

UNINSTALL PLUGIN plugin_a;

サーバーにはまだ 190 インストゥルメントがあります。プラグインコードによって生成されたすべての履歴データはまだ使用できますが、インストゥルメントの新しいイベントは収集されません。

INSTALL PLUGIN plugin_a;

サーバーは 40 インストゥルメントがすでに定義されていることを検出したため、新しいインストゥルメントが作成されず、以前に割り当てられた内部メモリーバッファーが再利用されます。サーバーにはまだ 190 インストゥルメントがあります。

INSTALL PLUGIN plugin_b;

サーバーは 200-190 = 10 インストゥルメント (この例では、相互排他ロッククラス) の空きがあり、プラグインに 20 個の新しいインストゥルメントが含まれていることを認識します。10 個のインストゥルメントがロードされ、10 個は破棄されるか失われます。Performance_schema_mutex_classes_lost は失われたインストゥルメント (相互排他ロッククラス) の数を示します。

mysql> SHOW STATUS LIKE "perf%mutex_classes_lost";+---------------------------------------+-------+
| Variable_name | Value |
+---------------------------------------+-------+
| Performance_schema_mutex_classes_lost | 10 |
+---------------------------------------+-------+
1 row in set (0.10 sec)

インストゥルメンテーションはまだ機能し、plugin_b の (部分) データを収集します。

サーバーが相互排他ロックインストゥルメントを作成できないと、次の結果が発生します。

  • インストゥルメントの行が setup_instruments テーブルに挿入されません。

  • Performance_schema_mutex_classes_lost が 1 増加します。

  • Performance_schema_mutex_instances_lost は変更されません。(相互排他ロックインストゥルメントが作成されない場合、あとでインストゥルメントされた相互排他ロックインスタンスの作成にそれを使用できません。)

先述のパターンは相互排他ロックだけでなく、すべての種類のインストゥルメントに当てはまります。

0 より大きい Performance_schema_mutex_classes_lost の値は 2 つのケースで発生する可能性があります。

  • 数バイトのメモリーを節約するには、サーバーを --performance_schema_max_mutex_classes=N で起動します。ここで N はデフォルト値未満です。デフォルト値を選択すれば、MySQL 配布で提供されるすべてのプラグインをロードするために十分ですが、一部のプラグインをロードしない場合にこれを減らすことができます。たとえば、配布内の一部のストレージエンジンをロードしないように選択できます。

  • パフォーマンススキーマ用にインストゥルメントされたサードパーティープラグインをロードしますが、サーバーの起動時に、プラグインのインストゥルメンテーションメモリー要件を考慮しません。それはサードパーティー製であるため、このエンジンのインストゥルメントメモリー消費は performance_schema_max_mutex_classes で選択されたデフォルト値で考慮されていません。

    サーバーにプラグインのインストゥルメント用の十分なリソースがなく、ユーザーが --performance_schema_max_mutex_classes=N を使用して、明示的に多く割り当てていない場合、このプラグインをロードすると、インストゥルメントが不足します。

performance_schema_max_mutex_classes に選択されている値が小さすぎる場合、エラーログにエラーが報告されず、実行時に障害が発生しません。ただし、performance_schema データベース内のテーブルの内容にイベントが含まれません。Performance_schema_mutex_classes_lost ステータス変数は、インストゥルメントの作成の失敗のために、一部のイベントが内部で削除されたことを示す唯一の目に見えるしるしです。

インストゥルメントが失われていない場合、それはパフォーマンススキーマに認識され、インスタンスのインストゥルメント時に使用されます。たとえば、wait/synch/mutex/sql/LOCK_deletesetup_instruments テーブル内の相互排他ロックインストゥルメントの名前です。サーバーの実行時に相互排他ロックの多くのインスタンスが必要であっても、コード内 (THD::LOCK_delete 内) で相互排他ロックの作成時に、この単一のインストゥルメントが使用されます。この場合、LOCK_delete は接続 (THD) ごとの相互排他ロックであるため、サーバーに 1000 接続がある場合、1000 スレッドと 1000 個のインストゥルメントされた LOCK_delete 相互排他ロックインスタンス (THD::LOCK_delete) が存在します。

サーバーにこれらの 1000 個のインストゥルメントされた相互排他ロック (インスタンス) すべてのための空きがない場合、一部の相互排他ロックはインストゥルメンテーション付きで作成され、一部はインストゥルメンテーションなしで作成されます。サーバーが 800 インスタンスしか作成できない場合、200 インスタンスが失われます。サーバーは実行し続けますが、Performance_schema_mutex_instances_lost を 200 増分し、インスタンスを作成できなかったことを示します。

0 より大きい Performance_schema_mutex_instances_lost は、--performance_schema_max_mutex_instances=N で割り当てられたものより多くの相互排他ロックを、コードで実行時に初期化した場合に発生する可能性があります。

結論として、SHOW STATUS LIKE 'perf%' に何も失われていないことが示されている (すべての値がゼロ) 場合に、パフォーマンススキーマデータは正確で信頼できます。何かが失われた場合、データは不完全であり、使用するように与えられたメモリーの量が不十分であったとすると、パフォーマンススキーマはすべてを記録できていません。この場合、特定の Performance_schema_xxx_lost 変数に問題の領域が示されます。

場合によって、意図的にインストゥルメントの不足を発生させることが適切なことがあります。たとえば、ファイル I/O のパフォーマンスデータに関心がない場合は、ファイル I/O に関連するすべてのパフォーマンススキーマのパラメータを 0 に設定して、サーバーを起動できます。ファイル関連のクラス、インスタンス、またはハンドルにメモリーが割り当てられず、すべてのファイルイベントが失われます。

SHOW ENGINE PERFORMANCE_SCHEMA STATUS を使用して、パフォーマンススキーマコードの内部操作を検査します。

mysql> SHOW ENGINE PERFORMANCE_SCHEMA STATUS\G...
*************************** 3. row *************************** Type: performance_schema Name: events_waits_history.row_size
Status: 76
*************************** 4. row *************************** Type: performance_schema Name: events_waits_history.row_count
Status: 10000
*************************** 5. row *************************** Type: performance_schema Name: events_waits_history.memory
Status: 760000
...
*************************** 57. row *************************** Type: performance_schema Name: performance_schema.memory
Status: 26459600
...

このステートメントは、さまざまなパフォーマンススキーマオプションがメモリー要件に与える効果について、DBA が理解できるようにすることを目的としています。フィールドの意味の説明については、セクション13.7.5.16「SHOW ENGINE 構文」を参照してください。

22.6 パフォーマンススキーマの原子的および分子的イベント

テーブル I/O イベントの場合、events_waits_current には通常 1 行ではなく、2 行あります。たとえば、行フェッチにより、次のような行になる可能性があります。

Row# EVENT_NAME TIMER_START TIMER_END
---- ---------- ----------- --------- 1 wait/io/file/myisam/dfile 10001 10002 2 wait/io/table/sql/handler 10000 NULL

行フェッチによりファイルが読み取られます。例では、テーブル I/O フェッチイベントがファイル I/O イベントの前に起動していますが、終了していません (その TIMER_END 値が NULL です)。ファイル I/O イベントはテーブル I/O イベント内にネストされます。

これは、相互排他ロックやファイル I/O などのほかの原子的待機イベントと異なり、テーブル I/O イベントは分子的で、ほかのイベントを含んで (重複して) います。events_waits_current で、テーブル I/O イベントには通常 2 つの行があります。

  • 最新のテーブル I/O 待機イベントについての 1 行

  • 任意の種類の最新の待機イベントについての 1 行

通常、ただし常にではありませんが、どの種類の待機イベントもテーブル I/O イベントと異なります。各従属イベントが完了すると、それは events_waits_current から消去されます。この時点で、および次の従属イベントが開始されるまで、テーブル I/O 待機は、あらゆる種類の最新の待機でもあります。

22.7 パフォーマンススキーマステートメントダイジェスト

MySQL 5.6.5 現在、パフォーマンススキーマはステートメントダイジェスト情報を保守します。ダイジェストは、SQL ステートメントを正規化形式に変換し、結果のハッシュ値を計算します。正規化により、類似のステートメントがグループ化され、要約されて、サーバーが実行しているステートメントの種類とそれらが発生する頻度に関する情報が公開されます。このセクションでは、どのようにステートメントの正規化が行われ、どのように役立つ可能性があるかについて説明します。

ステートメントのダイジェストには、これらのパフォーマンススキーマコンポーネントが関係します。

  • setup_consumers テーブル内の statement_digest コンシューマは、パフォーマンススキーマがダイジェスト情報を保守するかどうかを制御します。

  • ステートメントイベントテーブル (events_statements_currentevents_statements_history、および events_statements_history_long) には、ダイジェスト MD5 値と対応する正規化されたステートメントテキスト文字列を格納する DIGEST および DIGEST_TEXT カラムがあります。

  • events_statements_summary_by_digest テーブルは集計されたステートメントダイジェスト情報を提供します。

ステートメントの正規化によって、ステートメントテキストは、一般的なステートメント構造を保持しながら、構造に不可欠でない情報を削除する、より標準化された文字列表現に変換されます。データベースまたはテーブル名などのオブジェクト識別子は保持されます。値とコメントは削除され、空白は調整されます。パフォーマンススキーマは、名前、パスワード、日付などの情報を保持しません。

これらのステートメントを考慮してください。

SELECT * FROM orders WHERE customer_id=10 AND quantity>20
SELECT * FROM orders WHERE customer_id = 20 AND quantity > 100

これらのステートメントを正規化するため、パフォーマンススキーマはデータ値を ? に置換し、空白を調整します。どちらのステートメントも同じ正規化形式になるため、同じとみなされます。

SELECT * FROM orders WHERE customer_id = ? AND quantity > ?

正規化されたステートメントは、格納される情報は少ないですが、引き続き元のステートメントを代表しています。さまざまな比較値を持つほかの類似のステートメントは同じ正規化形式になります。

ここで、これらのステートメントを考慮してください。

SELECT * FROM customers WHERE customer_id = 1000
SELECT * FROM orders WHERE customer_id = 1000

この場合、ステートメントは同じではありません。オブジェクト識別子が異なるため、ステートメントは異なる正規化形式になります。

SELECT * FROM customers WHERE customer_id = ?
SELECT * FROM orders WHERE customer_id = ?

正規化されたステートメントは固定長です。DIGEST_TEXT 値の最大長は 1024 バイトです。この最大を変更するオプションはありません。正規化によって、この長さを超えるステートメントが生成された場合、テキストは ... で終わります。... のあとの部分のみが異なる長いステートメントは同じとみなされます。これらのステートメントを考慮してください。

SELECT * FROM mytable WHERE cola = 10 AND colb = 20
SELECT * FROM mytable WHERE cola = 10 AND colc = 20

AND の直後にカットオフが発生した場合、両方のステートメントがこの正規化形式になります。

SELECT * FROM mytable WHERE cola = ? AND ...

この場合、2 つ目のカラム名の違いが失われ、両方のステートメントが同じとみなされます。

正規化された各ステートメントについて、パフォーマンススキーマはハッシュダイジェスト値を計算し、その値とステートメントをステートメントイベントテーブル (events_statements_currentevents_statements_history、および events_statements_history_long) の DIGEST および DIGEST_TEXT カラムに格納します。さらに、同じ SCHEMA_NAME および DIGEST 値を持つステートメントの情報が events_statements_summary_by_digest サマリーテーブルに集計されます。パフォーマンススキーマは MD5 ハッシュ値を使用します。それらは計算が速く、競合を最小にする望ましい統計的分布を持つためです。

events_statements_summary_by_digest サマリーテーブルは固定サイズであるため、それがいっぱいになると、テーブル内の既存の値に一致しない SCHEMA_NAME および DIGEST 値のあるステートメントは、SCHEMA_NAME および DIGESTNULL に設定された特別な行にグループ化されます。これにより、すべてのステートメントがカウントされます。ただし、特別な行が、実行されるステートメントの大きな割合を占める場合、サマリーテーブルのサイズを増やすことが望ましい可能性があります。これを実行するには、サーバーの起動時に、performance_schema_digests_size システム変数を大きな値に設定します。performance_schema_digests_size 値が指定されていない場合、サーバーは起動時に使用する値を推定します。(MySQL 5.6.9 より前では、SCHEMA_NAME カラム値がなく、特別な行の DIGESTNULL に設定されます。)

ステートメントダイジェストサマリーテーブルは、サーバーによって実行されるステートメントのプロファイルを提供します。それは、アプリケーションが実行しているステートメントの種類とその頻度を示します。アプリケーション開発者はこの情報をテーブル内のほかの情報と組み合わせて使用し、アプリケーションのパフォーマンス特性を査定できます。たとえば、待機時間、ロック時間、またはインデックスの使用を示すテーブルカラムは不十分なクエリーの種類を強調表示することができます。これにより、開発者が注意が必要なアプリケーションの部分を把握できます。

22.8 パフォーマンススキーマの一般的なテーブル特性

performance_schema データベースの名前は小文字で、その中のテーブルの名前も同様です。クエリーでは名前を小文字で指定してください。

performance_schema データベース内のほとんどのテーブルは読み取り専用で、変更できません。セットアップテーブルの一部には、パフォーマンススキーマ操作に影響するように変更できるカラムがあります。さらに行の挿入や削除を許可するものもあります。収集されたイベントをクリアするために切り捨てが許可されるため、events_waits_ のプリフィクスのある名前のテーブルなど、それらの種類の情報を格納するテーブルで、TRUNCATE TABLE を使用できます。

TRUNCATE TABLE は、events_statements_summary_by_digest を除くサマリーテーブルでも使用できますが、その効果は行の削除ではなく、サマリーカラムを 0 または NULL にリセットすることです。

ほかのデータベースやテーブルに対する権限は次のようになります。

  • performance_schema テーブルから取得するには、SELECT 権限が必要です。

  • 変更可能なそれらのカラムを変更するには、UPDATE 権限が必要です。

  • 切り捨て可能なテーブルを切り捨てるには、DROP 権限が必要です。

22.9 パフォーマンススキーマテーブルの説明

performance_schema データベース内のテーブルは次のようにグループ化できます。

  • セットアップテーブル。これらのテーブルは、モニタリング特性の構成と表示に使われます。

  • 現在のイベントテーブル。events_waits_current テーブルには各スレッドの最新のイベントが格納されます。その他の類似のテーブルには、イベント階層のさまざまなレベルの現在のイベントが格納されます (ステージイベント用の events_stages_current とステートメントイベント用の events_statements_current)。

  • 履歴テーブル。これらのテーブルは現在のイベントテーブルと同じ構造を持ちますが、多くの行を格納します。たとえば、待機イベントの場合、events_waits_history テーブルにはスレッドあたり最新の 10 イベントが格納されます。events_waits_history_long には最新の 10,000 イベントが格納されます。ステージおよびステートメント履歴用にほかの類似テーブルが存在します。

    履歴テーブルのサイズを変更するには、サーバー起動時に、該当するシステム変数を設定します。たとえば、待機イベント履歴テーブルのサイズを設定するには、performance_schema_events_waits_history_size および performance_schema_events_waits_history_long_size を設定します。

  • サマリーテーブル。これらのテーブルには、履歴テーブルから破棄されたものを含むイベントのグループ全体で集計された情報が格納されます。

  • インスタンステーブル。これらのテーブルは、インストゥルメントされたオブジェクトの種類を記述します。インストゥルメントされたオブジェクトは、サーバーによって使われると、イベントを生成します。これらのテーブルは、イベント名と説明のメモまたはステータス情報を提供します。

  • その他のテーブル。これらはほかのどのテーブルグループにも分類されません。

22.9.1 パフォーマンススキーマテーブルインデックス

次の表に、各パフォーマンススキーマテーブルを一覧表示し、それぞれの簡単な説明を提供します。

表 22.1 パフォーマンススキーマテーブル

テーブル名説明
accountsクライアントアカウントごとの接続統計
cond_instances同期オブジェクトインスタンス
events_stages_current現在のステージイベント
events_stages_history各スレッドの最新ステージイベント
events_stages_history_long全体の最新ステージイベント
events_stages_summary_by_account_by_event_nameアカウントおよびイベント名ごとのステージイベント
events_stages_summary_by_host_by_event_nameホスト名およびイベント名ごとのステージイベント
events_stages_summary_by_thread_by_event_nameスレッドおよびイベント名ごとのステージ待機
events_stages_summary_by_user_by_event_nameユーザー名およびイベント名ごとのステージイベント
events_stages_summary_global_by_event_nameイベント名ごとのステージ待機
events_statements_current現在のステートメントイベント
events_statements_history各スレッドの最新ステートメントイベント
events_statements_history_long全体の最新ステートメントイベント
events_statements_summary_by_account_by_event_nameアカウントおよびイベント名ごとのステートメントイベント
events_statements_summary_by_digestスキーマおよびダイジェスト値ごとのステートメントイベント
events_statements_summary_by_host_by_event_nameホスト名およびイベント名ごとのステートメントイベント
events_statements_summary_by_thread_by_event_nameスレッドおよびイベント名ごとのステートメントイベント
events_statements_summary_by_user_by_event_nameユーザー名およびイベント名ごとのステートメントイベント
events_statements_summary_global_by_event_nameイベント名ごとのステートメントイベント
events_waits_current現在の待機イベント
events_waits_history各スレッドの最新待機イベント
events_waits_history_long全体の最新待機イベント
events_waits_summary_by_account_by_event_nameアカウントおよびイベント名ごとの待機イベント
events_waits_summary_by_host_by_event_nameホスト名およびイベント名ごとの待機イベント
events_waits_summary_by_instanceインスタンスごとの待機イベント
events_waits_summary_by_thread_by_event_nameスレッドおよびイベント名ごとの待機イベント
events_waits_summary_by_user_by_event_nameユーザー名およびイベント名ごとの待機イベント
events_waits_summary_global_by_event_nameイベント名ごとの待機イベント
file_instancesファイルインスタンス
file_summary_by_event_nameイベント名ごとのファイルイベント
file_summary_by_instanceファイルインスタンスごとのファイルイベント
host_cache内部ホストキャッシュからの情報
hostsクライアントホスト名ごとの接続統計
mutex_instances相互排他ロック同期オブジェクトインスタンス
objects_summary_global_by_typeオブジェクトサマリー
performance_timers使用可能なイベントタイマー
rwlock_instancesロック同期オブジェクトインスタンス
session_account_connect_attrs現在のセッションごとの接続属性
session_connect_attrsすべてのセッションの接続属性
setup_actors新しいフォアグラウンドスレッドのモニタリングの初期化方法
setup_consumersイベント情報を格納できるコンシューマ
setup_instrumentsイベントを収集できるインストゥルメントされたオブジェクトのクラス
setup_objectsモニターすべきオブジェクト
setup_timers現在のイベントタイマー
socket_instancesアクティブな接続インスタンス
socket_summary_by_event_nameイベント名ごとのソケット待機と I/O
socket_summary_by_instanceインスタンスごとのソケット待機と I/O
table_io_waits_summary_by_index_usageインデックスごとのテーブル I/O 待機
table_io_waits_summary_by_tableテーブルごとのテーブル I/O 待機
table_lock_waits_summary_by_tableテーブルごとのテーブルロック待機
threadsサーバースレッドに関する情報
usersクライアントユーザー名ごとの接続統計

22.9.2 パフォーマンススキーマセットアップテーブル

セットアップテーブルは現在のインストゥルメンテーションに関する情報を提供し、モニタリング構成の変更を可能にします。このため、UPDATE 権限を持つ場合、これらのテーブルの一部のカラムを変更できます。

セットアップ情報に個々の変数ではなく、テーブルを使用することで、パフォーマンススキーマ構成の変更の高度な柔軟性を提供します。たとえば、標準 SQL 構文の単一のステートメントを使用して、複数の同時の構成変更ができます。

これらのセットアップテーブルを使用できます。

  • setup_actors: 新しいフォアグラウンドスレッドのモニタリングの初期化方法

  • setup_consumers: イベント情報を送信および格納できる宛先

  • setup_instruments: イベントを収集できるインストゥルメントされたオブジェクトのクラス

  • setup_objects: モニターすべきオブジェクト

  • setup_timers: 現在のイベントタイマー

22.9.2.1 setup_actors テーブル

setup_actors テーブルには、新しいフォアグラウンドサーバースレッド、つまりクライアント接続に関連付けられたスレッドのモニタリングを有効にするかどうかを決定する情報が格納されます。このテーブルはデフォルトで 100 行の最大サイズになります。テーブルサイズを変更するには、サーバー起動時に performance_schema_setup_actors_size システム変数を変更します。

新しいフォアグラウンドスレッドごとに、パフォーマンススキーマはスレッドのユーザーとホストを、setup_actors テーブルの行に対して照合します。一致する行があるかどうかに基づいて、スレッドの threads テーブル行の INSTRUMENTED カラムが YES または NO に設定されます。これにより、ホスト、ユーザー、またはホストとユーザーの組み合わせごとに、インストゥルメントが選択して適用されます。

setup_actors テーブルの初期の内容は、任意のユーザーとホストの組み合わせに一致するため、デフォルトですべてのフォアグラウンドスレッドのモニタリングが有効にされます。

mysql> SELECT * FROM setup_actors;+------+------+------+
| HOST | USER | ROLE |
+------+------+------+
| % | % | % |
+------+------+------+

setup_actors テーブルへの変更は既存のスレッドに影響しません。

イベントモニタリングで setup_actors テーブルを使用する方法については、セクション22.2.3.3.3「スレッドによる事前フィルタリング」を参照してください。

setup_actors テーブルにはこれらのカラムがあります。

  • HOST

    ホスト名。これらはリテラル名または任意のホストを意味する '%' であるべきです。

  • USER

    ユーザー名。これはリテラル名または任意のユーザーを意味する '%' であるべきです。

  • ROLE

    使用されません。

22.9.2.2 setup_consumers テーブル

setup_consumers テーブルは、イベント情報を格納でき、有効にされているコンシューマの種類を一覧表示します。

mysql> SELECT * FROM setup_consumers;+--------------------------------+---------+
| NAME | ENABLED |
+--------------------------------+---------+
| events_stages_current | NO |
| events_stages_history | NO |
| events_stages_history_long | NO |
| events_statements_current | YES |
| events_statements_history | NO |
| events_statements_history_long | NO |
| events_waits_current | NO |
| events_waits_history | NO |
| events_waits_history_long | NO |
| global_instrumentation | YES |
| thread_instrumentation | YES |
| statements_digest | YES |
+--------------------------------+---------+

setup_consumers テーブル内のコンシューマ設定は、高いレベルから低いレベルまでの階層を形成します。さまざまなコンシューマを有効にすることの効果の詳細については、セクション22.2.3.3.4「コンシューマによる事前フィルタリング」を参照してください。

setup_consumers テーブルへの変更はただちにモニタリングに影響します。

setup_consumers テーブルにはこれらのカラムがあります。

  • NAME

    コンシューマ名。

  • ENABLED

    コンシューマが有効にされているかどうか。このカラムは変更できます。コンシューマを無効にすると、サーバーはそれにイベント情報を追加する時間を費やさなくなります。

22.9.2.3 setup_instruments テーブル

setup_instruments テーブルは、イベントを収集できるインストゥルメントされたオブジェクトのクラスを一覧表示します。

mysql> SELECT * FROM setup_instruments;+------------------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+------------------------------------------------------------+---------+-------+
...
| wait/synch/mutex/sql/LOCK_global_read_lock | YES | YES |
| wait/synch/mutex/sql/LOCK_global_system_variables | YES | YES |
| wait/synch/mutex/sql/LOCK_lock_db | YES | YES |
| wait/synch/mutex/sql/LOCK_manager | YES | YES |
...
| wait/synch/rwlock/sql/LOCK_grant | YES | YES |
| wait/synch/rwlock/sql/LOGGER::LOCK_logger | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_connect | YES | YES |
| wait/synch/rwlock/sql/LOCK_sys_init_slave | YES | YES |
...
| wait/io/file/sql/binlog | YES | YES |
| wait/io/file/sql/binlog_index | YES | YES |
| wait/io/file/sql/casetest | YES | YES |
| wait/io/file/sql/dbopt | YES | YES |
...

ソースコードに追加された各インストゥルメントは、インストゥルメントされたコードが実行されない場合でもこのテーブルの行を提供します。インストゥルメントが有効にされており、実行されると、*_instances テーブルに表示されるインストゥルメントされたインスタンスが作成されます。

setup_instruments テーブルへの変更はただちにモニタリングに影響します。

イベントフィルタリングにおける setup_instruments テーブルの役割の詳細については、セクション22.2.3.3「イベントの事前フィルタリング」を参照してください。

setup_instruments テーブルにはこれらのカラムがあります。

  • NAME

    インストゥルメント名。セクション22.4「パフォーマンススキーマインストゥルメント命名規則」に説明するように、インストゥルメント名には複数の部分があり、階層を形成することがあります。インストゥルメントの実行から生成されるイベントには、インストゥルメント NAME 値から取得される EVENT_NAME 値があります。(イベントには実際には名前がありませんが、これによって、イベントをインストゥルメントに関連付ける方法を提供します。)

  • ENABLED

    インストゥルメントが有効にされているかどうか。このカラムは変更できます。無効にされたインストゥルメントはイベントを生成しません。

  • TIMED

    インストゥルメントの時間が測定されるかどうか。このカラムは変更できます。

    有効にされたインストゥルメントの時間が測定されない場合、インストゥルメントコードは有効ですが、タイマーは有効ではありません。インストゥルメントによって生成されたイベントの TIMER_STARTTIMER_END、および TIMER_WAIT タイマー値が NULL になります。これによって、サマリーテーブルの合計、最小、最大、および平均の時間値の計算時に、それらの値が無視されます。

22.9.2.4 setup_objects テーブル

setup_objects テーブルは、パフォーマンススキーマが特定のオブジェクトをモニターするかどうかを制御します。このテーブルはデフォルトで 100 行の最大サイズになります。テーブルサイズを変更するには、サーバー起動時に performance_schema_setup_objects_size システム変数を変更します。

初期 setup_objects の内容は次のように見えます。

mysql> SELECT * FROM setup_objects;+-------------+--------------------+-------------+---------+-------+
| OBJECT_TYPE | OBJECT_SCHEMA | OBJECT_NAME | ENABLED | TIMED |
+-------------+--------------------+-------------+---------+-------+
| TABLE | mysql | % | NO | NO |
| TABLE | performance_schema | % | NO | NO |
| TABLE | information_schema | % | NO | NO |
| TABLE | % | % | YES | YES |
+-------------+--------------------+-------------+---------+-------+

setup_objects テーブルへの変更はただちにオブジェクトモニタリングに影響します。

setup_objects に示されているオブジェクトの種類では、パフォーマンススキーマはそれらのモニター方法にテーブルを使用します。オブジェクトの一致は OBJECT_SCHEMA および OBJECT_NAME カラムに基づきます。一致のないオブジェクトはモニターされません。

デフォルトのオブジェクト構成の効果は、mysqlINFORMATION_SCHEMA、および performance_schema データベースのテーブルを除くすべてのテーブルをインストゥルメントすることです。(INFORMATION_SCHEMA データベース内のテーブルは、setup_objects の内容に関係なくインストゥルメントされず、information_schema.% の行は単にこのデフォルトを明示します。)

パフォーマンススキーマは、setup_objects の一致をチェックする場合、まずより詳細な一致を見つけようとします。たとえば、テーブル db1.t1 では、'db1''t1'、次に 'db1''%'、次に '%''%' の一致を検索します。さまざまな一致する setup_objects 行はさまざまな ENABLED 値と TIMED 値を持つ可能性があるため、一致が発生する順序が重要です。

テーブルへの INSERT または DELETE 権限を持つユーザーが、setup_objects に行を挿入したり、削除したりできます。既存の行では、テーブルへの UPDATE 権限を持つユーザーによって、ENABLED および TIMED カラムのみを変更できます。

イベントフィルタリングにおける setup_objects テーブルの役割の詳細については、セクション22.2.3.3「イベントの事前フィルタリング」を参照してください。

setup_objects テーブルにはこれらのカラムがあります。

  • OBJECT_TYPE

    インストゥルメントするオブジェクトの種類。現在、これは常に 'TABLE' (ベーステーブル) です。

    TABLE フィルタリングはテーブル I/O イベント (wait/io/table/sql/handler インストゥルメント) およびテーブルロックイベント (wait/lock/table/sql/handler インストゥルメント) に影響します。

  • OBJECT_SCHEMA

    オブジェクトを格納するスキーマ。これはリテラル名、または任意のスキーマを意味する '%' であるべきです。

  • OBJECT_NAME

    インストゥルメントされたオブジェクトの名前。これはリテラル名、または任意のオブジェクトを意味する '%' であるべきです。

  • ENABLED

    オブジェクトのイベントがインストゥルメントされるかどうか。このカラムは変更できます。

    このカラムは、MySQL 5.6.3 で追加されました。それが存在しない初期バージョンの場合、パフォーマンススキーマはテーブル内の一部の行に一致するオブジェクトに対してのみモニタリングを有効にします。一致しないオブジェクトに対しては、モニタリングは暗黙的に無効にされます。

  • TIMED

    オブジェクトのイベントの時間が測定されるかどうか。このカラムは変更できます。

22.9.2.5 setup_timers テーブル

setup_timers テーブルには現在選択されているイベントタイマーが表示されます。

mysql> SELECT * FROM setup_timers;+-----------+-------------+
| NAME | TIMER_NAME |
+-----------+-------------+
| idle | MICROSECOND |
| wait | CYCLE |
| stage | NANOSECOND |
| statement | NANOSECOND |
+-----------+-------------+

setup_timers.TIMER_NAME 値を変更して、異なるタイマーを選択できます。値は performance_timers.TIMER_NAME カラム内の任意の値にすることができます。イベントタイミングがどのように行われるかの説明については、セクション22.2.3.1「パフォーマンススキーマイベントタイミング」を参照してください。

setup_timers テーブルへの変更はただちにモニタリングに影響します。すでに進行中のイベントは、開始時間に元のタイマーを使用し、終了時間に新しいタイマーを使用する可能性があるため、予測不可能な結果に至る場合があります。タイマーを変更した場合、TRUNCATE TABLE を使用して、パフォーマンススキーマの統計をリセットする必要がある場合があります。

setup_timers テーブルにはこれらのカラムがあります。

  • NAME

    タイマーが使用されるインストゥルメントの種類。

  • TIMER_NAME

    インストゥルメントの種類に適用されるタイマー。このカラムは変更できます。

22.9.3 パフォーマンススキーマインスタンステーブル

インスタンステーブルは、インストゥルメントされたオブジェクトの種類を記述します。それらは、イベント名と説明のメモまたはステータス情報を提供します。

  • cond_instances: 条件同期オブジェクトインスタンス

  • file_instances: ファイルインスタンス

  • mutex_instances: 相互排他ロック同期オブジェクトインスタンス

  • rwlock_instances: ロック同期オブジェクトインスタンス

  • socket_instances: アクティブな接続インスタンス

これらのテーブルはインストゥルメントされた同期オブジェクト、ファイル、および接続を一覧表示します。3 種類の同期オブジェクト condmutex、および rwlock があります。各インスタンステーブルには、各行に関連付けられているインストゥルメントを示す EVENT_NAME または NAME カラムがあります。セクション22.4「パフォーマンススキーマインストゥルメント命名規則」に説明するように、インストゥルメント名には複数の部分があり、階層を形成することがあります。

mutex_instances.LOCKED_BY_THREAD_ID および rwlock_instances.WRITE_LOCKED_BY_THREAD_ID カラムは、パフォーマンスボトルネックまたはデッドロックの調査にきわめて重要です。この目的でそれらを使用する方法の例については、セクション22.15「問題を診断するためのパフォーマンススキーマの使用」を参照してください

22.9.3.1 cond_instances テーブル

cond_instances テーブルは、サーバーの実行中にパフォーマンススキーマによって確認されるすべての条件を一覧表示します。条件は、この条件を待機しているスレッドが作業を再開できるように、特定のイベントが発生したことを伝えるために、コードで使用される同期メカニズムです。

スレッドが何かの発生を待機している場合、条件名は、スレッドが待機しているものを示しますが、ほかのどのスレッドが条件を発生させるかを伝えるための直接の方法はありません。

cond_instances テーブルにはこれらのカラムがあります。

  • NAME

    条件に関連付けられているインストゥルメント名。

  • OBJECT_INSTANCE_BEGIN

    インストゥルメントされた条件のメモリー内のアドレス。

22.9.3.2 file_instances テーブル

file_instances テーブルは、ファイル I/O インストゥルメンテーションの実行中にパフォーマンススキーマによって確認されるすべてのファイルを一覧表示します。ディスク上のファイルが開かれたことがない場合、file_instances に含まれません。ファイルがディスクから削除されると、file_instances テーブルからも削除されます。

file_instances テーブルにはこれらのカラムがあります。

  • FILE_NAME

    ファイル名。

  • EVENT_NAME

    ファイルに関連付けられているインストゥルメント名。

  • OPEN_COUNT

    ファイルへのオープンハンドルのカウント。ファイルが開かれ、閉じられた場合、それは 1 回開かれていますが、OPEN_COUNT は 0 になります。サーバーによって現在開かれているすべてのファイルを一覧表示するには、WHERE OPEN_COUNT > 0 を使用します。

22.9.3.3 mutex_instances テーブル

mutex_instances テーブルは、サーバーの実行中にパフォーマンススキーマによって確認されるすべての相互排他ロックを一覧表示します。相互排他ロックは、特定の時間に 1 つだけのスレッドが特定の共通リソースにアクセスできるようにする、コードで使用される同期メカニズムです。リソースは相互排他ロックによって保護されていると呼ばれます。

サーバーで実行している 2 つのスレッド (たとえば、クエリーを同時に実行している 2 つのユーザーセッション) が同じリソース (ファイル、バッファー、データの一部) にアクセスする必要がある場合、これらの 2 つのスレッドは互いに競争するため、相互排他ロックのロックを取得する最初のクエリーによって、ほかのクエリーは最初のクエリーが終了し、相互排他ロックを解除するまで待たされます。

相互排他ロックの保持中に実行される作業はクリティカルセクションにあると呼ばれ、複数のクエリーがこのクリティカルセクションを連続して (一度に 1 つずつ) 実行するため、これは潜在的なボトルネックになります。

mutex_instances テーブルにはこれらのカラムがあります。

  • NAME

    相互排他ロックに関連付けられているインストゥルメント名。

  • OBJECT_INSTANCE_BEGIN

    インストゥルメントされた相互排他ロックのメモリー内のアドレス。

  • LOCKED_BY_THREAD_ID

    スレッドが現在相互排他ロックされている場合、LOCKED_BY_THREAD_ID はロックしているスレッドの THREAD_ID になり、そうでない場合、それは NULL になります。

コードにインストゥルメントされた各相互排他ロックについて、パフォーマンススキーマは次の情報を提供します。

  • setup_instruments テーブルは、プリフィクス wait/synch/mutex/ を付けて、インストゥルメンテーションポイントの名前を一覧表示します。

  • 一部のコードで相互排他ロックが作成されると、行が mutex_instances テーブルに追加されます。OBJECT_INSTANCE_BEGIN カラムは相互排他ロックを一意に識別するプロパティーです。

  • スレッドが相互排他ロックのロックを試みた場合、events_waits_current テーブルにそのスレッドの行が表示され、それが相互排他ロックを待機していることが示され (EVENT_NAME カラム内)、待機されている相互排他ロックが示されます (OBJECT_INSTANCE_BEGIN カラム内)。

  • スレッドが相互排他ロックのロックに成功した場合:

    • events_waits_current は相互排他ロックへの待機が完了したことを示します (TIMER_END および TIMER_WAIT カラム内)

    • 完了した待機イベントは events_waits_history および events_waits_history_long テーブルに追加されます。

    • mutex_instances は相互排他ロックがスレッドによって所有されるようになったことを示します (THREAD_ID カラム内)。

  • スレッドが相互排他ロックのロックを解除すると、mutex_instances は相互排他ロックに所有者がいなくなったことを示します (THREAD_ID カラムが NULL になります)。

  • 相互排他ロックオブジェクトが破棄されると、対応する行が mutex_instances から削除されます。

次の両方のテーブルに対してクエリーを実行することによって、モニタリングアプリケーションまたは DBA は相互排他ロックを伴うスレッド間のボトルネックやデッドロックを検出できます。

  • events_waits_current、スレッドが待機している相互排他ロックを確認する場合

  • mutex_instances、相互排他ロックを現在所有しているほかのスレッドを確認する場合

22.9.3.4 rwlock_instances テーブル

rwlock_instances テーブルは、サーバーの実行中にパフォーマンススキーマによって確認されるすべての rwlock インスタンス (読み取り書き込みロック) を一覧表示します。rwlock は、特定の時間にそのスレッドが、次の特定のルールに従って、一部の共通リソースにアクセスできるようにするために、コードで使用される同期メカニズムです。リソースは rwlock によって保護されていると呼ばれます。アクセスは共有されている (多くのスレッドが同時に読み取りロックを持つことができる) かまたは排他的 (特定の時間に 1 つのスレッドだけが書き込みロックを持つことができる) のいずれかです。

ロックをリクエストしているスレッドの数、およびリクエストされているロックの性質に応じて、アクセスが共有モードで許可されるか、排他モードで許可されるか、またはまったく許可されないかのいずれかになる可能性があり、まずほかのスレッドが終了するのを待機します。

rwlock_instances テーブルにはこれらのカラムがあります。

  • NAME

    ロックに関連付けられているインストゥルメント名。

  • OBJECT_INSTANCE_BEGIN

    インストゥルメントされたロックのメモリー内のアドレス。

  • WRITE_LOCKED_BY_THREAD_ID

    スレッドが現在排他 (書き込み) モードでロックされた rwlock を持つ場合、WRITE_LOCKED_BY_THREAD_ID はロックしているスレッドの THREAD_ID になり、そうでない場合、それは NULL になります。

  • READ_LOCKED_BY_COUNT

    スレッドが現在共有 (読み取り) モードでロックされた rwlock を持つ場合、READ_LOCKED_BY_COUNT が 1 増分されます。これはカウンタのみであるため、読み取りロックを保持するスレッドを見つけるためにそれを直接使用することはできませんが、rwlock に対して読み取りの競合があるかどうかを確認し、現在アクティブなリーダー数を確認するために使用することができます。

次の両方のテーブルに対してクエリーを実行することによって、モニタリングアプリケーションまたは DBA はロックを伴うスレッド間の何らかのボトルネックやデッドロックを検出できます。

  • events_waits_current、スレッドが待機している rwlock を確認する場合

  • rwlock_instancesrwlock を現在所有しているほかのスレッドを確認する場合

制限があります。rwlock_instances は、書き込みロックを保持しているスレッドの識別にのみ使用できますが、読み取りロックを保持しているスレッドの識別には使用できません。

22.9.3.5 socket_instances テーブル

socket_instances テーブルは MySQL サーバーへのアクティブな接続のリアルタイムスナップショットを提供します。テーブルには、TCP/IP または Unix ソケットファイル接続ごとに 1 行含まれます。このテーブルで使用可能な情報は、サーバーへのアクティブな接続のリアルタイムスナップショットを提供します。(ソケット操作や送受信されたバイト数などのネットワークアクティビティーを含む、追加の情報はソケットサマリーテーブルで入手できます。セクション22.9.9.8「ソケットサマリーテーブル」を参照してください)。

mysql> SELECT * FROM socket_instances\G*************************** 1. row *************************** EVENT_NAME: wait/io/socket/sql/server_unix_socket
OBJECT_INSTANCE_BEGIN: 4316619408 THREAD_ID: 1 SOCKET_ID: 16 IP: PORT: 0 STATE: ACTIVE
*************************** 2. row *************************** EVENT_NAME: wait/io/socket/sql/client_connection
OBJECT_INSTANCE_BEGIN: 4316644608 THREAD_ID: 21 SOCKET_ID: 39 IP: 127.0.0.1 PORT: 55233 STATE: ACTIVE
*************************** 3. row *************************** EVENT_NAME: wait/io/socket/sql/server_tcpip_socket
OBJECT_INSTANCE_BEGIN: 4316699040 THREAD_ID: 1 SOCKET_ID: 14 IP: 0.0.0.0 PORT: 50603 STATE: ACTIVE

ソケットインストゥルメントは形式 wait/io/socket/sql/socket_type の名前を持ち、次のように使用されます。

  1. サーバーには、それがサポートする各ネットワークプロトコルの待機ソケットがあります。TCP/IP または Unix ソケットファイル接続の待機ソケットに関連付けられているインストゥルメントは、それぞれ server_tcpip_socket または server_unix_socketsocket_type 値を持ちます。

  2. 待機ソケットが接続を検出すると、サーバーは接続を、個別のスレッドによって管理される新しいソケットに転送します。新しい接続スレッドのインストゥルメントは、client_connectionsocket_type 値を持ちます。

  3. 接続が終了すると、socket_instances 内のそれに対応する行が削除されます。

socket_instances テーブルにはこれらのカラムがあります。

  • EVENT_NAME

    イベントを生成した wait/io/socket/* インストゥルメントの名前。これは setup_instruments テーブルからの NAME 値です。セクション22.4「パフォーマンススキーマインストゥルメント命名規則」に説明するように、インストゥルメント名には複数の部分があり、階層を形成することがあります。

  • OBJECT_INSTANCE_BEGIN

    このカラムは一意にソケットを識別します。この値はメモリー内のオブジェクトのアドレスです。

  • THREAD_ID

    サーバーによって割り当てられた内部スレッド識別子。各ソケットは単一のスレッドによって管理されるため、各ソケットはスレッドにマップでき、スレッドはサーバープロセスにマップできます。

  • SOCKET_ID

    ソケットに割り当てられている内部ファイルハンドル。

  • IP

    クライアントの IP アドレス。この値は IPv4 または IPv6 アドレスのいずれか、または Unix ソケットファイル接続を示すブランクになります。

  • PORT

    0 から 65535 の範囲の TCP/IP ポート番号。

  • STATE

    IDLE または ACTIVE のいずれかのソケットステータス。アクティブなソケットの待機時間は、対応するソケットインストゥルメントを使用して追跡されます。アイドルソケットの待機時間は、idle インストゥルメントを使用して追跡されます。

    ソケットはクライアントからのリクエストを待機している場合、アイドルになります。ソケットがアイドルになると、ソケットを追跡している socket_instances 内のイベント行が ACTIVE のステータスから IDLE に切り替わります。EVENT_NAME 値は wait/io/socket/* のままになりますが、インストゥルメントのタイミングは一時停止されます。代わりに、idleEVENT_NAME 値で events_waits_current テーブルにイベントが生成されます。

    次のリクエストを受信すると、idle イベントが終了し、ソケットインスタンスが IDLE から ACTIVE に切り替わり、ソケットインストゥルメントのタイミングが再開します。

IP:PORT カラムの組み合わせの値は接続を識別します。この組み合わせの値は、ソケットイベントの発生元の接続を識別するために、events_waits_xxx テーブルの OBJECT_NAME カラムで使用されます。

  • Unix ドメインリスナーソケット (server_unix_socket) の場合、ポートは 0 で IP は '' です。

  • Unix ドメインリスナー経由のクライアント接続 (client_connection) の場合、ポートは 0 で IP は '' です。

  • TCP/IP サーバーリスナーソケット (server_tcpip_socket) の場合、ポートは常にマスターポート (たとえば 3306) で、IP は常に 0.0.0.0 です。

  • TCP/IP リスナー経由のクライアント接続 (client_connection) の場合、ポートはサーバーが割り当てたものになりますが、0 にはなりません。IP は発信元ホストの IP (ローカルホストの場合 127.0.0.1 または ::1) です

socket_instances テーブルは MySQL 5.6.3 で追加されました。

22.9.4 パフォーマンススキーマ待機イベントテーブル

これらのテーブルは待機イベントを格納します。

  • events_waits_current: 現在の待機イベント

  • events_waits_history: 各スレッドの最新の待機イベント

  • events_waits_history_long: 全体の最新の待機イベント

次のセクションでそれらのテーブルについて説明します。待機イベントに関する情報を集計するサマリーテーブルもあります。セクション22.9.9.1「イベント待機サマリーテーブル」を参照してください。

待機イベント構成

待機イベントの収集を有効にするには、関連インストゥルメントとコンシューマを有効にします。

setup_instruments テーブルには、wait で始まる名前を持つインストゥルメントが格納されます。例:

mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'wait/io/file/innodb%';+--------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+--------------------------------------+---------+-------+
| wait/io/file/innodb/innodb_data_file | YES | YES |
| wait/io/file/innodb/innodb_log_file | YES | YES |
| wait/io/file/innodb/innodb_temp_file | YES | YES |
+--------------------------------------+---------+-------+
mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'wait/io/socket/%';+----------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+----------------------------------------+---------+-------+
| wait/io/socket/sql/server_tcpip_socket | NO | NO |
| wait/io/socket/sql/server_unix_socket | NO | NO |
| wait/io/socket/sql/client_connection | NO | NO |
+----------------------------------------+---------+-------+

待機イベントの収集を変更するには、関連インストゥルメントの ENABLED および TIMING カラムを変更します。例:

mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES' -> WHERE NAME LIKE 'wait/io/socket/sql/%';

setup_consumers テーブルには現在および最近の待機イベントテーブル名に対応する名前を持つコンシューマ値が格納されます。これらのコンシューマは待機イベントのコレクションをフィルタ処理するために使用できます。待機コンシューマはデフォルトで無効にされています。

mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%waits%';+---------------------------+---------+
| NAME | ENABLED |
+---------------------------+---------+
| events_waits_current | NO |
| events_waits_history | NO |
| events_waits_history_long | NO |
+---------------------------+---------+

すべての待機コンシューマを有効にするには、次を実行します。

mysql> UPDATE setup_consumers SET ENABLED = 'YES' -> WHERE NAME LIKE '%waits%';

setup_timers テーブルには、待機イベントのタイミングの単位を示す waitNAME 値のある行が格納されます。デフォルトの単位は CYCLE です。

mysql> SELECT * FROM setup_timers WHERE NAME = 'wait';+------+------------+
| NAME | TIMER_NAME |
+------+------------+
| wait | CYCLE |
+------+------------+

タイミングの単位を変更するには、TIMER_NAME 値を変更します。

mysql> UPDATE setup_timers SET TIMER_NAME = 'NANOSECOND' -> WHERE NAME = 'wait';

イベント収集の構成に関する追加情報については、セクション22.2「パフォーマンススキーマ構成」を参照してください。

22.9.4.1 events_waits_current テーブル

events_waits_current テーブルには、スレッドの最新のモニター対象待機イベントの現在のステータスを示すスレッドごとに 1 行で現在の待機イベントが格納されます。

events_waits_current テーブルは TRUNCATE TABLE で切り捨てることができます。

待機イベント行を格納するテーブルのうち、events_waits_current はもっとも基本的です。待機イベント行を格納するほかのテーブルは論理的に現在のイベントから派生します。たとえば、events_waits_history および events_waits_history_long テーブルは固定の行数以下の最新の待機イベントのコレクションです。

待機イベント収集の構成については、セクション22.9.4「パフォーマンススキーマ待機イベントテーブル」を参照してください。

events_waits_current テーブルにはこれらのカラムがあります。

  • THREAD_IDEVENT_ID

    イベントに関連付けられたスレッドとイベントの起動時のスレッドの現在のイベント番号。一緒に取得された THREAD_ID および EVENT_ID 値は、行を一意に識別する主キーを形成します。2 つの行が同じ値のペアを持つことはありません。

  • END_EVENT_ID

    このカラムは、イベントの起動時に NULL に設定され、イベントの終了時にスレッドの現在のイベント番号に更新されます。このカラムは、MySQL 5.6.4 で追加されました。

  • EVENT_NAME

    イベントを生成したインストゥルメントの名前。これは setup_instruments テーブルからの NAME 値です。セクション22.4「パフォーマンススキーマインストゥルメント命名規則」に説明するように、インストゥルメント名には複数の部分があり、階層を形成することがあります。

  • SOURCE

    イベントを生成した、インストゥルメントされたコードを格納するソースファイルの名前と、インストゥルメンテーションが行われたファイルの行番号。これにより、ソースをチェックして、コードに含まれるものを正確に判断することができます。たとえば、相互排他ロックまたはロックがブロックされた場合、これが発生するコンテキストをチェックできます。

  • TIMER_STARTTIMER_ENDTIMER_WAIT

    イベントのタイミング情報。これらの値の単位はピコ秒 (秒の 1 兆分の 1) です。TIMER_START および TIMER_END 値は、イベントのタイミングが開始されたときと終了したときを示します。TIMER_WAIT はイベントの経過時間 (期間) です。

    イベントが終了していない場合、TIMER_ENDTIMER_WAITNULL です。

    イベントが TIMED = NO のインストゥルメントから生成されている場合、タイミング情報は収集されず、TIMER_STARTTIMER_END、および TIMER_WAIT はすべて NULL になります。

    イベント時間の単位としてのピコ秒および時間値に影響する要因については、セクション22.2.3.1「パフォーマンススキーマイベントタイミング」を参照してください。

  • SPINS

    相互排他ロックの場合、スピンラウンドの数。値が NULL の場合、コードはスピンラウンドを使用しないか、スピニングがインストゥルメントされません。

  • OBJECT_SCHEMAOBJECT_NAMEOBJECT_TYPEOBJECT_INSTANCE_BEGIN

    これらのカラムは作用しているオブジェクトを識別します。その意味は、オブジェクトの種類によって異なります。

    同期オブジェクト (condmutex、および rwlock) の場合:

    • OBJECT_SCHEMAOBJECT_NAME、および OBJECT_TYPENULL です。

    • OBJECT_INSTANCE_BEGIN はメモリー内の同期オブジェクトのアドレスです。

    ファイル I/O オブジェクトの場合:

    • OBJECT_SCHEMANULL です。

    • OBJECT_NAME はファイル名です。

    • OBJECT_TYPEFILE です。

    • OBJECT_INSTANCE_BEGIN はメモリー内のアドレスです。

    ソケットオブジェクトの場合:

    • OBJECT_NAME はソケットの IP:PORT 値です。

    • OBJECT_INSTANCE_BEGIN はメモリー内のアドレスです。

    テーブル I/O オブジェクトの場合:

    • OBJECT_SCHEMA はテーブルを格納するスキーマの名前です。

    • OBJECT_NAME はテーブル名です。

    • OBJECT_TYPE は永続的ベーステーブルの TABLE または一時テーブルの TEMPORARY TABLE です。

    • OBJECT_INSTANCE_BEGIN はメモリー内のアドレスです。

    OBJECT_INSTANCE_BEGIN 値自体には、さまざまな値がさまざまなオブジェクトを示すことを除いて、意味がありません。OBJECT_INSTANCE_BEGIN はデバッグに使用できます。たとえば、それを GROUP BY OBJECT_INSTANCE_BEGIN で使用して、1,000 相互排他ロック (つまり、データの 1,000 ページまたはブロックを保護する) の負荷が均等に広がっているか、または少数のボトルネックだけに関わっているかを確認できます。これにより、ログファイルやほかのデバッグまたはパフォーマンスツールで同じオブジェクトアドレスが見られた場合に、情報のほかのソースと関連付けることができます。

  • INDEX_NAME

    使用されるインデックスの名前。PRIMARY はテーブルプライマリインデックスを示します。NULL はインデックスが使用されなかったことを意味します。

  • NESTING_EVENT_ID

    このイベントが中にネストされているイベントの EVENT_ID 値。MySQL 5.6.3 より前では、このカラムは常に NULL です。

  • NESTING_EVENT_TYPE

    ネストしているイベントの種類。値は STATEMENTSTAGE、または WAIT です。このカラムは、MySQL 5.6.3 で追加されました。

  • OPERATION

    lockread、または write などの実行される操作の種類。

  • NUMBER_OF_BYTES

    操作によって読み取りまたは書き込まれるバイト数。テーブル I/O 待機 (wait/io/table/sql/handler インストゥルメントのイベント) の場合、NUMBER_OF_BYTESNULL になります。

  • FLAGS

    将来使用するために予約されています。

22.9.4.2 events_waits_history テーブル

events_waits_history テーブルには、スレッドごとの最新の N 待機イベントが格納されます。N の値はサーバー起動時に自動サイズ設定されます。テーブルサイズを明示的に設定するには、サーバー起動時に performance_schema_events_waits_history_size システム変数を設定します。待機イベントはそれらが終了するまでテーブルに追加されません。新しいイベントが追加されたときに、テーブルがいっぱいである場合、古いイベントが破棄されます。

events_waits_history テーブルは events_waits_current と同じ構造を持ちます。セクション22.9.4.1「events_waits_current テーブル」を参照してください。

events_waits_history テーブルは TRUNCATE TABLE で切り捨てることができます。

待機イベント収集の構成については、セクション22.9.4「パフォーマンススキーマ待機イベントテーブル」を参照してください。

22.9.4.3 events_waits_history_long テーブル

events_waits_history_long テーブルには、最新の N 待機イベントが格納されます。N の値はサーバー起動時に自動サイズ設定されます。テーブルサイズを明示的に設定するには、サーバー起動時に performance_schema_events_waits_history_long_size システム変数を設定します。待機イベントはそれらが終了するまでテーブルに追加されません。新しいイベントが追加されたときに、テーブルがいっぱいである場合、古いイベントが破棄されます。

events_waits_history_long テーブルは events_waits_current と同じ構造を持ちます。セクション22.9.4.1「events_waits_current テーブル」を参照してください。

events_waits_history_long テーブルは TRUNCATE TABLE で切り捨てることができます。

待機イベント収集の構成については、セクション22.9.4「パフォーマンススキーマ待機イベントテーブル」を参照してください。

22.9.5 パフォーマンススキーマステージイベントテーブル

MySQL 5.6.3 現在、パフォーマンススキーマは、ステートメントの解析、テーブルのオープン、または filesort 操作の実行などのステートメント実行プロセス中のステップであるステージをインストゥルメントします。ステージは SHOW PROCESSLIST によって表示されるか、または INFORMATION_SCHEMA.PROCESSLIST テーブルに表示されるスレッドの状態に対応します。ステージは、状態値が変化したときに開始および終了します。

イベント階層内で、待機イベントはステージイベント内にネストし、ステージイベントはステートメントイベント内にネストします。

これらのテーブルはステージイベントを格納します。

  • events_stages_current: 現在のステージイベント

  • events_stages_history: 各スレッドの最新のステージイベント

  • events_stages_history_long: 全体の最新のステージイベント

次のセクションでそれらのテーブルについて説明します。ステージイベントに関する情報を集計するサマリーテーブルもあります。セクション22.9.9.2「ステージサマリーテーブル」を参照してください。

ステージイベント構成

ステージイベントの収集を有効にするには、関連インストゥルメントとコンシューマを有効にします。

setup_instruments テーブルには、stage で始まる名前を持つインストゥルメントが格納されます。これらのインストゥルメントはデフォルトで無効にされています。例:

mysql> SELECT * FROM setup_instruments WHERE NAME RLIKE 'stage/sql/[a-c]';+----------------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+----------------------------------------------------+---------+-------+
| stage/sql/After create | NO | NO |
| stage/sql/allocating local table | NO | NO |
| stage/sql/altering table | NO | NO |
| stage/sql/committing alter table to storage engine | NO | NO |
| stage/sql/Changing master | NO | NO |
| stage/sql/Checking master version | NO | NO |
| stage/sql/checking permissions | NO | NO |
| stage/sql/checking privileges on cached query | NO | NO |
| stage/sql/checking query cache for query | NO | NO |
| stage/sql/cleaning up | NO | NO |
| stage/sql/closing tables | NO | NO |
| stage/sql/Connecting to master | NO | NO |
| stage/sql/converting HEAP to MyISAM | NO | NO |
| stage/sql/Copying to group table | NO | NO |
| stage/sql/Copying to tmp table | NO | NO |
| stage/sql/copy to tmp table | NO | NO |
| stage/sql/Creating delayed handler | NO | NO |
| stage/sql/Creating sort index | NO | NO |
| stage/sql/creating table | NO | NO |
| stage/sql/Creating tmp table | NO | NO |
+----------------------------------------------------+---------+-------+

ステージイベントの収集を変更するには、関連インストゥルメントの ENABLED および TIMING カラムを変更します。例:

mysql> UPDATE setup_instruments SET ENABLED = 'YES', TIMED = 'YES' -> WHERE NAME = 'stage/sql/altering table';

setup_consumers テーブルには現在および最近のステージイベントテーブル名に対応する名前を持つコンシューマ値が格納されます。これらのコンシューマはステージイベントのコレクションをフィルタ処理するために使用できます。ステージコンシューマはデフォルトで無効にされています。

mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%stages%';+----------------------------+---------+
| NAME | ENABLED |
+----------------------------+---------+
| events_stages_current | NO |
| events_stages_history | NO |
| events_stages_history_long | NO |
+----------------------------+---------+

すべてのステージコンシューマを有効にするには、次を実行します。

mysql> UPDATE setup_consumers SET ENABLED = 'YES' -> WHERE NAME LIKE '%stages%';

setup_timers テーブルには、ステージイベントのタイミングの単位を示す stageNAME 値のある行が格納されます。デフォルトの単位は NANOSECOND です。

mysql> SELECT * FROM setup_timers WHERE NAME = 'stage';+-------+------------+
| NAME | TIMER_NAME |
+-------+------------+
| stage | NANOSECOND |
+-------+------------+

タイミングの単位を変更するには、TIMER_NAME 値を変更します。

mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND' -> WHERE NAME = 'stage';

イベント収集の構成に関する追加情報については、セクション22.2「パフォーマンススキーマ構成」を参照してください。

22.9.5.1 events_stages_current テーブル

events_stages_current テーブルには、スレッドの最新のモニター対象ステージイベントの現在のステータスを示すスレッドごとに 1 行で現在のステージイベントが格納されます。

events_stages_current テーブルは TRUNCATE TABLE で切り捨てることができます。

ステージイベント行を格納するテーブルのうち、events_stages_current はもっとも基本的です。ステージイベント行を格納するほかのテーブルは論理的に現在のイベントから派生します。たとえば、events_stages_history および events_stages_history_long テーブルは固定の行数以下の最新のステージイベントのコレクションです。

ステージイベント収集の構成については、セクション22.9.5「パフォーマンススキーマステージイベントテーブル」を参照してください。

events_stages_current テーブルにはこれらのカラムがあります。

  • THREAD_IDEVENT_ID

    イベントに関連付けられたスレッドとイベントの起動時のスレッドの現在のイベント番号。一緒に取得された THREAD_ID および EVENT_ID 値は、行を一意に識別する主キーを形成します。2 つの行が同じ値のペアを持つことはありません。

  • END_EVENT_ID

    このカラムは、イベントの起動時に NULL に設定され、イベントの終了時にスレッドの現在のイベント番号に更新されます。このカラムは、MySQL 5.6.4 で追加されました。

  • EVENT_NAME

    イベントを生成したインストゥルメントの名前。これは setup_instruments テーブルからの NAME 値です。セクション22.4「パフォーマンススキーマインストゥルメント命名規則」に説明するように、インストゥルメント名には複数の部分があり、階層を形成することがあります。

  • SOURCE

    イベントを生成した、インストゥルメントされたコードを格納するソースファイルの名前と、インストゥルメンテーションが行われたファイルの行番号。これにより、ソースをチェックして、コードに含まれるものを正確に判断することができます。

  • TIMER_STARTTIMER_ENDTIMER_WAIT

    イベントのタイミング情報。これらの値の単位はピコ秒 (秒の 1 兆分の 1) です。TIMER_START および TIMER_END 値は、イベントのタイミングが開始されたときと終了したときを示します。TIMER_WAIT はイベントの経過時間 (期間) です。

    イベントが終了していない場合、TIMER_ENDTIMER_WAITNULL です。

    イベントが TIMED = NO のインストゥルメントから生成されている場合、タイミング情報は収集されず、TIMER_STARTTIMER_END、および TIMER_WAIT はすべて NULL になります。

    イベント時間の単位としてのピコ秒および時間値に影響する要因については、セクション22.2.3.1「パフォーマンススキーマイベントタイミング」を参照してください。

  • NESTING_EVENT_ID

    このイベントが中にネストされているイベントの EVENT_ID 値。ステージイベントのネストしているイベントは通常ステートメントイベントです。

  • NESTING_EVENT_TYPE

    ネストしているイベントの種類。値は STATEMENTSTAGE、または WAIT です。

events_stages_current テーブルは MySQL 5.6.3 で追加されました。

22.9.5.2 events_stages_history テーブル

events_stages_history テーブルにはスレッドごとに最新の N ステージイベントが格納されます。N の値はサーバー起動時に自動サイズ設定されます。テーブルサイズを明示的に設定するには、サーバー起動時に performance_schema_events_stages_history_size システム変数を設定します。ステージイベントは終了するまでテーブルに追加されません。新しいイベントが追加されたときに、テーブルがいっぱいである場合、古いイベントが破棄されます。

events_stages_history テーブルは events_stages_current と同じ構造を持ちます。セクション22.9.5.1「events_stages_current テーブル」を参照してください。

events_stages_history テーブルは TRUNCATE TABLE で切り捨てることができます。

events_stages_history テーブルは MySQL 5.6.3 で追加されました。

ステージイベント収集の構成については、セクション22.9.5「パフォーマンススキーマステージイベントテーブル」を参照してください。

22.9.5.3 events_stages_history_long テーブル

events_stages_history_long テーブルには最新の N ステージイベントが格納されます。N の値はサーバー起動時に自動サイズ設定されます。テーブルサイズを明示的に設定するには、サーバー起動時に performance_schema_events_stages_history_long_size システム変数を設定します。ステージイベントは終了するまでテーブルに追加されません。新しいイベントが追加されたときに、テーブルがいっぱいである場合、古いイベントが破棄されます。

events_stages_history_long テーブルは events_stages_current と同じ構造を持ちます。セクション22.9.5.1「events_stages_current テーブル」を参照してください。

events_stages_history_long テーブルは TRUNCATE TABLE で切り捨てることができます。

events_stages_history_long テーブルは MySQL 5.6.3 で追加されました。

ステージイベント収集の構成については、セクション22.9.5「パフォーマンススキーマステージイベントテーブル」を参照してください。

22.9.6 パフォーマンススキーマステートメントイベントテーブル

MySQL 5.6.3 現在、パフォーマンススキーマはステートメント実行をインストゥルメントします。ステートイベントイベントはイベント階層の高いレベルで発生します。待機イベントはステージイベント内にネストし、ステージイベントはステートメントイベント内にネストします。

これらのテーブルはステートメントイベントを格納します。

  • events_statements_current: 現在のステートメントイベント

  • events_statements_history: 各スレッドの最新のステートメントイベント

  • events_statements_history_long: 全体の最新のステートメントイベント

次のセクションでそれらのテーブルについて説明します。ステートメントイベントに関する情報を集計するサマリーテーブルもあります。セクション22.9.9.3「ステートメントサマリーテーブル」を参照してください。

ステートメントイベント構成

ステートメントイベントの収集を有効にするには、関連インストゥルメントとコンシューマを有効にします。

setup_instruments テーブルには、statement で始まる名前を持つインストゥルメントが格納されます。これらのインストゥルメントはデフォルトで有効にされています。

mysql> SELECT * FROM setup_instruments WHERE NAME LIKE 'statement/%';+---------------------------------------------+---------+-------+
| NAME | ENABLED | TIMED |
+---------------------------------------------+---------+-------+
| statement/sql/select | YES | YES |
| statement/sql/create_table | YES | YES |
| statement/sql/create_index | YES | YES |
...
| statement/sp/stmt | YES | YES |
| statement/sp/set | YES | YES |
| statement/sp/set_trigger_field | YES | YES |
| statement/scheduler/event | YES | YES |
| statement/com/Sleep | YES | YES |
| statement/com/Quit | YES | YES |
| statement/com/Init DB | YES | YES |
...
| statement/abstract/Query | YES | YES |
| statement/abstract/new_packet | YES | YES |
| statement/abstract/relay_log | YES | YES |
+---------------------------------------------+---------+-------+

ステートメントイベントの収集を変更するには、関連インストゥルメントの ENABLED および TIMING カラムを変更します。例:

mysql> UPDATE setup_instruments SET ENABLED = 'NO' -> WHERE NAME LIKE 'statement/com/%';

setup_consumers テーブルには現在および最近のステートメントイベントテーブル名に対応する名前を持つコンシューマ値とステートメントダイジェストコンシューマが格納されます。これらのコンシューマはステートメントイベントのコレクションとステートメントダイジェストをフィルタ処理するために使用できます。events_statements_currentstatements_digest のみがデフォルトで有効にされています。

mysql> SELECT * FROM setup_consumers WHERE NAME LIKE '%statements%';+--------------------------------+---------+
| NAME | ENABLED |
+--------------------------------+---------+
| events_statements_current | YES |
| events_statements_history | NO |
| events_statements_history_long | NO |
| statements_digest | YES |
+--------------------------------+---------+

すべてのステートメントコンシューマを有効にするには、次を実行します。

mysql> UPDATE setup_consumers SET ENABLED = 'YES' -> WHERE NAME LIKE '%statements%';

setup_timers テーブルには、ステートメントイベントのタイミングの単位を示す statementNAME 値のある行が格納されます。デフォルトの単位は NANOSECOND です。

mysql> SELECT * FROM setup_timers WHERE NAME = 'statement';+-----------+------------+
| NAME | TIMER_NAME |
+-----------+------------+
| statement | NANOSECOND |
+-----------+------------+

タイミングの単位を変更するには、TIMER_NAME 値を変更します。

mysql> UPDATE setup_timers SET TIMER_NAME = 'MICROSECOND' -> WHERE NAME = 'statement';

イベント収集の構成に関する追加情報については、セクション22.2「パフォーマンススキーマ構成」を参照してください。

ステートメントモニタリング

ステートメントのモニタリングは、サーバーがスレッドに対してアクティビティーがリクエストされていることを確認した時点から、すべてのアクティビティーが終了した時点までに開始されます。一般に、これはサーバーがクライアントから最初のパケットを受け取ったときから、サーバーが応答の送信を終了したときまでを意味します。モニタリングは、トップレベルステートメントに対してのみ行われます。ストアドプログラムとサブクエリー内のステートメントは別々に見られません。

パフォーマンススキーマがリクエスト (サーバーコマンドまたは SQL ステートメント) をインストゥルメントする場合、最終的なインストゥルメント名に到達するまで、より一般的 (または抽象的) から、より具体的へと段階を追って進むインストゥルメント名を使用します。

最終インストゥルメント名はサーバーコマンドと SQL ステートメントに対応します。

  • サーバーコマンドは mysql_com.h ヘッダーファイルに定義され、sql/sql_parse.cc で処理される COM_xxx codes に対応します。例は COM_PINGCOM_QUIT です。コマンドのインストゥルメントは、statement/com/Pingstatement/com/Quit などの statement/com から始まる名前を持ちます。

  • SQL ステートメントは DELETE FROM t1 または SELECT * FROM t2 などのテキストとして表されます。SQL ステートメントのインストゥルメントは、statement/sql/deletestatement/sql/select などの statement/sql から始まる名前を持ちます。

いくつかの最終インストゥルメント名はエラー処理に固有です。

  • statement/com/Error は帯域外のサーバーによって受信されたメッセージから構成されます。これはサーバーが理解しないクライアントによって送信されたコマンドを検出するために使用できます。これは、構成が誤っているか、サーバーよりも新しい MySQL のバージョンを使用しているクライアントや、サーバーへの攻撃を試みているクライアントの識別などの目的で役に立つことがあります。

  • statement/sql/error は解析に失敗した SQL ステートメントから構成されます。これはクライアントによって送信された不正な形式のクエリーを検出するために使用できます。解析に失敗するクエリーは、解析するが、実行中のエラーのために失敗するクエリーと異なります。たとえば、SELECT * FROM は不正な形式で、statement/sql/error インストゥルメントが使用されます。対照的に SELECT * は解析しますが、「表が指定されていません」エラーを伴って失敗します。この場合、statement/sql/select が使用され、ステートメントイベントにはエラーの性質を示す情報が含まれます。

リクエストはこれらの任意のソースから取得できます。

  • リクエストをパケットとして送信するクライアントからのコマンドまたはステートメントリクエストとして

  • レプリケーションスレーブ上のリレーログから読み取られたステートメント文字列として (MySQL 5.6.13 以降)

リクエストの詳細は最初は不明で、パフォーマンススキーマはリクエストのソースに依存する順序で、抽象から特定のインストゥルメント名に進みます。

クライアントから受信したリクエストの場合:

  1. サーバーがソケットレベルで新しいパケットを検出すると、新しいステートメントが statement/abstract/new_packet の抽象インストゥルメント名で開始されます。

  2. サーバーはパケット番号を読み取ると、受信したリクエストの種類について詳しく知り、パフォーマンススキーマがインストゥルメント名を絞り込みます。たとえば、リクエストが COM_PING パケットの場合、インストゥルメント名は statement/com/Ping になり、それが最終名になります。リクエストが COM_QUERY パケットの場合、それは SQL ステートメントに対応するが、特定のステートメントの種類ではないことがわかります。この場合、インストゥルメントはある抽象名から、やや具体的だが、まだ抽象名である statement/abstract/Query に変更され、リクエストはさらに分類する必要があります。

  3. リクエストがステートメントである場合、ステートメントテキストが読み取られ、パーサーに提供されます。解析後、正確なステートメントの種類が認識されます。リクエストがたとえば INSERT ステートメントの場合、パフォーマンススキーマはインストゥルメント名を statement/abstract/Query から最終名である statement/sql/insert に絞り込みます。

レプリケーションスレーブ上のリレーログからステートメントとして読み取られるリクエストの場合:

  1. リレーログ内のステートメントはテキストとして保存され、そのように読み取られます。ネットワークプロトコルはないため、statement/abstract/new_packet インストゥルメントは使用されません。代わりに、初期インストゥルメントは statement/abstract/relay_log になります。

  2. ステートメントが解析されると、正確なステートメントの種類が認識されます。リクエストがたとえば INSERT ステートメントの場合、パフォーマンススキーマはインストゥルメント名を statement/abstract/Query から最終名である statement/sql/insert に絞り込みます。

先述の説明はステートメントベースのレプリケーションにのみ適用されます。行ベースのレプリケーションでは、行の変更を処理しながら、スレーブで実行されるテーブル I/O をインストゥルメントできますが、リレーログ内の行イベントは、個別のステートメントとして表示されません。

ステートメントに対して収集される統計の場合、各ステートメントの種類に使用される最終 statement/sql/* インストゥルメントを有効にするだけでは十分ではありません。抽象 statement/abstract/* インストゥルメントも有効にする必要があります。すべてのステートメントインストゥルメントがデフォルトで有効にされるため、これは通常問題にならないはずです。ただし、ステートメントインストゥルメントを選択して有効または無効にするアプリケーションは、抽象インストゥルメントを無効にすると、個々のステートメントインストゥルメントの統計収集も無効になることを考慮する必要があります。たとえば、INSERT ステートメントの統計を収集するには、statement/sql/insert を有効にする必要がありますが、statement/abstract/new_packetstatement/abstract/Query も有効にする必要があります。同様に、レプリケートされたステートメントをインストゥルメントするには、statement/abstract/relay_log が有効にされている必要があります。

ステートメントが最終ステートメント名として抽象インストゥルメントに分類されることはないため、statement/abstract/Query などの抽象インストゥルメントに対して統計は集計されません。

先述の説明の抽象インストゥルメント名は MySQL 5.6.15 現在です。5.6 より前では、それらの名前が決定されるまでに、いくらかの名前の変更がありました。

  • MySQL 5.6.14 では statement/abstract/new_packetstatement/com/ で、MySQL 5.6.13 では statement/com/new_packet で、それ以前は statement/com/ でした。

  • MySQL 5.6.15 より前では、statement/abstract/Querystatement/com/Query でした。

  • MySQL 5.6.13 から 5.6.14 では statement/abstract/relay_logstatement/rpl/relay_log で、それより前は存在していませんでした。

22.9.6.1 events_statements_current テーブル

events_statements_current テーブルには、スレッドの最新のモニター対象ステートメントイベントの現在のステータスを示す、スレッドごとに 1 行で現在のステートメントイベントが格納されます。

events_statements_current テーブルは TRUNCATE TABLE で切り捨てることができます。

ステートメントイベント行を格納するテーブルのうち、events_statements_current はもっとも基本的です。ステートメントイベント行を格納するほかのテーブルは論理的に現在のイベントから派生します。たとえば、events_statements_history および events_statements_history_long テーブルは固定の行数以下の最新のステートメントイベントのコレクションです。

ステートメントイベント収集の構成については、セクション22.9.6「パフォーマンススキーマステートメントイベントテーブル」を参照してください。

events_statements_current テーブルにはこれらのカラムがあります。

  • THREAD_IDEVENT_ID

    イベントに関連付けられたスレッドとイベントの起動時のスレッドの現在のイベント番号。一緒に取得された THREAD_ID および EVENT_ID 値は、行を一意に識別する主キーを形成します。2 つの行が同じ値のペアを持つことはありません。

  • END_EVENT_ID

    このカラムは、イベントの起動時に NULL に設定され、イベントの終了時にスレッドの現在のイベント番号に更新されます。このカラムは、MySQL 5.6.4 で追加されました。

  • EVENT_NAME

    イベントが収集されたインストゥルメントの名前。これは setup_instruments テーブルからの NAME 値です。セクション22.4「パフォーマンススキーマインストゥルメント命名規則」に説明するように、インストゥルメント名には複数の部分があり、階層を形成することがあります。

    SQL ステートメントの場合、ステートメントが解析されるまで、EVENT_NAME 値は最初 statement/com/Query であり、その後セクション22.9.6「パフォーマンススキーマステートメントイベントテーブル」に説明するように、より適切な値に変更されます。

  • SOURCE

    イベントを生成した、インストゥルメントされたコードを格納するソースファイルの名前と、インストゥルメンテーションが行われたファイルの行番号。これにより、ソースをチェックして、コードに含まれるものを正確に判断することができます。

  • TIMER_STARTTIMER_ENDTIMER_WAIT

    イベントのタイミング情報。これらの値の単位はピコ秒 (秒の 1 兆分の 1) です。TIMER_START および TIMER_END 値は、イベントのタイミングが開始されたときと終了したときを示します。TIMER_WAIT はイベントの経過時間 (期間) です。

    イベントが終了していない場合、TIMER_ENDTIMER_WAITNULL です。

    イベントが TIMED = NO のインストゥルメントから生成されている場合、タイミング情報は収集されず、TIMER_STARTTIMER_END、および TIMER_WAIT はすべて NULL になります。

    イベント時間の単位としてのピコ秒および時間値に影響する要因については、セクション22.2.3.1「パフォーマンススキーマイベントタイミング」を参照してください。

  • LOCK_TIME

    テーブルロックの待機に費やされた時間。この値はマイクロ秒で計算されますが、ほかのパフォーマンススキーマタイマーとの比較を容易にするため、ピコ秒に正規化されます。

  • SQL_TEXT

    SQL ステートメントのテキスト。SQL ステートメントに関連付けられていないコマンドの場合、値は NULL です。

  • DIGEST

    32 個の 16 進文字の文字列としてのステートメントダイジェスト MD5 値または statement_digest コンシューマが no の場合は NULL。ステートメントダイジェストの詳細については、セクション22.7「パフォーマンススキーマステートメントダイジェスト」を参照してください。このカラムは、MySQL 5.6.5 で追加されました。

  • DIGEST_TEXT

    正規化されたステートメントダイジェストテキストまたは statement_digest コンシューマが no の場合は NULL。ステートメントダイジェストの詳細については、セクション22.7「パフォーマンススキーマステートメントダイジェスト」を参照してください。このカラムは、MySQL 5.6.5 で追加されました。

  • CURRENT_SCHEMA

    ステートメントのデフォルトのデータベース、何もない場合は NULL

  • OBJECT_SCHEMAOBJECT_NAMEOBJECT_TYPE

    予約済み。現在は NULL

  • OBJECT_INSTANCE_BEGIN

    このカラムはステートメントを識別します。この値はメモリー内のオブジェクトのアドレスです。

  • MYSQL_ERRNO

    ステートメント診断領域からのステートメントエラー番号。

  • RETURNED_SQLSTATE

    ステートメント診断領域からのステートメント SQLSTATE 値。

  • MESSAGE_TEXT

    ステートメント診断領域からのステートメントエラーメッセージ。

  • ERRORS

    ステートメントにエラーが発生したかどうか。SQLSTATE 値が 00 (完了) または 01 (警告) から始まる場合、値は 0 です。SQLSTATE 値がほかの値の場合、値は 1 です。

  • WARNINGS

    ステートメント診断領域からの警告数。

  • ROWS_AFFECTED

    ステートメントに影響を受けた行数。影響を受けたの意味については、セクション23.8.7.1「mysql_affected_rows()」を参照してください。

  • ROWS_SENT

    ステートメントから返された行数。

  • ROWS_EXAMINED

    ステートメント実行中にストレージエンジンから読み取られた行数。

  • CREATED_TMP_DISK_TABLES

    Created_tmp_disk_tables ステータス変数と同様ですが、ステートメントに固有です。

  • CREATED_TMP_TABLES

    Created_tmp_tables ステータス変数と同様ですが、ステートメントに固有です。

  • SELECT_FULL_JOIN

    Select_full_join ステータス変数と同様ですが、ステートメントに固有です。

  • SELECT_FULL_RANGE_JOIN

    Select_full_range_join ステータス変数と同様ですが、ステートメントに固有です。

  • SELECT_RANGE

    Select_range ステータス変数と同様ですが、ステートメントに固有です。

  • SELECT_RANGE_CHECK

    Select_range_check ステータス変数と同様ですが、ステートメントに固有です。

  • SELECT_SCAN

    Select_scan ステータス変数と同様ですが、ステートメントに固有です。

  • SORT_MERGE_PASSES

    Sort_merge_passes ステータス変数と同様ですが、ステートメントに固有です。

  • SORT_RANGE

    Sort_range ステータス変数と同様ですが、ステートメントに固有です。

  • SORT_ROWS

    Sort_rows ステータス変数と同様ですが、ステートメントに固有です。

  • SORT_SCAN

    Sort_scan ステータス変数と同様ですが、ステートメントに固有です。

  • NO_INDEX_USED

    ステートメントがインデックスを使用せずにテーブルスキャンを実行した場合は 1、そうでない場合は 0。

  • NO_GOOD_INDEX_USED

    サーバーがステートメントに使用する適切なインデックスを見つけられなかった場合は 1、そうでない場合は 0。追加の情報については、セクション8.8.2「EXPLAIN 出力フォーマット」で、EXPLAIN 出力の Extra カラムの Range checked for each record 値の説明を参照してください。

  • NESTING_EVENT_IDNESTING_EVENT_TYPE

    予約済み。現在は NULL

events_statements_current テーブルは MySQL 5.6.3 で追加されました。

22.9.6.2 events_statements_history テーブル

events_statements_history テーブルには、スレッドごとの最新の N ステートメントイベントが格納されます。N の値はサーバー起動時に自動サイズ設定されます。テーブルサイズを明示的に設定するには、サーバー起動時に performance_schema_events_statements_history_size システム変数を設定します。ステートメントイベントは終了するまでテーブルに追加されません。新しいイベントが追加されたときに、テーブルがいっぱいである場合、古いイベントが破棄されます。

events_statements_history テーブルは events_statements_current と同じ構造を持ちます。セクション22.9.6.1「events_statements_current テーブル」を参照してください。

events_statements_history テーブルは TRUNCATE TABLE で切り捨てることができます。

events_statements_history テーブルは MySQL 5.6.3 で追加されました。

ステートメントイベント収集の構成については、セクション22.9.6「パフォーマンススキーマステートメントイベントテーブル」を参照してください。

22.9.6.3 events_statements_history_long テーブル

events_statements_history_long テーブルには、最新の N ステートメントイベントが格納されます。N の値はサーバー起動時に自動サイズ設定されます。テーブルサイズを明示的に設定するには、サーバー起動時に performance_schema_events_statements_history_long_size システム変数を設定します。ステートメントイベントは終了するまでテーブルに追加されません。新しいイベントが追加されたときに、テーブルがいっぱいである場合、古いイベントが破棄されます。

events_statements_history_long テーブルは events_statements_current と同じ構造を持ちます。セクション22.9.6.1「events_statements_current テーブル」を参照してください。

events_statements_history_long テーブルは TRUNCATE TABLE で切り捨てることができます。

events_statements_history_long テーブルは MySQL 5.6.3 で追加されました。

ステートメントイベント収集の構成については、セクション22.9.6「パフォーマンススキーマステートメントイベントテーブル」を参照してください。

22.9.7 パフォーマンススキーマ接続テーブル

MySQL 5.6.3 以降、パフォーマンススキーマはサーバーへの接続に関する統計を提供します。クライアントが接続する場合、特定のユーザー名で特定のホストからそれを行います。パフォーマンススキーマは、これらのテーブルを使用して、アカウント (ユーザー名とホスト名) ごとに、およびユーザー名ごととホスト名ごとの個別に、接続を追跡します。

  • accounts: クライアントアカウントごとの接続統計

  • hosts: クライアントホスト名ごとの接続統計

  • users: クライアントユーザー名ごとの接続統計

接続に関する情報を集計するサマリーテーブルもあります。セクション22.9.9.7「接続サマリーテーブル」を参照してください。

接続テーブルでのアカウントの意味は、その用語がユーザーとホスト値の組み合わせを表すという点で、mysql データベース内の MySQL 付与テーブルでのその意味に似ています。付与テーブルでそれらが異なる点は、アカウントのホスト部分をパターンにできるのに対し、接続テーブルではホスト値は常に固有の非パターンホスト名であることです。

接続テーブルにはすべて CURRENT_CONNECTIONS および TOTAL_CONNECTIONS カラムがあり、統計が基づく追跡値ごとの現在と合計の接続数を追跡します。テーブルは、それらが追跡値に使用するものに違いがあります。accounts テーブルには USER および HOST カラムがあり、ユーザー名とホスト名の組み合わせごとに接続を追跡します。users および hosts テーブルには USER および HOST カラムがあり、それぞれユーザー名ごとおよびホスト名ごとに接続を追跡します。

user1user2 というクライアントがそれぞれ hostahostb から一度に接続するとします。パフォーマンススキーマは次のように接続を追跡します。

  • accounts テーブルには、user1/hostauser1/hostbuser2/hosta、および user2/hostb アカウント値の 4 つの行があり、各行はアカウントごとに 1 つの接続をカウントします。

  • users テーブルには、user1user2 値の 2 つの行があり、各行はユーザー名ごとに 2 つの接続をカウントします。

  • hosts テーブルには、hostahostb 値の 2 つの行があり、各行はホスト名ごとに 2 つの接続をカウントします。

クライアントが接続すると、パフォーマンススキーマは、各テーブルに該当する追跡値を使用して、接続に適用する各接続テーブル内の行を判断します。そのような行がない場合、追加されます。次に、パフォーマンススキーマはその行の CURRENT_CONNECTIONS および TOTAL_CONNECTIONS カラムを 1 つ増分します。

クライアントが切断すると、パフォーマンススキーマはその行の CURRENT_CONNECTIONS カラムを 1 つ減分し、TOTAL_CONNECTIONS カラムは変更しないままにします。

パフォーマンススキーマは内部スレッドと認証に失敗したユーザーセッションのスレッドもカウントします。これらは、NULL の値の USER および HOST カラムのある行でカウントされます。

各接続テーブルは TRUNCATE TABLE で切り捨てることができ、次の効果があります。

  • CURRENT_CONNECTIONS = 0 の行が削除されます。

  • CURRENT_CONNECTIONS > 0 の行で、TOTAL_CONNECTIONSCURRENT_CONNECTIONS にリセットされます。

  • 接続テーブルに依存する接続サマリーテーブルは暗黙的に切り捨てられます (サマリー値は 0 に設定されます)。暗黙的な切り捨ての詳細については、セクション22.9.9.7「接続サマリーテーブル」を参照してください。

22.9.7.1 accounts テーブル

accounts テーブルは、MySQL サーバーに接続した各アカウントの行を格納します。各アカウントについて、テーブルは現在と合計の接続数をカウントします。テーブルサイズはサーバー起動時に自動サイズ設定されます。テーブルサイズを明示的に設定するには、サーバー起動時に performance_schema_accounts_size システム変数を設定します。アカウント統計を無効にするには、この変数を 0 に設定します。

accounts テーブルには次のカラムがあります。TRUNCATE TABLE の効果を含む、パフォーマンススキーマがこのテーブルの行を保守する方法については、セクション22.9.7「パフォーマンススキーマ接続テーブル」を参照してください。

  • USER

    接続のクライアントユーザー名、または内部スレッドまたは認証に失敗したユーザーセッションの場合 NULL

  • HOST

    クライアントの接続元のホスト名、または内部スレッドまたは認証に失敗したユーザーセッションの場合 NULL

  • CURRENT_CONNECTIONS

    アカウントの現在の接続数。

  • TOTAL_CONNECTIONS

    アカウントの合計の接続数。

accounts テーブルは MySQL 5.6.3 で追加されました。

22.9.7.2 hosts テーブル

hosts テーブルは、クライアントが MySQL サーバーに接続している各ホストの行を格納します。各ホスト名について、テーブルは現在と合計の接続数をカウントします。テーブルサイズはサーバー起動時に自動サイズ設定されます。テーブルサイズを明示的に設定するには、サーバー起動時に performance_schema_hosts_size システム変数を設定します。ホスト統計を無効にするには、この変数を 0 に設定します。

hosts テーブルには次のカラムがあります。TRUNCATE TABLE の効果を含む、パフォーマンススキーマがこのテーブルの行を保守する方法については、セクション22.9.7「パフォーマンススキーマ接続テーブル」を参照してください。

  • HOST

    クライアントの接続元のホスト名、または内部スレッドまたは認証に失敗したユーザーセッションの場合 NULL

  • CURRENT_CONNECTIONS

    ホストの現在の接続数。

  • TOTAL_CONNECTIONS

    ホストの合計の接続数。

hosts テーブルは MySQL 5.6.3 で追加されました。

22.9.7.3 users テーブル

users テーブルは、MySQL サーバーに接続している各ユーザーの行を格納します。各ユーザー名について、テーブルは現在と合計の接続数をカウントします。テーブルサイズはサーバー起動時に自動サイズ設定されます。テーブルサイズを明示的に設定するには、サーバー起動時に performance_schema_users_size システム変数を設定します。ユーザー統計を無効にするには、この変数を 0 に設定します。

users テーブルには次のカラムがあります。TRUNCATE TABLE の効果を含む、パフォーマンススキーマがこのテーブルの行を保守する方法については、セクション22.9.7「パフォーマンススキーマ接続テーブル」を参照してください。

  • USER

    接続のクライアントユーザー名、または内部スレッドまたは認証に失敗したユーザーセッションの場合 NULL

  • CURRENT_CONNECTIONS

    ユーザーの現在の接続数。

  • TOTAL_CONNECTIONS

    ユーザーの合計の接続数。

users テーブルは MySQL 5.6.3 で追加されました。

22.9.8 パフォーマンススキーマ接続属性テーブル

MySQL 5.6.6 以降、アプリケーションプログラムでは、mysql_options() および mysql_options4() C API 関数を使用して、接続時にサーバーに渡されるキー/値接続属性を提供できます。パフォーマンススキーマはこれらのテーブルからこの情報を公開します。

  • session_account_connect_attrs: 現在のアカウントのセッションの接続属性。

  • session_connect_attrs: すべてのセッションの接続属性。

22.9.8.1 session_account_connect_attrs テーブル

MySQL 5.6.6 以降、アプリケーションプログラムでは、mysql_options() および mysql_options4() C API 関数を使用して、接続時にサーバーに渡されるキー/値接続属性を提供できます。

session_account_connect_attrs テーブルは、自分のアカウントに対してオープンしているセッションの接続属性のみを格納します。すべてのセッションの接続属性を確認するには、session_connect_attrs テーブルを調べてください。

session_account_connect_attrs テーブルは、これらのカラムを格納します。

  • PROCESSLIST_ID

    セッションの接続識別子。

  • ATTR_NAME

    属性名。

  • ATTR_VALUE

    属性値。

  • ORDINAL_POSITION

    属性が一連の接続属性に追加された順序。

22.9.8.2 session_connect_attrs テーブル

MySQL 5.6.6 以降、アプリケーションプログラムでは、mysql_options() および mysql_options4() C API 関数を使用して、接続時にサーバーに渡されるキー/値接続属性を提供できます。

session_connect_attrs テーブルはすべてのセッションの接続属性を格納します。自分のアカウントに対してオープンしているセッションの接続属性のみを確認するには、session_account_connect_attrs テーブルを調べてください。

session_connect_attrs テーブルは、これらのカラムを格納します。

  • PROCESSLIST_ID

    セッションの接続識別子。

  • ATTR_NAME

    属性名。

  • ATTR_VALUE

    属性値。

  • ORDINAL_POSITION

    属性が一連の接続属性に追加された順序。

22.9.9 パフォーマンススキーマサマリーテーブル

サマリーテーブルは、時間の経過とともに強制終了されたイベントについて集計された情報を提供します。このグループのテーブルには、さまざまな方法で、イベントデータが要約されます。

イベント待機サマリー:

  • events_waits_summary_global_by_event_name: イベント名ごとに要約された待機イベント

  • events_waits_summary_by_instance: インスタンスごとに要約された待機イベント

  • events_waits_summary_by_thread_by_event_name: スレッドおよびイベント名ごとに要約された待機イベント

ステージサマリー:

  • events_stages_summary_by_thread_by_event_name: スレッドおよびイベント名ごとに要約されたステージ待機

  • events_stages_summary_global_by_event_name: イベント名ごとに要約されたステージ待機

ステートメントサマリー:

  • events_statements_summary_by_digest: スキーマおよびダイジェスト値ごとに要約されたステートメントイベント

  • events_statements_summary_by_thread_by_event_name: スレッドおよびイベント名ごとに要約されたステートメントイベント

  • events_statements_summary_global_by_event_name: イベント名ごとに要約されたステートメントイベント

オブジェクト待機サマリー:

  • objects_summary_global_by_type: オブジェクトサマリー

ファイル I/O サマリー:

  • file_summary_by_event_name: イベント名ごとに要約されたファイルイベント

  • file_summary_by_instance: ファイルインスタンスごとに要約されたファイルイベント

テーブル I/O およびロック待機サマリー:

  • table_io_waits_summary_by_index_usage: インデックスごとのテーブル I/O 待機

  • table_io_waits_summary_by_table: テーブルごとのテーブル I/O 待機

  • table_lock_waits_summary_by_table: テーブルごとのテーブルロック待機

接続サマリー:

  • events_waits_summary_by_account_by_event_name: アカウントおよびイベント名ごとに要約された待機イベント

  • events_waits_summary_by_user_by_event_name: ユーザー名およびイベント名ごとに要約された待機イベント

  • events_waits_summary_by_host_by_event_name: ホスト名およびイベント名ごとに要約された待機イベント

  • events_stages_summary_by_account_by_event_name: アカウントおよびイベント名ごとに要約されたステージイベント

  • events_stages_summary_by_user_by_event_name: ユーザー名およびイベント名ごとに要約されたステージイベント

  • events_stages_summary_by_host_by_event_name: ホスト名およびイベント名ごとに要約されたステージイベント

  • events_statements_summary_by_digest: スキーマおよびダイジェスト値ごとに要約されたステートメントイベント

  • events_statements_summary_by_account_by_event_name: アカウントおよびイベント名ごとに要約されたステートメントイベント

  • events_statements_summary_by_user_by_event_name: ユーザー名およびイベント名ごとに要約されたステートメントイベント

  • events_statements_summary_by_host_by_event_name: ホスト名およびイベント名ごとに要約されたステートメントイベント

ソケットサマリー:

  • socket_summary_by_instance: インスタンスごとに要約されたソケット待機および I/O

  • socket_summary_by_event_name: イベント名ごとに要約されたソケット待機および I/O

各サマリーテーブルには、集計するデータのグループ化の方法を決定するグループ化カラムと、集計値を格納するサマリーカラムがあります。同様の方法でイベントを要約するテーブルには、多くの場合に類似の一連のサマリーカラムがあり、イベントの集計方法を決定するために使用されるグループ化カラムのみ異なります。

サマリーテーブルは TRUNCATE TABLE で切り捨てることができます。events_statements_summary_by_digest を除き、その効果は、サマリーカラムを 0 または NULL にリセットすることで、行を削除することではありません。これにより、収集された値をクリアし、アグリゲーションを再開できます。それは、実行時構成の変更を行なったあとなどに便利な場合があります。

22.9.9.1 イベント待機サマリーテーブル

パフォーマンススキーマは現在および最近の待機イベントを収集するためのテーブルを保守し、その情報をサマリーテーブルに集計します。セクション22.9.4「パフォーマンススキーマ待機イベントテーブル」に待機サマリーが基づいているイベントについて説明しています。待機イベントの内容、現在および最近の待機イベントテーブル、および待機イベント収集の制御方法に関する情報については、その説明を参照してください。

各イベント待機サマリーテーブルには、テーブルのイベントの集計方法を示す 1 つまたは複数のグループ化カラムがあります。イベント名は、setup_instruments テーブル内のイベントインストゥルメントの名前を表します。

  • events_waits_summary_global_by_event_name には EVENT_NAME カラムがあります。各行は特定のイベント名のイベントを要約します。インストゥルメントを使用して、インストゥルメントされるオブジェクトの複数のインスタンスを作成できます。たとえば、接続ごとに作成される相互排他ロックのインストゥルメントがある場合、接続と同じ数のインスタンスがあります。インストゥルメントのサマリー行は、これらのすべてのインスタンス全体を要約します。

  • events_waits_summary_by_instance には EVENT_NAME および OBJECT_INSTANCE_BEGIN カラムがあります。各行は特定のイベント名とオブジェクトのイベントを要約します。複数のインスタンスを作成するためにインストゥルメントが使用される場合、各インスタンスには一意の OBJECT_INSTANCE_BEGIN 値があるため、これらのインスタンスはこのテーブルで個別に要約されます。

  • events_waits_summary_by_thread_by_event_name には THREAD_ID および EVENT_NAME カラムがあります。各行は特定のスレッドおよびイベント名のイベントを要約します。

すべてのイベント待機サマリーテーブルには、集計された値を格納するこれらのサマリーカラムがあります。

  • COUNT_STAR

    要約されたイベントの数。この値には、時間付きか時間なしかに関係なく、すべてのイベントが含まれます。

  • SUM_TIMER_WAIT

    要約された時間付きイベントの合計待機時間。時間なしイベントは NULL の待機時間を持つため、この値は時間付きイベントに対してのみ計算されます。同じことがほかの xxx_TIMER_WAIT 値にも当てはまります。

  • MIN_TIMER_WAIT

    要約された時間付きイベントの最小待機時間。

  • AVG_TIMER_WAIT

    要約された時間付きイベントの平均待機時間。

  • MAX_TIMER_WAIT

    要約された時間付きイベントの最大待機時間。

待機イベントサマリー情報の例:

mysql> SELECT * FROM events_waits_summary_global_by_event_name\G...
*************************** 6. row *************************** EVENT_NAME: wait/synch/mutex/sql/BINARY_LOG::LOCK_index COUNT_STAR: 8
SUM_TIMER_WAIT: 2119302
MIN_TIMER_WAIT: 196092
AVG_TIMER_WAIT: 264912
MAX_TIMER_WAIT: 569421
...
*************************** 9. row *************************** EVENT_NAME: wait/synch/mutex/sql/hash_filo::lock COUNT_STAR: 69
SUM_TIMER_WAIT: 16848828
MIN_TIMER_WAIT: 0
AVG_TIMER_WAIT: 244185
MAX_TIMER_WAIT: 735345
...

TRUNCATE TABLE は待機サマリーテーブルに使用できます。それは、行を削除するのではなく、サマリーカラムを 0 にリセットします。

22.9.9.2 ステージサマリーテーブル

MySQL 5.6.3 以降、パフォーマンススキーマは現在および最近のステージイベントを収集するためのテーブルを保守し、その情報をサマリーテーブルに集計します。セクション22.9.5「パフォーマンススキーマステージイベントテーブル」で、ステージサマリーが基づいているイベントについて説明しています。ステージイベントの内容、現在および最近のステージイベントテーブル、およびステージイベント収集の制御方法に関する情報については、その説明を参照してください。

各ステージサマリーテーブルには、テーブルのイベントの集計方法を示す 1 つまたは複数のグループ化カラムがあります。イベント名は、setup_instruments テーブル内のイベントインストゥルメントの名前を表します。

  • events_stages_summary_by_thread_by_event_name には THREAD_ID および EVENT_NAME カラムがあります。各行は特定のスレッドおよびイベント名のイベントを要約します。

  • events_stages_summary_global_by_event_name には EVENT_NAME カラムがあります。各行は特定のイベント名のイベントを要約します。

すべてのステージサマリーテーブルには、集計された値を格納するこれらのサマリーカラムがあります。COUNT_STARSUM_TIMER_WAITMIN_TIMER_WAIT, AVG_TIMER_WAIT、および MAX_TIMER_WAIT。ステージサマリーテーブルでは、events_waits_current ではなく events_stages_current から待機を集計することを除き、これらのカラムはイベント待機サマリーテーブル (セクション22.9.9.1「イベント待機サマリーテーブル」を参照) の同じ名前のカラムに似ています。

ステージイベントサマリー情報の例:

mysql> SELECT * FROM events_stages_summary_global_by_event_name\G...
*************************** 5. row *************************** EVENT_NAME: stage/sql/checking permissions COUNT_STAR: 57
SUM_TIMER_WAIT: 26501888880
MIN_TIMER_WAIT: 7317456
AVG_TIMER_WAIT: 464945295
MAX_TIMER_WAIT: 12858936792
...
*************************** 9. row *************************** EVENT_NAME: stage/sql/closing tables COUNT_STAR: 37
SUM_TIMER_WAIT: 662606568
MIN_TIMER_WAIT: 1593864
AVG_TIMER_WAIT: 17907891
MAX_TIMER_WAIT: 437977248
...

TRUNCATE TABLE はステージサマリーテーブルに使用できます。それは、行を削除するのではなく、サマリーカラムを 0 にリセットします。

22.9.9.3 ステートメントサマリーテーブル

MySQL 5.6.3 以降、パフォーマンススキーマは現在および最近のステートメントイベントを集計するためのテーブルを保守し、その情報をサマリーテーブルに集計します。セクション22.9.6「パフォーマンススキーマステートメントイベントテーブル」で、ステートメントサマリーが基づいているイベントについて説明しています。ステートメントイベントの内容、現在および最近のステートメントイベントテーブル、およびステートメントイベント収集の制御方法に関する情報については、その説明を参照してください。

各ステートメントサマリーテーブルには、テーブルのイベントの集計方法を示す 1 つまたは複数のグループ化カラムがあります。イベント名は、setup_instruments テーブル内のイベントインストゥルメントの名前を表します。

  • events_statements_summary_by_digest には SCHEMA_NAME および DIGEST カラムがあります。各行は特定のスキーマ/ダイジェスト値のイベントを要約します。( DIGEST_TEXT カラムは、対応する正規化されたステートメントダイジェストテキストを格納しますが、グループ化カラムでもサマリーカラムでもありません。)

    このテーブルは、5.6.5 で追加されました。MySQL 5.6.9 より前では、SCHEMA_NAME カラム値がなく、グループ化は DIGEST 値のみに基づきます。

  • events_statements_summary_by_thread_by_event_name には THREAD_ID および EVENT_NAME カラムがあります。各行は特定のスレッドおよびイベント名のイベントを要約します。

  • events_statements_summary_global_by_event_name には EVENT_NAME カラムがあります。各行は特定のイベント名のイベントを要約します。

すべてのステートメントサマリーテーブルには、集計された値を格納するこれらのサマリーカラムがあります。

  • COUNT_STARSUM_TIMER_WAITMIN_TIMER_WAITAVG_TIMER_WAITMAX_TIMER_WAIT

    ステートメントサマリーテーブルは、events_waits_current ではなく events_statements_current からイベントを集計することを除き、これらのカラムはイベント待機サマリーテーブル (セクション22.9.9.1「イベント待機サマリーテーブル」を参照) の同じ名前のカラムに似ています。

  • SUM_xxx

    events_statements_current テーブル内の対応する xxx カラムの集計。たとえば、ステートメントサマリーテーブルの SUM_LOCK_TIME および SUM_ERRORS カラムは events_statements_current テーブルの LOCK_TIME および ERRORS カラムの集計です。

events_statements_summary_by_digest テーブルにはこれらの追加のサマリーカラムがあります。

  • FIRST_SEEN_TIMESTAMPLAST_SEEN_TIMESTAMP

    特定のダイジェスト値を持つステートメントが最初に確認された時間と最後に確認された時間。

ステートメントイベントサマリー情報の例:

mysql> SELECT * FROM events_statements_summary_global_by_event_name\G*************************** 1. row *************************** EVENT_NAME: statement/sql/select COUNT_STAR: 25 SUM_TIMER_WAIT: 1535983999000 MIN_TIMER_WAIT: 209823000 AVG_TIMER_WAIT: 61439359000 MAX_TIMER_WAIT: 1363397650000 SUM_LOCK_TIME: 20186000000 SUM_ERRORS: 0 SUM_WARNINGS: 0 SUM_ROWS_AFFECTED: 0 SUM_ROWS_SENT: 388 SUM_ROWS_EXAMINED: 370
SUM_CREATED_TMP_DISK_TABLES: 0 SUM_CREATED_TMP_TABLES: 0 SUM_SELECT_FULL_JOIN: 0 SUM_SELECT_FULL_RANGE_JOIN: 0 SUM_SELECT_RANGE: 0 SUM_SELECT_RANGE_CHECK: 0 SUM_SELECT_SCAN: 6 SUM_SORT_MERGE_PASSES: 0 SUM_SORT_RANGE: 0 SUM_SORT_ROWS: 0 SUM_SORT_SCAN: 0 SUM_NO_INDEX_USED: 6 SUM_NO_GOOD_INDEX_USED: 0
...

TRUNCATE TABLE はステートメントサマリーテーブルに使用できます。events_statements_summary_by_digest に対して、それはテーブルを空にします。ほかのステートメントサマリーテーブルに対して、それは行を削除するのではなく、サマリーカラムを 0 にリセットします。

ステートメントダイジェストアグリゲーションルール

statement_digest コンシューマを有効にすると、ステートメントの完了時に、events_statements_summary_by_digest へのアグリゲーションが次のように行われます。アグリゲーションはステートメントに対して計算された DIGEST 値に基づきます。

  • 完了したばかりのステートメントのダイジェスト値のある events_statements_summary_by_digest 行がすでに存在する場合、ステートメントの統計はその行に集計されます。LAST_SEEN カラムは現在の時間に更新されます。

  • 完了したばかりのステートメントのダイジェスト値のある行がなく、テーブルがいっぱいでない場合、そのステートメントに対して新しい行が作成されます。FIRST_SEEN および LAST_SEEN カラムは現在の時間で初期化されます。

  • 完了したばかりのステートメントのステートメントダイジェスト値のある行がなく、テーブルがいっぱいである場合、完了したばかりのステートメントの統計が、必要に応じて作成される特別な多目的行に、DIGEST = NULL で追加されます。この行が作成された場合、FIRST_SEEN および LAST_SEEN カラムは現在の時間で初期化されます。そうでない場合、LAST_SEEN カラムが現在の時間で更新されます。

パフォーマンススキーマテーブルには、メモリー制約による最大サイズがあるため、DIGEST = NULL の行は保守されます。DIGEST = NULL 行は、ほかの行に一致しないダイジェストが、サマリーテーブルがいっぱいである場合でも、共通のほかのバケットを使用して、カウントされることを許可します。この行は、ダイジェストサマリーが代表的であるかどうかを推定するのに役立ちます。

  • すべてのダイジェストのうち 5% を表す COUNT_STAR 値がある DIGEST = NULL 行は、ダイジェストサマリーテーブルがきわめて代表的であることを示します。ほかの行が、存在するステートメントの 95% を占めます。

  • すべてのダイジェストのうち 50% を表す COUNT_STAR 値がある DIGEST = NULL 行は、ダイジェストサマリーテーブルがあまり代表的でないことを示します。ほかの行は、存在するステートメントの半分しか占めません。たいていの場合に DBA は DIGEST = NULL 行にカウントされる行の多くが、代わりにより具体的な行を使用してカウントされるように、最大テーブルサイズを拡大するべきです。これを実行するには、サーバーの起動時に、performance_schema_digests_size システム変数を大きな値に設定します。デフォルトサイズは 200 です。

22.9.9.4 オブジェクト待機サマリーテーブル

objects_summary_global_by_type テーブルはオブジェクト待機イベントを集計します。これにはテーブルのイベントの集計方法を示すグループ化カラム OBJECT_TYPEOBJECT_SCHEMA、および OBJECT_NAME があります。各行は特定のオブジェクトのイベントを要約します。

objects_summary_global_by_type には events_waits_summary_by_xxx テーブルと同じサマリーカラムがあります。セクション22.9.9.1「イベント待機サマリーテーブル」を参照してください。

オブジェクト待機イベントサマリー情報の例:

mysql> SELECT * FROM objects_summary_global_by_type\G...
*************************** 3. row *************************** OBJECT_TYPE: TABLE OBJECT_SCHEMA: test OBJECT_NAME: t COUNT_STAR: 3
SUM_TIMER_WAIT: 263126976
MIN_TIMER_WAIT: 1522272
AVG_TIMER_WAIT: 87708678
MAX_TIMER_WAIT: 258428280
...
*************************** 10. row *************************** OBJECT_TYPE: TABLE OBJECT_SCHEMA: mysql OBJECT_NAME: user COUNT_STAR: 14
SUM_TIMER_WAIT: 365567592
MIN_TIMER_WAIT: 1141704
AVG_TIMER_WAIT: 26111769
MAX_TIMER_WAIT: 334783032
...

TRUNCATE TABLE はオブジェクトサマリーテーブルに使用できます。それは、行を削除するのではなく、サマリーカラムを 0 にリセットします。

22.9.9.5 ファイル I/O サマリーテーブル

ファイル I/O サマリーテーブルは I/O 操作に関する情報を集計します。

各ファイル I/O サマリーテーブルには、テーブルのイベントの集計方法を示す 1 つまたは複数のグループ化カラムがあります。イベント名は、setup_instruments テーブル内のイベントインストゥルメントの名前を表します。

  • file_summary_by_event_name には EVENT_NAME カラムがあります。各行は特定のイベント名のイベントを要約します。

  • file_summary_by_instance には FILE_NAMEEVENT_NAME、および (MySQL 5.6.4 現在) OBJECT_INSTANCE_BEGIN カラムがあります。各行は特定のファイルおよびイベント名のイベントを要約します。

すべてのファイル I/O サマリーテーブルには、集計された値を格納する次のサマリーカラムがあります。(MySQL 5.6.4 より前では、テーブルに COUNT_READCOUNT_WRITESUM_NUMBER_OF_BYTES_READ、および SUM_NUMBER_OF_BYTES_WRITE アグリゲーションカラムのみが格納されます。)一部のカラムは一般的で、より詳細なカラムの値の合計と同じ値を持ちます。このように、低レベルカラムを合計するユーザー定義ビューを必要とせずに、高レベルでのアグリゲーションを直接取得できます。

  • COUNT_STARSUM_TIMER_WAITMIN_TIMER_WAITAVG_TIMER_WAITMAX_TIMER_WAIT

    これらのカラムはすべての I/O 操作を集計します。

  • COUNT_READSUM_TIMER_READMIN_TIMER_READAVG_TIMER_READMAX_TIMER_READSUM_NUMBER_OF_BYTES_READ

    これらのカラムは FGETSFGETCFREAD、および READ を含むすべての読み取り操作を集計します。

  • COUNT_WRITESUM_TIMER_WRITEMIN_TIMER_WRITEAVG_TIMER_WRITEMAX_TIMER_WRITESUM_NUMBER_OF_BYTES_WRITE

    これらのカラムは FPUTSFPUTCFPRINTFVFPRINTFFWRITE、および PWRITE を含むすべての書き込み操作を集計します。

  • COUNT_MISCSUM_TIMER_MISCMIN_TIMER_MISCAVG_TIMER_MISCMAX_TIMER_MISC

    これらのカラムは CREATEDELETEOPENCLOSESTREAM_OPENSTREAM_CLOSESEEKTELLFLUSHSTATFSTATCHSIZERENAME、および SYNC を含むその他のすべての I/O 操作を集計します。これらの操作のバイトカウントはありません。

ファイル I/O イベントサマリー情報の例:

mysql> SELECT * FROM file_summary_by_event_name\G...
*************************** 2. row *************************** EVENT_NAME: wait/io/file/sql/binlog COUNT_STAR: 31 SUM_TIMER_WAIT: 8243784888 MIN_TIMER_WAIT: 0 AVG_TIMER_WAIT: 265928484 MAX_TIMER_WAIT: 6490658832
...
mysql> SELECT * FROM file_summary_by_instance\G...
*************************** 2. row *************************** FILE_NAME: /var/mysql/share/english/errmsg.sys EVENT_NAME: wait/io/file/sql/ERRMSG EVENT_NAME: wait/io/file/sql/ERRMSG OBJECT_INSTANCE_BEGIN: 4686193384 COUNT_STAR: 5 SUM_TIMER_WAIT: 13990154448 MIN_TIMER_WAIT: 26349624 AVG_TIMER_WAIT: 2798030607 MAX_TIMER_WAIT: 8150662536
...

TRUNCATE TABLE はファイル I/O サマリーテーブルに使用できます。それは、行を削除するのではなく、サマリーカラムを 0 にリセットします。

MySQL サーバーは、いくつかの技法を使用して、ファイルから読み取られた情報をキャッシュすることによって I/O 操作を回避するため、I/O イベントが発生すると予想されるようなステートメントでも発生しない可能性があります。キャッシュをフラッシュするか、サーバーを再起動して、その状態をリセットすることによって、I/O を発生させることができる場合があります。

22.9.9.6 テーブル I/O およびロック待機サマリーテーブル

次のセクションでは、テーブル I/O およびロック待機サマリーテーブルについて説明します。

  • table_io_waits_summary_by_index_usage: インデックスごとのテーブル I/O 待機

  • table_io_waits_summary_by_table: テーブルごとのテーブル I/O 待機

  • table_lock_waits_summary_by_table: テーブルごとのテーブルロック待機

22.9.9.6.1 table_io_waits_summary_by_table テーブル

table_io_waits_summary_by_table テーブルは、wait/io/table/sql/handler インストゥルメントによって生成されるすべてのテーブル I/O 待機イベントを集計します。グループ化はテーブル単位です。

table_io_waits_summary_by_table テーブルには、テーブルのイベントの集計方法を示すこれらのグループ化カラムがあります。OBJECT_TYPEOBJECT_SCHEMA、および OBJECT_NAME。これらのカラムは、events_waits_current テーブル内と同じ意味を持ちます。それらは、行の適用先のテーブルを識別します。

table_io_waits_summary_by_table には集計された値を格納する次のサマリーカラムがあります。カラムの説明に示すように、一部のカラムは一般的で、より詳細なカラムの値の合計と同じ値を持ちます。たとえば、すべての書き込みを集計するカラムは、挿入、更新、および削除を集計する対応するカラムの合計を保持します。このように、低レベルカラムを合計するユーザー定義ビューを必要とせずに、高レベルでのアグリゲーションを直接取得できます。

  • COUNT_STARSUM_TIMER_WAITMIN_TIMER_WAITAVG_TIMER_WAITMAX_TIMER_WAIT

    これらのカラムはすべての I/O 操作を集計します。それらは対応する xxx_READ および xxx_WRITE カラムの合計と同じです。

  • COUNT_READSUM_TIMER_READMIN_TIMER_READAVG_TIMER_READMAX_TIMER_READ

    これらのカラムはすべての読み取り操作を集計します。それらは対応する xxx_FETCH カラムの合計と同じです。

  • COUNT_WRITESUM_TIMER_WRITEMIN_TIMER_WRITEAVG_TIMER_WRITEMAX_TIMER_WRITE

    これらのカラムはすべての書き込み操作を集計します。それらは対応する xxx_INSERTxxx_UPDATE、および xxx_DELETE カラムの合計と同じです。

  • COUNT_FETCHSUM_TIMER_FETCHMIN_TIMER_FETCHAVG_TIMER_FETCHMAX_TIMER_FETCH

    これらのカラムはすべてのフェッチ操作を集計します。

  • COUNT_INSERTSUM_TIMER_INSERTMIN_TIMER_INSERTAVG_TIMER_INSERTMAX_TIMER_INSERT

    これらのカラムはすべての挿入操作を集計します。

  • COUNT_UPDATESUM_TIMER_UPDATEMIN_TIMER_UPDATEAVG_TIMER_UPDATEMAX_TIMER_UPDATE

    これらのカラムはすべての更新操作を集計します。

  • COUNT_DELETESUM_TIMER_DELETEMIN_TIMER_DELETEAVG_TIMER_DELETEMAX_TIMER_DELETE

    これらのカラムはすべての削除操作を集計します。

TRUNCATE TABLE はテーブル I/O サマリーテーブルに使用できます。それは、行を削除するのではなく、サマリーカラムを 0 にリセットします。このテーブルを切り捨てると、table_io_waits_summary_by_index_usage テーブルも切り捨てられます。

22.9.9.6.2 table_io_waits_summary_by_index_usage テーブル

table_io_waits_summary_by_index_usage テーブルは、wait/io/table/sql/handler インストゥルメントによって生成されるすべてのテーブルインデックス I/O 待機イベントを集計します。グループ化はテーブルインデックス単位です。

table_io_waits_summary_by_index_usage の構造は、table_io_waits_summary_by_table とほぼ同一です。唯一の違いは、テーブル I/O 待機イベントが記録されたときに使用されたインデックスの名前に対応する、追加のグループカラム INDEX_NAME です。

  • PRIMARY の値はテーブル I/O でプライマリインデックスが使用されたことを示します。

  • NULL の値はテーブル I/O でインデックスが使用されなかったことを示します。

  • 挿入は INDEX_NAME = NULL に対してカウントされます。

TRUNCATE TABLE はテーブル I/O サマリーテーブルに使用できます。それは、行を削除するのではなく、サマリーカラムを 0 にリセットします。このテーブルも、table_io_waits_summary_by_table テーブルの切り捨てによって切り捨てられます。テーブルのインデックス構造を変更する DDL 操作により、インデックスごとの統計がリセットされることがあります。

22.9.9.6.3 table_lock_waits_summary_by_table テーブル

table_lock_waits_summary_by_table テーブルは、wait/lock/table/sql/handler インストゥルメントによって生成されるすべてのテーブルロック待機イベントを集計します。グループ化はテーブル単位です。

このテーブルには、内部および外部ロックに関する情報が格納されます。

  • 内部ロックは、SQL レイヤーのロックに対応します。これは現在 thr_lock() への呼び出しによって実装されます。イベント行で、これらのロックは、次のいずれかの値を持つ OPERATION カラムによって区別されます。

    read normal
    read with shared locks
    read high priority
    read no insert
    write allow write
    write concurrent insert
    write delayed
    write low priority
    write normal
  • 外部ロックはストレージエンジンレイヤーのロックに対応します。これは現在 handler::external_lock() への呼び出しによって実装されます。イベント行で、これらのロックは、次のいずれかの値を持つ OPERATION カラムによって区別されます。

    read external
    write external

table_lock_waits_summary_by_table テーブルには、テーブルのイベントの集計方法を示すこれらのグループ化カラムがあります。OBJECT_TYPEOBJECT_SCHEMA、および OBJECT_NAME。これらのカラムは、events_waits_current テーブル内と同じ意味を持ちます。それらは、行の適用先のテーブルを識別します。

table_lock_waits_summary_by_table には集計された値を格納する次のサマリーカラムがあります。カラムの説明に示すように、一部のカラムは一般的で、より詳細なカラムの値の合計と同じ値を持ちます。たとえば、すべてのロックを集計するカラムは、読み取りおよび書き込みロックを集計する対応するカラムの合計を保持します。このように、低レベルカラムを合計するユーザー定義ビューを必要とせずに、高レベルでのアグリゲーションを直接取得できます。

  • COUNT_STARSUM_TIMER_WAITMIN_TIMER_WAITAVG_TIMER_WAITMAX_TIMER_WAIT

    これらのカラムはすべてのロック操作を集計します。それらは対応する xxx_READ および xxx_WRITE カラムの合計と同じです。

  • COUNT_READSUM_TIMER_READMIN_TIMER_READAVG_TIMER_READMAX_TIMER_READ

    これらのカラムはすべての読み取りロック操作を集計します。それらは対応する xxx_READ_NORMALxxx_READ_WITH_SHARED_LOCKSxxx_READ_HIGH_PRIORITY、および xxx_READ_NO_INSERT カラムの合計と同じです。

  • COUNT_WRITESUM_TIMER_WRITEMIN_TIMER_WRITEAVG_TIMER_WRITEMAX_TIMER_WRITE

    これらのカラムはすべての書き込みロック操作を集計します。それらは対応する xxx_WRITE_ALLOW_WRITExxx_WRITE_CONCURRENT_INSERTxxx_WRITE_DELAYEDxxx_WRITE_LOW_PRIORITY、および xxx_WRITE_NORMAL カラムの合計と同じです。

  • COUNT_READ_NORMALSUM_TIMER_READ_NORMALMIN_TIMER_READ_NORMALAVG_TIMER_READ_NORMALMAX_TIMER_READ_NORMAL

    これらのカラムは内部読み取りロックを集計します。

  • COUNT_READ_WITH_SHARED_LOCKSSUM_TIMER_READ_WITH_SHARED_LOCKSMIN_TIMER_READ_WITH_SHARED_LOCKSAVG_TIMER_READ_WITH_SHARED_LOCKSMAX_TIMER_READ_WITH_SHARED_LOCKS

    これらのカラムは内部読み取りロックを集計します。

  • COUNT_READ_HIGH_PRIORITYSUM_TIMER_READ_HIGH_PRIORITYMIN_TIMER_READ_HIGH_PRIORITYAVG_TIMER_READ_HIGH_PRIORITYMAX_TIMER_READ_HIGH_PRIORITY

    これらのカラムは内部読み取りロックを集計します。

  • COUNT_READ_NO_INSERTSUM_TIMER_READ_NO_INSERTMIN_TIMER_READ_NO_INSERTAVG_TIMER_READ_NO_INSERTMAX_TIMER_READ_NO_INSERT

    これらのカラムは内部読み取りロックを集計します。

  • COUNT_READ_EXTERNALSUM_TIMER_READ_EXTERNALMIN_TIMER_READ_EXTERNALAVG_TIMER_READ_EXTERNALMAX_TIMER_READ_EXTERNAL

    これらのカラムは外部読み取りロックを集計します。

  • COUNT_WRITE_ALLOW_WRITESUM_TIMER_WRITE_ALLOW_WRITEMIN_TIMER_WRITE_ALLOW_WRITEAVG_TIMER_WRITE_ALLOW_WRITEMAX_TIMER_WRITE_ALLOW_WRITE

    これらのカラムは内部書き込みロックを集計します。

  • COUNT_WRITE_CONCURRENT_INSERTSUM_TIMER_WRITE_CONCURRENT_INSERTMIN_TIMER_WRITE_CONCURRENT_INSERTAVG_TIMER_WRITE_CONCURRENT_INSERTMAX_TIMER_WRITE_CONCURRENT_INSERT

    これらのカラムは内部書き込みロックを集計します。

  • COUNT_WRITE_DELAYEDSUM_TIMER_WRITE_DELAYEDMIN_TIMER_WRITE_DELAYEDAVG_TIMER_WRITE_DELAYEDMAX_TIMER_WRITE_DELAYED

    これらのカラムは内部書き込みロックを集計します。

    MySQL 5.6.6 以降、DELAYED 挿入は非推奨であるため、これらのカラムは将来のリリースで削除されます。

  • COUNT_WRITE_LOW_PRIORITYSUM_TIMER_WRITE_LOW_PRIORITYMIN_TIMER_WRITE_LOW_PRIORITYAVG_TIMER_WRITE_LOW_PRIORITYMAX_TIMER_WRITE_LOW_PRIORITY

    これらのカラムは内部書き込みロックを集計します。

  • COUNT_WRITE_NORMALSUM_TIMER_WRITE_NORMALMIN_TIMER_WRITE_NORMALAVG_TIMER_WRITE_NORMALMAX_TIMER_WRITE_NORMAL

    これらのカラムは内部書き込みロックを集計します。

  • COUNT_WRITE_EXTERNALSUM_TIMER_WRITE_EXTERNALMIN_TIMER_WRITE_EXTERNALAVG_TIMER_WRITE_EXTERNALMAX_TIMER_WRITE_EXTERNAL

    これらのカラムは外部書き込みロックを集計します。

TRUNCATE TABLE はテーブルロックサマリーテーブルに使用できます。それは、行を削除するのではなく、サマリーカラムを 0 にリセットします。

22.9.9.7 接続サマリーテーブル

接続サマリーテーブルは、スレッド単位ではなく、アカウント、ユーザー、またホストごとにアグリゲーションが行われることを除いて、対応する events_xxx_summary_by_thread_by_event_name テーブルに似ています。

パフォーマンススキーマは、イベント名とアカウント、ユーザー、またはホストで接続統計を集計するサマリーテーブルを保守します。待機、ステージ、およびステートメントイベントを集計する個別のテーブルのグループを使用でき、それによってこの一連の接続サマリーテーブルが得られます。

  • events_waits_summary_by_account_by_event_name: アカウントおよびイベント名ごとに要約された待機イベント

  • events_waits_summary_by_user_by_event_name: ユーザー名およびイベント名ごとに要約された待機イベント

  • events_waits_summary_by_host_by_event_name: ホスト名およびイベント名ごとに要約された待機イベント

  • events_stages_summary_by_account_by_event_name: アカウントおよびイベント名ごとに要約されたステージイベント

  • events_stages_summary_by_user_by_event_name: ユーザー名およびイベント名ごとに要約されたステージイベント

  • events_stages_summary_by_host_by_event_name: ホスト名およびイベント名ごとに要約されたステージイベント

  • events_statements_summary_by_account_by_event_name: アカウントおよびイベント名ごとに要約されたステートメントイベント

  • events_statements_summary_by_user_by_event_name: ユーザー名およびイベント名ごとに要約されたステートメントイベント

  • events_statements_summary_by_host_by_event_name: ホスト名およびイベント名ごとに要約されたステートメントイベント

つまり、接続サマリーテーブルは、形式 events_xxx_summary_yyy_by_event_name の名前を持ちます。ここで xxxwaitsstages、または statements で、yyyaccountuser、または host です。

接続サマリーテーブルは中間アグリゲーションレベルを提供します。

  • xxx_summary_by_thread_by_event_name テーブルは接続サマリーテーブルより詳細です

  • xxx_summary_global_by_event_name テーブルは接続サマリーテーブルより詳細ではありません

各接続サマリーテーブルには、テーブルのイベントの集計方法を示す 1 つまたは複数のグループ化カラムがあります。イベント名は、setup_instruments テーブル内のイベントインストゥルメントの名前を表します。

  • 名前に _by_account のあるテーブルでは、USERHOST、および EVENT_NAME カラムで、アカウントとイベント名ごとにイベントがグループ化されます。

  • 名前に _by_host のあるテーブルでは、HOST および EVENT_NAME カラムで、ホスト名とイベント名ごとにイベントがグループ化されます。

  • 名前に _by_user のあるテーブルでは、USER および EVENT_NAME カラムで、ユーザー名とイベント名ごとにイベントがグループ化されます。

すべての接続サマリーテーブルには、集計された値を格納するこれらのサマリーカラムがあります。COUNT_STARSUM_TIMER_WAITMIN_TIMER_WAIT, AVG_TIMER_WAIT、および MAX_TIMER_WAIT。これらは events_waits_summary_by_instance テーブル内の同じ名前のカラムに似ています。ステートメントの接続サマリーテーブルには、ステートメントの種類を集計する追加の SUM_xxx カラムがあります。

接続サマリーテーブルは MySQL 5.6.3 で追加されました。

TRUNCATE TABLE は接続サマリーテーブルに使用できます。それは、行を削除するのではなく、サマリーカラムを 0 にリセットします。さらに、接続サマリーテーブルは、それらが依存する接続テーブルが切り捨てられた場合に、暗黙的に切り捨てられます。表22.2「暗黙的なテーブル切り捨ての効果」 に接続テーブルの切り捨てと暗黙的に切り捨てられるテーブルの関係を説明しています。

表 22.2 暗黙的なテーブル切り捨ての効果

切り捨てられたテーブル暗黙的に切り捨てられたサマリーテーブル
accounts%_by_account%%_by_thread% に一致する名前を持つテーブル
hosts%_by_account%%_by_host%%_by_thread% に一致する名前を持つテーブル
users%_by_account%%_by_user%%_by_thread% に一致する名前を持つテーブル

22.9.9.8 ソケットサマリーテーブル

これらのソケットサマリーテーブルは、ソケット操作のタイマーおよびバイトカウント情報を集計します。

  • socket_summary_by_instance: ソケットインスタンスごとに、すべてのソケット I/O 操作の wait/io/socket/* インストゥルメントによって生成されたタイマーおよびバイトカウント統計を集計します。接続が終了すると、socket_summary_by_instance 内のそれに対応する行が削除されます。

  • socket_summary_by_event_name: ソケットインストゥルメントごとに、すべてのソケット I/O 操作の wait/io/socket/* インストゥルメントによって生成されたタイマーおよびバイトカウント統計を集計します。

ソケットサマリーテーブルは、ソケットがクライアントからの次のリクエストを待っている間に、idle イベントによって生成される待機は集計しません。idle イベントアグリゲーションには、待機イベントサマリーテーブルを使用します。セクション22.9.9.1「イベント待機サマリーテーブル」を参照してください。

各ソケットサマリーテーブルには、テーブルのイベントの集計方法を示す 1 つまたは複数のグループ化カラムがあります。イベント名は、setup_instruments テーブル内のイベントインストゥルメントの名前を表します。

  • socket_summary_by_instance には OBJECT_INSTANCE_BEGIN カラムがあります。各行は特定のオブジェクトのイベントを要約します。

  • socket_summary_by_event_name には EVENT_NAME カラムがあります。各行は特定のイベント名のイベントを要約します。

すべてのソケットサマリーテーブルには、集計された値を格納するこれらのサマリーカラムがあります。

  • COUNT_STARSUM_TIMER_WAITMIN_TIMER_WAITAVG_TIMER_WAITMAX_TIMER_WAIT

    これらのカラムはすべての操作を集計します。

  • COUNT_READSUM_TIMER_READMIN_TIMER_READAVG_TIMER_READMAX_TIMER_READSUM_NUMBER_OF_BYTES_READ

    これらのカラムはすべての受信操作 (RECVRECVFROM、および RECVMSG) を集計します。

  • COUNT_WRITESUM_TIMER_WRITEMIN_TIMER_WRITEAVG_TIMER_WRITEMAX_TIMER_WRITESUM_NUMBER_OF_BYTES_WRITE

    これらのカラムはすべての送信操作 (SENDSENDTO、および SENDMSG) を集計します。

  • COUNT_MISCSUM_TIMER_MISCMIN_TIMER_MISCAVG_TIMER_MISCMAX_TIMER_MISC

    これらのカラムは CONNECTLISTENACCEPTCLOSE、および SHUTDOWN などのほかのすべてのソケット操作を集計します。これらの操作のバイトカウントはありません。

socket_summary_by_instance テーブルには、ソケットのクラス (client_connectionserver_tcpip_socketserver_unix_socket) を示す EVENT_NAME カラムもあります。このカラムは、たとえば、クライアントアクティビティーをサーバー待機ソケットのそれから分離するために、グループ化できます。

これらのテーブルは MySQL 5.6.3 で追加されました。

TRUNCATE TABLE はソケットサマリーテーブルに使用できます。events_statements_summary_by_digest を除き、tt は行を削除するのではなく、サマリーカラムを 0 にリセットします。

22.9.10 パフォーマンススキーマのその他のテーブル

次のセクションでは、先述のセクションで説明したテーブルカテゴリに収まらないテーブルについて説明します。

  • host_cache: 内部ホストキャッシュからの情報

  • performance_timers: 使用可能なイベントタイマー

  • threads: サーバースレッドに関する情報

22.9.10.1 host_cache テーブル

host_cache は、クライアントホスト名および IP アドレス情報を格納し、DNS ルックアップを回避するために使用されるホストキャッシュの内容へのアクセスを提供します。(セクション8.11.5.2「DNS ルックアップの最適化とホストキャッシュ」を参照してください。)host_cache テーブルは、SELECT ステートメントを使用して調査できるようにホストキャッシュの内容を公開します。パフォーマンススキーマを有効にしている必要があり、そうでなければこのテーブルは空になります。

FLUSH HOSTSTRUNCATE TABLE host_cache は同じ効果を持ちます。それらはホストキャッシュをクリアします。これは host_cache テーブルを空にし (それはキャッシュの可視表現であるため)、ブロックされたすべてのホストのブロックも解除します (セクションB.5.2.6「ホスト 'host_name' は拒否されました」を参照してください)。FLUSH HOSTS には RELOAD 権限が必要です。TRUNCATE TABLE では host_cache テーブルへの DROP 権限が必要です。

host_cache テーブルにはこれらのカラムがあります。

  • IP

    文字列で表された、サーバーに接続しているクライアントの IP アドレス。

  • HOST

    そのクライアント IP の解決済みの DNS ホスト名、または名前が不明な場合は NULL

  • HOST_VALIDATED

    クライアント IP に対し、IP からホスト名、ホスト名から IP の DNS 解決が正常に実行されたかどうか。HOST_VALIDATEDYES の場合、DNS への呼び出しを回避できるように、IP に対応するホスト名として HOST カラムが使用されます。HOST_VALIDATEDNO である間、各接続について、最終的にそれが有効な結果または永続的エラーのいずれかで完了するまで、DNS 解決が試みられます。この情報により、サーバーは、クライアントに永久に影響することがある、一時的な DNS 障害発生時の不正または失われたホスト名のキャッシュを避けることができます。

  • SUM_CONNECT_ERRORS

    ブロックとみなされる接続エラーの数 (max_connect_errors システム変数に対して評価される)。現在、プロトコルハンドシェークエラーのみが、検証に合格したホスト (HOST_VALIDATED = YES) に対してのみカウントされます。

  • COUNT_HOST_BLOCKED_ERRORS

    SUM_CONNECT_ERRORSmax_connect_errors システム変数の値を超えたため、ブロックされた接続の数。

  • COUNT_NAMEINFO_TRANSIENT_ERRORS

    IP からホスト名への DNS 解決時の一時的なエラーの数。

  • COUNT_NAMEINFO_PERMANENT_ERRORS

    IP からホスト名への DNS 解決時の永続的なエラーの数。

  • COUNT_FORMAT_ERRORS

    ホスト名形式エラーの数。MySQL は、1.2.example.com など、名前の最初のコンポーネントの 1 つまたは複数がすべて数値であるホスト名に対して、mysql.user テーブル内の Host カラム値の照合を実行しません。代わりにクライアント IP アドレスが使用されます。この種類の照合が行われない理由については、セクション6.2.3「アカウント名の指定」を参照してください。

  • COUNT_ADDRINFO_TRANSIENT_ERRORS

    ホスト名から IP への逆引き DNS 解決時の一時的なエラーの数。

  • COUNT_ADDRINFO_PERMANENT_ERRORS

    ホスト名から IP への逆引き DNS 解決時の永続的なエラーの数。

  • COUNT_FCRDNS_ERRORS

    Forward-confirmed reverse DNS エラーの数。これらのエラーは、IP からホスト名、ホスト名から IP の DNS 解決で、クライアントの発信元の IP アドレスに一致しない IP アドレスが生成された場合に発生します。

  • COUNT_HOST_ACL_ERRORS

    クライアントホストからログインできる可能性のあるユーザーがいないために発生するエラーの数。そのような場合、サーバーは ER_HOST_NOT_PRIVILEGED を返し、ユーザー名やパスワードも要求しません。

  • COUNT_NO_AUTH_PLUGIN_ERRORS

    使用できない認証プラグインのリクエストによるエラーの数。プラグインが使用できない可能性があるのは、たとえば、それがロードされていないか、ロードの試みに失敗した場合です。

  • COUNT_AUTH_PLUGIN_ERRORS

    認証プラグインによって報告されるエラーの数。

    認証プラグインは、障害の原因を示すために、さまざまなエラーコードを報告することがあります。エラーの種類に応じて、これらのいずれかのカラムが増分されます。COUNT_AUTHENTICATION_ERRORSCOUNT_AUTH_PLUGIN_ERRORSCOUNT_HANDSHAKE_ERRORS。新しいリターンコードは、既存のプラグイン API へのオプションの拡張です。不明または予期しないプラグインエラーは COUNT_AUTH_PLUGIN_ERRORS カラムにカウントされます。

  • COUNT_HANDSHAKE_ERRORS

    有線プロトコルレベルで検出されたエラーの数。

  • COUNT_PROXY_USER_ERRORS

    プロキシユーザー A が、存在しない別のユーザー B にプロキシ設定された場合に、検出されたエラーの数。

  • COUNT_PROXY_USER_ACL_ERRORS

    存在はしているが、それに対してプロキシユーザー A が PROXY 権限を持たない別のユーザー B に A がプロキシ設定された場合に、検出されたエラーの数。

  • COUNT_AUTHENTICATION_ERRORS

    失敗した認証によって発生したエラーの数。

  • COUNT_SSL_ERRORS

    SSL の問題によるエラーの数。

  • COUNT_MAX_USER_CONNECTIONS_ERRORS

    ユーザーごとの接続割り当てを超えることによって発生したエラーの数。セクション6.3.4「アカウントリソース制限の設定」を参照してください。

  • COUNT_MAX_USER_CONNECTIONS_PER_HOUR_ERRORS

    時間あたりのユーザーごとの接続割り当てを超えることによって発生したエラーの数。セクション6.3.4「アカウントリソース制限の設定」を参照してください。

  • COUNT_DEFAULT_DATABASE_ERRORS

    デフォルトのデータベースに関連するエラーの数。たとえば、データベースが存在していないか、ユーザーがそれにアクセスするための権限を持っていませんでした。

  • COUNT_INIT_CONNECT_ERRORS

    init_connect システム変数値内のステートメントの実行の失敗によって発生したエラーの数。

  • COUNT_LOCAL_ERRORS

    サーバー実装にローカルで、ネットワーク、認証、または承認に関連しないエラーの数。たとえば、メモリー不足状況はこのカテゴリに収まります。

  • COUNT_UNKNOWN_ERRORS

    このテーブルのほかのカラムによって報告されない、ほかの不明なエラーの数。このカラムは、新しいエラー状況を報告する必要がある場合や、下位互換性を維持し、host_cache テーブルのテーブル構造を必要とする場合に備えて、将来使用するために予約されています。

  • FIRST_SEEN

    IP カラム内のクライアントから確認された最初の接続の試みのタイムスタンプ。

  • LAST_SEEN

    IP カラム内のクライアントから確認された最後の接続の試みのタイムスタンプ。

  • FIRST_ERROR_SEEN

    IP カラム内のクライアントから確認された最初のエラーのタイムスタンプ。

  • LAST_ERROR_SEEN

    IP カラム内のクライアントから確認された最後のエラーのタイムスタンプ。

host_cache テーブルは MySQL 5.6.5 で追加されました。

22.9.10.2 performance_timers テーブル

performance_timers テーブルは使用可能なイベントタイマーを示します。

mysql> SELECT * FROM performance_timers;+-------------+-----------------+------------------+----------------+
| TIMER_NAME | TIMER_FREQUENCY | TIMER_RESOLUTION | TIMER_OVERHEAD |
+-------------+-----------------+------------------+----------------+
| CYCLE | 2389029850 | 1 | 72 |
| NANOSECOND | NULL | NULL | NULL |
| MICROSECOND | 1000000 | 1 | 585 |
| MILLISECOND | 1035 | 1 | 738 |
| TICK | 101 | 1 | 630 |
+-------------+-----------------+------------------+----------------+

特定のタイマーに関連付けられた値が NULL の場合、そのタイマーはプラットフォームでサポートされていません。NULL を含まない行は、setup_timers で使用できるタイマーを示しています。

performance_timers テーブルにはこれらのカラムがあります。

  • TIMER_NAME

    setup_timers テーブルの構成時に、タイマーを参照する名前。

  • TIMER_FREQUENCY

    秒あたりのタイマーユニットの数。サイクルタイマーの場合、頻度は一般に CPU 速度に関連します。たとえば、2.4GHz プロセッサを搭載するシステムでは、CYCLE は 2400000000 に近い可能性があります。

  • TIMER_RESOLUTION

    タイマー値が増加するタイマーユニット数を示します。タイマーの分解能が 10 の場合、その値は毎回 10 ずつ増加します。

  • TIMER_OVERHEAD

    特定のタイマーで 1 つのタイミングを取得するためのオーバーヘッドの最小サイクル数。パフォーマンススキーマは、初期化時にタイマーを 20 回呼び出し、最小値を選択することによって、この値を決定します。インストゥルメンテーションは、各イベントの開始と終了でタイマーを呼び出すため、実際の合計のオーバーヘッドはこの量の 2 倍になります。タイマーコードは、時間付きイベントにのみ呼び出されるため、このオーバーヘッドは時間なしイベントには適用されません。

    テーブルの最大行数は、サーバー起動時に自動サイズ設定されます。この最大を明示的に設定するには、サーバー起動時に performance_schema_digests_size システム変数を設定します。

22.9.10.3 スレッドテーブル

threads テーブルは各サーバースレッドの行を格納します。各行は、スレッドに関する情報を格納し、それに対するモニタリングが有効にされているかどうかを示します。

mysql> SELECT * FROM threads\G*************************** 1. row *************************** THREAD_ID: 1 NAME: thread/sql/main TYPE: BACKGROUND PROCESSLIST_ID: NULL PROCESSLIST_USER: NULL PROCESSLIST_HOST: NULL PROCESSLIST_DB: NULL
PROCESSLIST_COMMAND: NULL PROCESSLIST_TIME: 80284 PROCESSLIST_STATE: NULL PROCESSLIST_INFO: NULL PARENT_THREAD_ID: NULL ROLE: NULL INSTRUMENTED: YES
...
*************************** 4. row *************************** THREAD_ID: 51 NAME: thread/sql/one_connection TYPE: FOREGROUND PROCESSLIST_ID: 34 PROCESSLIST_USER: paul PROCESSLIST_HOST: localhost PROCESSLIST_DB: performance_schema
PROCESSLIST_COMMAND: Query PROCESSLIST_TIME: 0 PROCESSLIST_STATE: Sending data PROCESSLIST_INFO: SELECT * FROM threads PARENT_THREAD_ID: 1 ROLE: NULL INSTRUMENTED: YES
...

threads テーブルの初期の内容は、パフォーマンススキーマの初期化が行われるときに、存在しているスレッドに基づきます。その後、サーバーがスレッドを作成するたびに新しい行が追加されます。

スレッドの終了時に、threads テーブルからの行の削除が行われます。クライアントセッションに関連付けられたスレッドでは、セッションの終了時に削除が行われます。クライアントの自動再接続が有効にされており、セッションが切断後に再接続した場合、そのセッションは異なる PROCESSLIST_ID 値を持つ threads テーブル内の新しい行に関連付けられます。新しいスレッドの初期 INSTRUMENTED 値は元のスレッドの値と異なることがあります。その間に setup_actors テーブルが変更されている可能性があり、元のスレッドの INSTRUMENTED 値が初期化後に変更されている場合、その変更は新しいスレッドに持ち越されません。

PROCESSLIST_ のプリフィクスのある名前を持つ threads テーブルカラムは、INFORMATION_SCHEMA.PROCESSLIST テーブルまたは SHOW PROCESSLIST ステートメントから入手できるものに似た情報を提供します。そのため、これらのすべてのソースはスレッドモニタリング情報を提供します。threads の使用は、次の点で、ほかの 2 つのソースの使用と異なります。

  • threads へのアクセスには相互排他ロックは必要なく、サーバーパフォーマンスへの影響は最小です。INFORMATION_SCHEMA.PROCESSLISTSHOW PROCESSLIST では相互排他ロックが必要になるため、パフォーマンスの低下につながります。

  • threads は、スレッドがフォアグラウンドスレッドかバックグラウンドスレッドか、およびスレッドに関連付けられているサーバー内の場所などの、各スレッドの追加情報を提供します。

  • threads はバックグラウンドスレッドに関する情報を提供するため、ほかのスレッド情報ソースでは不可能なアクティビティーのモニターに使用できます。

  • スレッドモニタリングを有効または無効にできます (つまり、スレッドによって実行されるイベントがインストゥルメントされるかどうか)。既存のスレッドのモニタリングを制御するには、threads テーブルの INSTRUMENTED カラムを設定します。新しいフォアグラウンドスレッドの初期 INSTRUMENTED 値を制御するには、setup_actors テーブルを使用します。(スレッドモニタリングが行われる状況の詳細については、INSTRUMENTED カラムの説明を参照してください。)

これらの理由で、INFORMATION_SCHEMA.PROCESSLIST または SHOW PROCESSLIST を使用して、サーバーモニタリングを実行する DBA は、代わりに threads を使用してモニターしたいと考える場合があります。

注記

INFORMATION_SCHEMA.PROCESSLIST および SHOW PROCESSLIST では、ほかのユーザーのスレッドに関する情報は、現在のユーザーに PROCESS 権限がある場合にのみ表示されます。これは threads テーブルには当てはまりません。テーブルの SELECT 権限を持つすべてのユーザーに、すべての行が表示されます。ほかのユーザーのスレッドを表示できないようにすべきであるユーザーには、その権限を与えないでください。

threads テーブルにはこれらのカラムがあります。

  • THREAD_ID

    一意のスレッド識別子。

  • NAME

    サーバーのスレッドインストゥルメンテーションコードに関連付けられている名前。たとえば、thread/sql/one_connection はユーザー接続の処理を担当するコード内のスレッド関数に対応し、thread/sql/main はサーバーの main() 関数を表します。

  • TYPE

    FOREGROUND または BACKGROUND のスレッドの種類。ユーザー接続スレッドはフォアグラウンドスレッドです。内部サーバーアクティビティーに関連付けられているスレッドはバックグラウンドスレッドです。例は、内部 InnoDB スレッド、スレーブに情報を送信する Binlog Dump スレッド、スレーブ I/O および SQL スレッドです。

  • PROCESSLIST_ID

    INFORMATION_SCHEMA.PROCESSLIST テーブルに表示されるスレッドの場合、これはそのテーブルの ID カラムに表示される同じ値です。それは、SHOW PROCESSLIST 出力の Id カラムに表示される値と、そのスレッド内で CONNECTION_ID() が返す値でもあります。

    バックグラウンドスレッド (ユーザー接続に関連付けられないスレッド) の場合、PROCESSLIST_IDNULL であるため、値は一意ではありません。(MySQL 5.6.9 より前では、バックグラウンドスレッドの場合の値は 0 です。)

  • PROCESSLIST_USER

    フォアグラウンドスレッドに関連付けられているユーザー、バックグラウンドスレッドの場合は NULL

  • PROCESSLIST_HOST

    フォアグラウンドスレッドに関連付けられているクライアントのホスト名、バックグラウンドスレッドの場合は NULL

  • PROCESSLIST_DB

    スレッドのデフォルトのデータベース、何もない場合は NULL

  • PROCESSLIST_COMMAND

    スレッドが実行しているコマンドの種類。スレッドコマンドの説明については、セクション8.12.5「スレッド情報の検査」を参照してください。このカラムの値は、クライアント/サーバープロトコルの COM_xxx コマンドと Com_xxx ステータス変数に対応します。セクション5.1.6「サーバーステータス変数」を参照してください

  • PROCESSLIST_TIME

    スレッドが現在の状態になってからの秒数。

  • PROCESSLIST_STATE

    スレッドが行なっていることを示すアクション、イベント、または状態。PROCESSLIST_STATE 値の説明については、セクション8.12.5「スレッド情報の検査」を参照してください。

    ほとんどの状態がきわめてすばやい操作に対応します。スレッドが何秒間も特定の状態にとどまっている場合は、問題が発生している可能性があり、調査が必要です。

  • PROCESSLIST_INFO

    スレッドが実行しているステートメント、またはそれがどのステートメントも実行していない場合は NULL。このステートメントは、サーバーに送信されるステートメント、またはこのステートメントがほかのステートメントを実行する場合は、もっとも内側のステートメントである可能性があります。たとえば、CALL ステートメントが SELECT ステートメントを実行しているストアドプロシージャーを実行する場合、PROCESSLIST_INFO 値には SELECT ステートメントが示されます。

  • PARENT_THREAD_ID

    このスレッドがサブスレッド (別のスレッドによって生成される) である場合、これは生成されるスレッドの THREAD_ID 値です。スレッドの生成は、INSERT DELAYED ステートメントからの行の挿入を処理するためなどに発生します。

  • ROLE

    使用されません。

  • INSTRUMENTED

    スレッドがインストゥルメントされるかどうか。これは、スレッドの threads テーブル行に影響せず、スレッドによって実行されるイベントがインストゥルメントされるかどうかに影響します。

    • フォアグラウンドスレッドでは、初期 INSTRUMENTED 値は、スレッドに関連付けられているユーザーアカウントが setup_actors テーブル内の任意の行に一致するかどうかによって決定されます。照合は PROCESSLIST_USER および PROCESSLIST_HOST カラムの値に基づきます。

      スレッドがサブスレッドを生成する場合、そのサブスレッドに対して照合が再度行われます。

    • バックグラウンドスレッドの場合、INSTRUMENTED はデフォルトで YES です。バックグラウンドスレッドに関連付けられたユーザーはないため、setup_actors は参照されません。

    • どのスレッドでも、スレッドの有効期間の間にその INSTRUMENTED 値が変更されることがあります。これは、唯一の変更可能な threads テーブルカラムです。

    スレッドによって実行されるイベントのモニタリングが行われる場合、これらのことが当てはまる必要があります。

    • setup_consumers テーブル内の thread_instrumentation コンシューマは YES である必要があります。

    • thread.INSTRUMENTED カラムは YES である必要があります。

    • setup_instruments テーブル内で有効にされているインストゥルメントから生成されたスレッドイベントに対してのみ、モニタリングが行われます。

22.10 パフォーマンススキーマオプションおよび変数リファレンス

表 22.3 パフォーマンススキーマ変数リファレンス

名前コマンド行オプションファイルシステム変数ステータス変数変数スコープ動的
performance_schemaはいはいはい グローバルいいえ
Performance_schema_accounts_lost   はいグローバルいいえ
performance_schema_accounts_sizeはいはいはい グローバルいいえ
Performance_schema_cond_classes_lost   はいグローバルいいえ
Performance_schema_cond_instances_lost   はいグローバルいいえ
performance-schema-consumer-events-stages-currentはいはい    
performance-schema-consumer-events-stages-historyはいはい    
performance-schema-consumer-events-stages-history-longはいはい    
performance-schema-consumer-events-statements-currentはいはい    
performance-schema-consumer-events-statements-historyはいはい    
performance-schema-consumer-events-statements-history-longはいはい    
performance-schema-consumer-events-waits-currentはいはい    
performance-schema-consumer-events-waits-historyはいはい    
performance-schema-consumer-events-waits-history-longはいはい    
performance-schema-consumer-global-instrumentationはいはい    
performance-schema-consumer-statements-digestはいはい    
performance-schema-consumer-thread-instrumentationはいはい    
Performance_schema_digest_lost   はいグローバルいいえ
performance_schema_digests_sizeはいはいはい グローバルいいえ
performance_schema_events_stages_history_long_sizeはいはいはい グローバルいいえ
performance_schema_events_stages_history_sizeはいはいはい グローバルいいえ
performance_schema_events_statements_history_long_sizeはいはいはい グローバルいいえ
performance_schema_events_statements_history_sizeはいはいはい グローバルいいえ
performance_schema_events_waits_history_long_sizeはいはいはい グローバルいいえ
performance_schema_events_waits_history_sizeはいはいはい グローバルいいえ
Performance_schema_file_classes_lost   はいグローバルいいえ
Performance_schema_file_handles_lost   はいグローバルいいえ
Performance_schema_file_instances_lost   はいグローバルいいえ
Performance_schema_hosts_lost   はいグローバルいいえ
performance_schema_hosts_sizeはいはいはい グローバルいいえ
performance-schema-instrumentはいはい    
Performance_schema_locker_lost   はいグローバルいいえ
performance_schema_max_cond_classesはいはいはい グローバルいいえ
performance_schema_max_cond_instancesはいはいはい グローバルいいえ
performance_schema_max_file_classesはいはいはい グローバルいいえ
performance_schema_max_file_handlesはいはいはい グローバルいいえ
performance_schema_max_file_instancesはいはいはい グローバルいいえ
performance_schema_max_mutex_classesはいはいはい グローバルいいえ
performance_schema_max_mutex_instancesはいはいはい グローバルいいえ
performance_schema_max_rwlock_classesはいはいはい グローバルいいえ
performance_schema_max_rwlock_instancesはいはいはい グローバルいいえ
performance_schema_max_socket_classesはいはいはい グローバルいいえ
performance_schema_max_socket_instancesはいはいはい グローバルいいえ
performance_schema_max_stage_classesはいはいはい グローバルいいえ
performance_schema_max_statement_classesはいはいはい グローバルいいえ
performance_schema_max_table_handlesはいはいはい グローバルいいえ
performance_schema_max_table_instancesはいはいはい グローバルいいえ
performance_schema_max_thread_classesはいはいはい グローバルいいえ
performance_schema_max_thread_instancesはいはいはい グローバルいいえ
Performance_schema_mutex_classes_lost   はいグローバルいいえ
Performance_schema_mutex_instances_lost   はいグローバルいいえ
Performance_schema_rwlock_classes_lost   はいグローバルいいえ
Performance_schema_rwlock_instances_lost   はいグローバルいいえ
Performance_schema_session_connect_attrs_lost   はいグローバルいいえ
performance_schema_session_connect_attrs_sizeはいはいはい グローバルいいえ
performance_schema_setup_actors_sizeはいはいはい グローバルいいえ
performance_schema_setup_objects_sizeはいはいはい グローバルいいえ
Performance_schema_socket_classes_lost   はいグローバルいいえ
Performance_schema_socket_instances_lost   はいグローバルいいえ
Performance_schema_stage_classes_lost   はいグローバルいいえ
Performance_schema_statement_classes_lost   はいグローバルいいえ
Performance_schema_table_handles_lost   はいグローバルいいえ
Performance_schema_table_instances_lost   はいグローバルいいえ
Performance_schema_thread_classes_lost   はいグローバルいいえ
Performance_schema_thread_instances_lost   はいグローバルいいえ
Performance_schema_users_lost   はいグローバルいいえ
performance_schema_users_sizeはいはいはい グローバルいいえ

22.11 パフォーマンススキーマコマンドオプション

パフォーマンススキーマパラメータは、サーバー起動時にコマンド行またはオプションファイルに指定して、パフォーマンススキーマのインストゥルメントおよびコンシューマを構成できます。多くの場合に実行時構成も可能ですが (セクション22.2.3「パフォーマンススキーマ実行時構成」 を参照)、実行時構成で、起動プロセス中にすでに初期化されているインストゥルメントに影響を与えるには遅すぎる場合は、起動時構成を使用する必要があります。

パフォーマンススキーマのコンシューマおよびインストゥルメントは、次の構文を使用して起動時に構成できます。追加の詳細については、セクション22.2.2「パフォーマンススキーマ起動構成」を参照してください。

  • --performance-schema-consumer-consumer_name=value

    パフォーマンススキーマコンシューマを構成します。setup_consumers テーブル内のコンシューマ名は下線が使われますが、起動時に設定されたコンシューマでは、名前の中のダッシュと下線は同等です。各コンシューマを構成するためのオプションについては、このセクションの後半で詳しく説明します。

  • --performance-schema-instrument=instrument_name=value

    パフォーマンススキーマインストゥルメントを構成します。名前をパターンとして指定して、パターンに一致するインストゥルメントを構成できます。

次の項目は各コンシューマを構成します。

  • --performance-schema-consumer-events-stages-current=value

    events-stages-current コンシューマを構成します。このオプションは MySQL 5.6.4 で追加されました。

  • --performance-schema-consumer-events-stages-history=value

    events-stages-history コンシューマを構成します。このオプションは MySQL 5.6.4 で追加されました。

  • --performance-schema-consumer-events-stages-history-long=value

    events-stages-history-long コンシューマを構成します。このオプションは MySQL 5.6.4 で追加されました。

  • --performance-schema-consumer-events-statements-current=value

    events-statements-current コンシューマを構成します。このオプションは MySQL 5.6.4 で追加されました。

  • --performance-schema-consumer-events-statements-history=value

    events-statements-history コンシューマを構成します。このオプションは MySQL 5.6.4 で追加されました。

  • --performance-schema-consumer-events-statements-history-long=value

    events-statements-history-long コンシューマを構成します。このオプションは MySQL 5.6.4 で追加されました。

  • --performance-schema-consumer-events-waits-current=value

    events-waits-current コンシューマを構成します。このオプションは MySQL 5.6.4 で追加されました。

  • --performance-schema-consumer-events-waits-history=value

    events-waits-history コンシューマを構成します。このオプションは MySQL 5.6.4 で追加されました。

  • --performance-schema-consumer-events-waits-history-long=value

    events-waits-history-long コンシューマを構成します。このオプションは MySQL 5.6.4 で追加されました。

  • --performance-schema-consumer-global-instrumentation=value

    global-instrumentation コンシューマを構成します。このオプションは MySQL 5.6.4 で追加されました。

  • --performance-schema-consumer-statements-digest=value

    statements-digest コンシューマを構成します。このオプションは MySQL 5.6.5 で追加されました。

  • --performance-schema-consumer-thread-instrumentation=value

    thread-instrumentation コンシューマを構成します。このオプションは MySQL 5.6.4 で追加されました。

22.12 パフォーマンススキーマシステム変数

パフォーマンススキーマは、構成情報を提供するいくつかのシステム変数を実装しています。

mysql> SHOW VARIABLES LIKE 'perf%';+--------------------------------------------------------+---------+
| Variable_name | Value |
+--------------------------------------------------------+---------+
| performance_schema | ON |
| performance_schema_accounts_size | 100 |
| performance_schema_digests_size | 200 |
| performance_schema_events_stages_history_long_size | 10000 |
| performance_schema_events_stages_history_size | 10 |
| performance_schema_events_statements_history_long_size | 10000 |
| performance_schema_events_statements_history_size | 10 |
| performance_schema_events_waits_history_long_size | 10000 |
| performance_schema_events_waits_history_size | 10 |
| performance_schema_hosts_size | 100 |
| performance_schema_max_cond_classes | 80 |
| performance_schema_max_cond_instances | 1000 |
| performance_schema_max_file_classes | 50 |
| performance_schema_max_file_handles | 32768 |
| performance_schema_max_file_instances | 10000 |
| performance_schema_max_mutex_classes | 200 |
| performance_schema_max_mutex_instances | 1000000 |
| performance_schema_max_rwlock_classes | 30 |
| performance_schema_max_rwlock_instances | 1000000 |
| performance_schema_max_socket_classes | 10 |
| performance_schema_max_socket_instances | 1000 |
| performance_schema_max_stage_classes | 150 |
| performance_schema_max_statement_classes | 165 |
| performance_schema_max_table_handles | 10000 |
| performance_schema_max_table_instances | 1000 |
| performance_schema_max_thread_classes | 50 |
| performance_schema_max_thread_instances | 1000 |
| performance_schema_session_connect_attrs_size | 512 |
| performance_schema_setup_actors_size | 100 |
| performance_schema_setup_objects_size | 100 |
| performance_schema_users_size | 100 |
+--------------------------------------------------------+---------+

パフォーマンススキーマシステム変数は、コマンド行またはオプションファイルでサーバーの起動時に設定でき、多くは実行時に設定できます。セクション22.10「パフォーマンススキーマオプションおよび変数リファレンス」を参照してください。

MySQL 5.6.6 以降、パフォーマンススキーマは、そのパラメータのいくつかの値を、それらが明示的に設定されていない場合に、サーバーの起動時に自動的にサイズ設定します。詳細については、セクション22.2.2「パフォーマンススキーマ起動構成」を参照してください。

パフォーマンススキーマシステム変数には次の意味があります。

  • performance_schema

    コマンド行形式--performance-schema=#
    システム変数名前performance_schema
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)ブール
    デフォルトOFF
    許可されている値 (>= 5.6.6)ブール
    デフォルトON

    この変数の値は ON または OFF で、パフォーマンススキーマが有効にされているかどうかを示します。デフォルトで、この値は MySQL 5.6.6 以降 ON で、それより前では OFF です。サーバーの起動時に、この変数を値なし、またはそれを有効にする ON または 1 の値、またはそれを無効にする OFF または 0 の値で指定できます。

  • performance_schema_accounts_size

    導入5.6.3
    コマンド行形式--performance-schema-accounts-size=#
    システム変数名前performance_schema_accounts_size
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト10
    最小値0
    最大値1048576
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)
    最小値-1
    最大値1048576

    accounts テーブルの行数。この変数が 0 の場合、パフォーマンススキーマは accounts テーブル内の接続統計を保守しません。この変数は MySQL 5.6.3 で追加されました。

  • performance_schema_digests_size

    導入5.6.5
    コマンド行形式--performance-schema-digests-size=#
    システム変数名前performance_schema_digests_size
    変数スコープグローバル
    動的変数いいえ
    許可されている値数値
    デフォルト-1 (autosized)
    最小値-1
    最大値1048576

    events_statements_summary_by_digest テーブル内の最大行数。この変数は MySQL 5.6.5 で追加されました。この最大を超えたため、ダイジェストをインストゥルメントできない場合、パフォーマンススキーマは Performance_schema_digest_lost ステータス変数を増分します。

  • performance_schema_events_stages_history_long_size

    導入5.6.3
    コマンド行形式--performance-schema-events-stages-history-long-size=#
    システム変数名前performance_schema_events_stages_history_long_size
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト10000
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)

    events_stages_history_long テーブルの行数。この変数は MySQL 5.6.3 で追加されました。

  • performance_schema_events_stages_history_size

    導入5.6.3
    コマンド行形式--performance-schema-events-stages-history-size=#
    システム変数名前performance_schema_events_stages_history_size
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト10
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)

    events_stages_history テーブルのスレッドあたりの行数。この変数は MySQL 5.6.3 で追加されました。

  • performance_schema_events_statements_history_long_size

    導入5.6.3
    コマンド行形式--performance-schema-events-statements-history-long-size=#
    システム変数名前performance_schema_events_statements_history_long_size
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト10000
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)

    events_statements_history_long テーブル内の行数。この変数は MySQL 5.6.3 で追加されました。

  • performance_schema_events_statements_history_size

    導入5.6.3
    コマンド行形式--performance-schema-events-statements-history-size=#
    システム変数名前performance_schema_events_statements_history_size
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト10
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)

    events_statements_history テーブル内のスレッドあたりの行数。この変数は MySQL 5.6.3 で追加されました。

  • performance_schema_events_waits_history_long_size

    コマンド行形式--performance-schema-events-waits-history-long-size=#
    システム変数名前performance_schema_events_waits_history_long_size
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト10000
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)

    events_waits_history_long テーブル内の行数。

  • performance_schema_events_waits_history_size

    コマンド行形式--performance-schema-events-waits-history-size=#
    システム変数名前performance_schema_events_waits_history_size
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト10
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)

    events_waits_history テーブル内のスレッドあたりの行数。

  • performance_schema_hosts_size

    導入5.6.3
    コマンド行形式--performance-schema-hosts-size=#
    システム変数名前performance_schema_hosts_size
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト10
    最小値0
    最大値1048576
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)
    最小値-1
    最大値1048576

    hosts テーブル内の行数。この変数が 0 の場合、パフォーマンススキーマは hosts テーブル内の接続統計を保守しません。この変数は MySQL 5.6.3 で追加されました。

  • performance_schema_max_cond_classes

    コマンド行形式--performance-schema-max-cond-classes=#
    システム変数名前performance_schema_max_cond_classes
    変数スコープグローバル
    動的変数いいえ
    許可されている値数値
    デフォルト80

    条件インストゥルメントの最大数。

  • performance_schema_max_cond_instances

    コマンド行形式--performance-schema-max-cond-instances=#
    システム変数名前performance_schema_max_cond_instances
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト1000
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)

    インストゥルメントされた条件オブジェクトの最大数。

  • performance_schema_max_file_classes

    コマンド行形式--performance-schema-max-file-classes=#
    システム変数名前performance_schema_max_file_classes
    変数スコープグローバル
    動的変数いいえ
    許可されている値数値
    デフォルト50

    ファイルインストゥルメントの最大数。

  • performance_schema_max_file_handles

    コマンド行形式--performance-schema-max-file-handles=#
    システム変数名前performance_schema_max_file_handles
    変数スコープグローバル
    動的変数いいえ
    許可されている値数値
    デフォルト32768

    オープンしているファイルオブジェクトの最大数。

    performance_schema_max_file_handles の値は、open_files_limit の値より大きくしてください。open_files_limit は、サーバーがサポート可能なオープンファイルハンドルの最大数に影響し、performance_schema_max_file_handles はこれらのファイルハンドルのうちインストゥルメント可能な数に影響します。

  • performance_schema_max_file_instances

    コマンド行形式--performance-schema-max-file-instances=#
    システム変数名前performance_schema_max_file_instances
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト10000
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)

    インストゥルメントされるファイルオブジェクトの最大数。

  • performance_schema_max_mutex_classes

    コマンド行形式--performance-schema-max-mutex-classes=#
    システム変数名前performance_schema_max_mutex_classes
    変数スコープグローバル
    動的変数いいえ
    許可されている値数値
    デフォルト200

    相互排他ロックインストゥルメントの最大数。

  • performance_schema_max_mutex_instances

    コマンド行形式--performance-schema-max-mutex-instances=#
    システム変数名前performance_schema_max_mutex_instances
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト1000
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)

    インストゥルメントされる相互排他ロックオブジェクトの最大数。

  • performance_schema_max_rwlock_classes

    コマンド行形式--performance-schema-max-rwlock-classes=#
    システム変数名前performance_schema_max_rwlock_classes
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (5.6.0)数値
    デフォルト20
    許可されている値 (>= 5.6.1, <= 5.6.14)数値
    デフォルト30
    許可されている値 (>= 5.6.15)数値
    デフォルト40

    rwlock インストゥルメントの最大数。

  • performance_schema_max_rwlock_instances

    コマンド行形式--performance-schema-max-rwlock-instances=#
    システム変数名前performance_schema_max_rwlock_instances
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト1000
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)

    インストゥルメントされる rwlock オブジェクトの最大数。

  • performance_schema_max_socket_classes

    導入5.6.3
    コマンド行形式--performance-schema-max-socket-classes=#
    システム変数名前performance_schema_max_socket_classes
    変数スコープグローバル
    動的変数いいえ
    許可されている値数値
    デフォルト10

    ソケットインストゥルメントの最大数。この変数は MySQL 5.6.3 で追加されました。

  • performance_schema_max_socket_instances

    導入5.6.3
    コマンド行形式--performance-schema-max-socket-instances=#
    システム変数名前performance_schema_max_socket_instances
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト1000
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)

    インストゥルメントされるソケットオブジェクトの最大数。この変数は MySQL 5.6.3 で追加されました。

  • performance_schema_max_stage_classes

    導入5.6.3
    コマンド行形式--performance-schema-max-stage-classes=#
    システム変数名前performance_schema_max_stage_classes
    変数スコープグローバル
    動的変数いいえ
    許可されている値数値
    デフォルト150

    ステージインストゥルメントの最大数。この変数は MySQL 5.6.3 で追加されました。

  • performance_schema_max_statement_classes

    導入5.6.3
    コマンド行形式--performance-schema-max-statement-classes=#
    システム変数名前performance_schema_max_statement_classes
    変数スコープグローバル
    動的変数いいえ
    許可されている値数値
    デフォルト(autosized)

    ステートメントインストゥルメントの最大数。デフォルト値は、サーバー構築時に、クライアント/サーバープロトコルのコマンド数とサーバーでサポートされる SQL ステートメントの種類の数に基づいて計算されます。

    この変数は、それを 0 に設定して、すべてのステートメントインストゥルメンテーションを無効にし、それに関連付けられているすべてのメモリーを節約しないかぎり、変更するべきではありません。変数をデフォルトでない 0 以外の値に設定してもメリットはありません。特にデフォルトより大きい値は、必要以上のメモリーが割り当てられます。

    この変数は MySQL 5.6.3 で追加されました。

  • performance_schema_max_table_handles

    コマンド行形式--performance-schema-max-table-handles=#
    システム変数名前performance_schema_max_table_handles
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト100000
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)

    オープンしているテーブルオブジェクトの最大数。

  • performance_schema_max_table_instances

    コマンド行形式--performance-schema-max-table-instances=#
    システム変数名前performance_schema_max_table_instances
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト50000
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)

    インストゥルメントされるテーブルオブジェクトの最大数。

  • performance_schema_max_thread_classes

    コマンド行形式--performance-schema-max-thread-classes=#
    システム変数名前performance_schema_max_thread_classes
    変数スコープグローバル
    動的変数いいえ
    許可されている値数値
    デフォルト50

    スレッドインストゥルメントの最大数。

  • performance_schema_max_thread_instances

    コマンド行形式--performance-schema-max-thread-instances=#
    システム変数名前performance_schema_max_thread_instances
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト1000
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)

    インストゥルメントされるスレッドオブジェクトの最大数。この値は threads テーブルのサイズを制御します。この最大を超えたため、スレッドをインストゥルメントできない場合、パフォーマンススキーマは Performance_schema_thread_instances_lost ステータス変数を増分します。

    max_connections システム変数はサーバーで実行するスレッド数に影響します。performance_schema_max_thread_instances はこれらの実行中のスレッドのうちインストゥルメント可能なスレッド数に影響します。performance_schema_max_thread_instances のデフォルト値は、max_connections の値に基づいて自動サイズ設定されます。

  • performance_schema_session_connect_attrs_size

    導入5.6.6
    コマンド行形式--performance-schema-session-connect-attrs-size=#
    システム変数名前performance_schema_session_connect_attrs_size
    変数スコープグローバル
    動的変数いいえ
    許可されている値数値
    デフォルト-1 (autosized)
    最小値-1
    最大値1048576

    接続属性文字列を保持するために使用される、スレッドごとに事前割り当てされるメモリーの量。接続属性文字列が予約されたストレージより大きい場合、Performance_schema_session_connect_attrs_lost ステータス変数が増分されます。この変数は MySQL 5.6.7 で追加されました。

  • performance_schema_setup_actors_size

    導入5.6.1
    コマンド行形式--performance-schema-setup-actors-size=#
    システム変数名前performance_schema_setup_actors_size
    変数スコープグローバル
    動的変数いいえ
    許可されている値数値
    デフォルト100

    setup_actors テーブル内の行数。

  • performance_schema_setup_objects_size

    導入5.6.1
    コマンド行形式--performance-schema-setup-objects-size=#
    システム変数名前performance_schema_setup_objects_size
    変数スコープグローバル
    動的変数いいえ
    許可されている値数値
    デフォルト100

    setup_objects テーブル内の行数。

  • performance_schema_users_size

    導入5.6.3
    コマンド行形式--performance-schema-users-size=#
    システム変数名前performance_schema_users_size
    変数スコープグローバル
    動的変数いいえ
    許可されている値 (<= 5.6.5)数値
    デフォルト10
    最小値0
    最大値1048576
    許可されている値 (>= 5.6.6)数値
    デフォルト-1 (autosized)
    最小値-1
    最大値1048576

    users テーブル内の行数。この変数が 0 の場合、パフォーマンススキーマは users テーブル内の接続統計を保守しません。この変数は MySQL 5.6.3 で追加されました。

22.13 パフォーマンススキーマステータス変数

パフォーマンススキーマは、メモリー制約のためロードまたは作成できなかったインストゥルメンテーションついての情報を提供するいくつかのステータス変数を実装しています。

mysql> SHOW STATUS LIKE 'perf%';+-------------------------------------------+-------+
| Variable_name | Value |
+-------------------------------------------+-------+
| Performance_schema_accounts_lost | 0 |
| Performance_schema_cond_classes_lost | 0 |
| Performance_schema_cond_instances_lost | 0 |
| Performance_schema_file_classes_lost | 0 |
| Performance_schema_file_handles_lost | 0 |
| Performance_schema_file_instances_lost | 0 |
| Performance_schema_hosts_lost | 0 |
| Performance_schema_locker_lost | 0 |
| Performance_schema_mutex_classes_lost | 0 |
| Performance_schema_mutex_instances_lost | 0 |
| Performance_schema_rwlock_classes_lost | 0 |
| Performance_schema_rwlock_instances_lost | 0 |
| Performance_schema_socket_classes_lost | 0 |
| Performance_schema_socket_instances_lost | 0 |
| Performance_schema_stage_classes_lost | 0 |
| Performance_schema_statement_classes_lost | 0 |
| Performance_schema_table_handles_lost | 0 |
| Performance_schema_table_instances_lost | 0 |
| Performance_schema_thread_classes_lost | 0 |
| Performance_schema_thread_instances_lost | 0 |
| Performance_schema_users_lost | 0 |
+-------------------------------------------+-------+

パフォーマンススキーマステータス変数には次の意味があります。

  • Performance_schema_accounts_lost

    accounts テーブルがいっぱいであったため、行を追加できなかった回数。この変数は MySQL 5.6.3 で追加されました。

  • Performance_schema_cond_classes_lost

    ロードできなかった条件インストゥルメントの数。

  • Performance_schema_cond_instances_lost

    作成できなかった条件インストゥルメントインスタンスの数。

  • Performance_schema_digest_lost

    events_statements_summary_by_digest テーブルにインストゥルメントできなかったダイジェストインスタンスの数。performance_schema_digests_size の値が小さすぎる場合、これは 0 以外になることがあります。この変数は MySQL 5.6.5 で追加されました。

  • Performance_schema_file_classes_lost

    ロードできなかったファイルインストゥルメントの数。

  • Performance_schema_file_handles_lost

    オープンできなかったファイルインストゥルメントインスタンスの数。

  • Performance_schema_file_instances_lost

    作成できなかったファイルインストゥルメントインスタンスの数。

  • Performance_schema_hosts_lost

    hosts テーブルがいっぱいであったため、行を追加できなかった回数。この変数は MySQL 5.6.3 で追加されました。

  • Performance_schema_locker_lost

    次の状況のため、失われるか記録されないイベント数。

    • イベントが再帰的です (たとえば、A を待機することによって B で待機が発生し、それによって C で待機が発生したなど)。

    • ネストしたイベントスタックの深さが、実装によって課せられる制限より大きいです。

    現在、パフォーマンススキーマによって記録されるイベントは再帰的でないため、この変数は常に 0 になるはずです。

  • Performance_schema_mutex_classes_lost

    ロードできなかった相互排他ロックインストゥルメントの数。

  • Performance_schema_mutex_instances_lost

    作成できなかった相互排他ロックインストゥルメントインスタンスの数。

  • Performance_schema_rwlock_classes_lost

    ロードできなかった rwlock インストゥルメントの数。

  • Performance_schema_rwlock_instances_lost

    作成できなかった rwlock インストゥルメントインスタンスの数。

  • Performance_schema_session_connect_attrs_lost

    接続属性文字列が予約されたストレージより大きかった回数。この変数は MySQL 5.6.7 で追加されました。

  • Performance_schema_socket_classes_lost

    ロードできなかったソケットインストゥルメントの数。この変数は MySQL 5.6.3 で追加されました。

  • Performance_schema_socket_instances_lost

    作成できなかったソケットインストゥルメントインスタンスの数。この変数は MySQL 5.6.3 で追加されました。

  • Performance_schema_stage_classes_lost

    ロードできなかったステージインストゥルメントの数。この変数は MySQL 5.6.3 で追加されました。

  • Performance_schema_statement_classes_lost

    ロードできなかったステートメントインストゥルメントの数。この変数は MySQL 5.6.3 で追加されました。

  • Performance_schema_table_handles_lost

    オープンできなかったテーブルインストゥルメントインスタンスの数。

  • Performance_schema_table_instances_lost

    作成できなかったテーブルインストゥルメントインスタンスの数。

  • Performance_schema_thread_classes_lost

    ロードできなかったスレッドインストゥルメントの数。

  • Performance_schema_thread_instances_lost

    threads テーブルにインストゥルメントできなかったスレッドインスタンスの数。performance_schema_max_thread_instances の値が小さすぎる場合、これは 0 以外になることがあります。

  • Performance_schema_users_lost

    users テーブルがいっぱいであったため、行を追加できなかった回数。この変数は MySQL 5.6.3 で追加されました。

これらの変数を使用して、パフォーマンススキーマのステータスをチェックすることについては、セクション22.5「パフォーマンススキーマステータスモニタリング」を参照してください。

22.14 パフォーマンススキーマとプラグイン

UNINSTALL PLUGIN によってプラグインを削除することは、そのプラグインのコードですでに収集された情報には影響しません。プラグインのロード中にコードの実行に費やされた時間は、プラグインがあとでアンロードされた場合でも費やされます。集計情報を含む関連付けられたイベント情報は、performance_schema データベーステーブルで読み取り可能なままになります。プラグインのインストールと削除の効果の追加情報については、セクション22.5「パフォーマンススキーマステータスモニタリング」を参照してください。

プラグインコードをインストゥルメントするプラグイン実装者は、プラグインをロードするユーザーがその要件を把握できるように、インストゥルメンテーションの特性をドキュメント化してください。たとえば、サードパーティーストレージエンジンでは、そのドキュメントに、エンジンが相互排他ロックおよびその他のインストゥルメントに必要とするメモリーの量を記載してください。

22.15 問題を診断するためのパフォーマンススキーマの使用

パフォーマンススキーマは、DBA が大まかな推量ではなく、実際に測定して、パフォーマンスのチューニングを行うのに役立つツールです。このセクションでは、この目的でパフォーマンススキーマを使用するいくつかの方法について説明します。ここでの説明は、セクション22.2.3.2「パフォーマンススキーマイベントフィルタリング」で説明しているイベントフィルタリングの使用に依存します。

次の例では、パフォーマンスボトルネックの調査など、反復される問題の分析に使用できる 1 つの方法を示しています。開始するには、パフォーマンスが遅すぎるとみなされ、最適化が必要な反復可能なユースケースが必要であり、すべてのインストゥルメンテーションを有効にすべきです (事前フィルタリングなし)。

  1. ユースケースを実行します。

  2. パフォーマンススキーマテーブルを使用して、パフォーマンスの問題の原因を分析します。この分析は事後フィルタリングに大きく依存します。

  3. 除外する問題領域については、対応するインストゥルメントを無効にします。たとえば、問題が特定のストレージエンジンのファイル I/O に関連していないことが分析に示されている場合、そのエンジンのファイル I/O インストゥルメントを無効にします。次に、履歴およびサマリーテーブルを切り捨て、これまでに収集されたイベントを削除します。

  4. ステップ 1 のプロセスを繰り返します。

    繰り返しのたびに、パフォーマンススキーマの出力、特に events_waits_history_long テーブルに格納される、無意味なインストゥルメントによって発生するノイズが減っていき、このテーブルが固定のサイズである場合、当面の問題の分析に関連するデータが増えていきます。

    繰り返しのたびに、調査は問題の原因に近づいていくはずであり、シグナル/ノイズ率が改善するにつれて、分析が簡単になります。

  5. パフォーマンスボトルネックの原因を突き止めたら、次のような適切な修正措置をとります。

    • サーバーパラメータ (キャッシュサイズ、メモリーなど) をチューニングします。

    • クエリーを違う方法で書いてチューニングします。

    • データベーススキーマ (テーブル、インデックスなど) をチューニングします。

    • コードをチューニングします (これはストレージエンジンまたはサーバー開発者のみに適用されます)。

  6. ステップ 1 から再開して、パフォーマンスへの変更の効果を確認します。

mutex_instances.LOCKED_BY_THREAD_ID および rwlock_instances.WRITE_LOCKED_BY_THREAD_ID カラムは、パフォーマンスボトルネックまたはデッドロックの調査にきわめて重要です。これは、次のようなパフォーマンススキーマインストゥルメンテーションによって可能になります。

  1. スレッド 1 は相互排他ロックを待機してスタックしているとします。

  2. スレッドが何を待機しているかを特定できます。

    SELECT * FROM events_waits_current WHERE THREAD_ID = thread_1;

    たとえば、events_waits_current.OBJECT_INSTANCE_BEGIN にあるように、スレッドが相互排他ロック A を待機していることがクエリー結果に示されます。

  3. 相互排他ロック A を保持しているスレッドを特定できます。

    SELECT * FROM mutex_instances WHERE OBJECT_INSTANCE_BEGIN = mutex_A;

    たとえば、mutex_instances.LOCKED_BY_THREAD_ID にあるように、相互排他ロック A を保持しているのがスレッド 2 であることがクエリー結果に示されます。

  4. スレッド 2 が何を実行しているかを確認できます。

    SELECT * FROM events_waits_current WHERE THREAD_ID = thread_2;
関連キーワード:  テーブル,イベント,events,schema,インストゥルメント,performance,TIMER,history,setup,カラム