13.7.5.16 SHOW ENGINE 構文

SHOW ENGINE engine_name {STATUS | MUTEX}

SHOW ENGINE は、ストレージエンジンに関する動作情報を表示します。これには PROCESS 権限が必要です。このステートメントは、次のバリアントがあります。

SHOW ENGINE INNODB STATUS
SHOW ENGINE INNODB MUTEX
SHOW ENGINE {NDB | NDBCLUSTER} STATUS
SHOW ENGINE PERFORMANCE_SCHEMA STATUS

SHOW ENGINE INNODB STATUS は、InnoDB ストレージエンジンの状態に関する InnoDB 標準モニターからの広範囲にわたる情報を表示します。InnoDB の処理に関する情報を提供する標準モニターやその他の InnoDB モニターについては、セクション14.15「InnoDB モニター」を参照してください。

SHOW ENGINE INNODB MUTEX は、InnoDB 相互排他ロックおよび読み書きロックの統計を表示します。ステートメント出力には、次のカラムがあります。

注記

ほとんどの SHOW ENGINE INNODB MUTEX 出力は 5.6.14 で削除されます。SHOW ENGINE INNODB MUTEX 出力は、MySQL 5.7.2 で完全に削除されます。パフォーマンススキーマテーブル上にビューを作成することによって、比較可能な情報を生成できます。

• Type

  常に InnoDB です。

• Name

  相互排他ロックが実装されているソースファイルと、そのファイル内の相互排他ロックが作成されている行番号。この行番号は、使用している MySQL のバージョンに固有です。

• Status

  相互排他ロックのステータス。MySQL のコンパイル時に WITH_DEBUG が定義された場合、このフィールドにはいくつかの値が表示されます。WITH_DEBUG が定義されなかった場合、このステートメントは os_waits 値のみを表示します。後者の (WITH_DEBUG なしの) 場合は、この出力の基になっている情報が通常の相互排他ロックと、読み書きロックを保護する (複数読み取りまたは単一書き込みを許可する) 相互排他ロックを区別するには不足しています。その結果、出力が、同じ相互排他ロックに対して複数の行を含むように見える可能性があります。

  • count は、相互排他ロックが要求された回数を示します。

  • spin_waits は、スピンロックの実行が必要になった回数を示します。

  • spin_rounds は、スピンロックラウンドの数を示します。(spin_rounds を spin_waits で割ると、平均のラウンド数が得られます。)

  • os_waits は、オペレーティングシステムの待機の数を示します。これは、スピンロックが機能しなかった (スピンロック中に相互排他ロックがロックされず、オペレーティングシステムに譲って待機する必要があった) 場合に発生します。

  • os_yields は、相互排他ロックをロックしようとしているスレッドがそのタイムスライスをあきらめ、オペレーティングシステムに譲った回数を示します (ほかのスレッドの実行を許可すると、相互排他ロックが解放され、ロックできるようになることを前提にしています)。

  • os_wait_times は、オペレーティングシステムの待機に費やされた時間 (ミリ秒単位) を示します。MySQL 5.6 ではタイミングが無効になるため、この値は常に 0 です。

大きなバッファープールでは出力の量がシステム上で膨大になる場合があるため、SHOW ENGINE INNODB MUTEX は、バッファープールブロックの相互排他ロックと読み書きロックをスキップします。(各 16K バッファープールブロック内に 1 つの相互排他ロックと 1 つの読み書きロックが存在し、1G バイトあたり 65,536 個のブロックが存在します。) SHOW ENGINE INNODB MUTEX はまた、待機されなかった (os_waits=0) 相互排他ロックまたは読み書きロックも一覧表示しません。そのため、SHOW ENGINE INNODB MUTEX は、OS レベルの待機を少なくとも 1 回は発生させた、バッファープールの外部の相互排他ロックと読み書きロックに関する情報のみを表示します。

SHOW ENGINE INNODB MUTEX の情報を使用すると、システムの問題を診断できます。たとえば、spin_waits や spin_rounds の値が大きい場合は、スケーラビリティーの問題を示している可能性があります。

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 が理解できるようにすることを目的としています。

Name 値は、それぞれ、内部バッファーとバッファー属性を指定する 2 つの部分で構成されます。バッファー名は、次のように解釈します。

• テーブルとして公開されていない内部バッファーは括弧内に指定されます。例: (pfs_cond_class).row_size、(pfs_mutex_class).memory。

• performance_schema データベース内のテーブルとして公開されている内部バッファーは、そのテーブル名で (括弧なしで) 指定されます。例: events_waits_history.row_size、mutex_instances.row_count。

• 全体としてのパフォーマンススキーマに適用される値は、performance_schema で始まります。例: performance_schema.memory。

バッファー属性には、次の意味があります。

• row_size は、実装によって使用される内部レコードのサイズ (テーブル内の行のサイズなど) です。row_size 値は変更できません。

• row_count は、内部レコードの数 (テーブル内の行数など) です。row_count 値は、パフォーマンススキーマの構成オプションを使用して変更できます。

• テーブルの場合、tbl_name.memory は row_size と row_count の積です。全体としてのパフォーマンススキーマの場合、performance_schema.memory は、使用されているすべてのメモリーの合計 (ほかのすべての memory 値の合計) です。

場合によっては、パフォーマンススキーマの構成パラメータと SHOW ENGINE 値の間に直接の関係が存在します。たとえば、events_waits_history_long.row_count は performance_schema_events_waits_history_long_size に対応します。その他の場合、この関係はより複雑です。たとえば、events_waits_history.row_count は、performance_schema_events_waits_history_size (スレッドあたりの行数) に performance_schema_max_thread_instances (スレッドの数) を掛けた値に対応します。

SHOW ENGINE NDB STATUS  サーバーで NDB ストレージエンジンが有効になっている場合、SHOW ENGINE NDB STATUS は、接続されているデータノードの数、クラスタの接続文字列、クラスタバイナリログのエポックや、クラスタに接続したときに MySQL Server によって作成されたさまざまなクラスタ API オブジェクトの数などのクラスタステータス情報を表示します。このステートメントからのサンプル出力を次に示します。

mysql> SHOW ENGINE NDB STATUS;
+------------+-----------------------+--------------------------------------------------+
| Type       | Name                  | Status                                           |
+------------+-----------------------+--------------------------------------------------+
| ndbcluster | connection            | cluster_node_id=7,
  connected_host=192.168.0.103, connected_port=1186, number_of_data_nodes=4,
  number_of_ready_data_nodes=3, connect_count=0                                         |
| ndbcluster | NdbTransaction        | created=6, free=0, sizeof=212                    |
| ndbcluster | NdbOperation          | created=8, free=8, sizeof=660                    |
| ndbcluster | NdbIndexScanOperation | created=1, free=1, sizeof=744                    |
| ndbcluster | NdbIndexOperation     | created=0, free=0, sizeof=664                    |
| ndbcluster | NdbRecAttr            | created=1285, free=1285, sizeof=60               |
| ndbcluster | NdbApiSignal          | created=16, free=16, sizeof=136                  |
| ndbcluster | NdbLabel              | created=0, free=0, sizeof=196                    |
| ndbcluster | NdbBranch             | created=0, free=0, sizeof=24                     |
| ndbcluster | NdbSubroutine         | created=0, free=0, sizeof=68                     |
| ndbcluster | NdbCall               | created=0, free=0, sizeof=16                     |
| ndbcluster | NdbBlob               | created=1, free=1, sizeof=264                    |
| ndbcluster | NdbReceiver           | created=4, free=0, sizeof=68                     |
| ndbcluster | binlog                | latest_epoch=155467, latest_trans_epoch=148126,
  latest_received_binlog_epoch=0, latest_handled_binlog_epoch=0,
  latest_applied_binlog_epoch=0                                                         |
+------------+-----------------------+--------------------------------------------------+

Name カラム内に connection と binlog を含む行は、MySQL 5.1 でこのステートメントの出力に追加されました。これらの各行内の Status カラムは、それぞれ、MySQL サーバーのクラスタへの接続に関する情報と、クラスタバイナリログのステータスに関する情報を提供します。Status 情報は、カンマで区切られた一連の名前と値のペアの形式をしています。

connection 行の Status カラムには、次の表で説明されている名前と値のペアが含まれています。

名前	値
cluster_node_id	クラスタ内の MySQL サーバーのノード ID
connected_host	MySQL サーバーが接続されているクラスタ管理サーバーのホスト名または IP アドレス
connected_port	MySQL サーバーが管理サーバー (connected_host) に接続するために使用するポート
number_of_data_nodes	クラスタのために構成されているデータノードの数 (つまり、そのクラスタの config.ini ファイル内の [ndbd] セクションの数)
number_of_ready_data_nodes	実際に実行されているクラスタ内のデータノードの数
connect_count	この mysqld がクラスタデータノードに接続または再接続した回数

binlog 行の Status カラムには、MySQL Cluster レプリケーションに関連した情報が含まれています。そこに含まれている名前と値のペアについて、次の表で説明します。

名前	値
latest_epoch	この MySQL サーバー上で直近で実行された最新のエポック (つまり、このサーバー上で実行された最新のトランザクションのシーケンス番号)
latest_trans_epoch	クラスタのデータノードによって処理された最新のエポック
latest_received_binlog_epoch	バイナリログスレッドによって受信された最新のエポック
latest_handled_binlog_epoch	(バイナリログへの書き込みのために) バイナリログスレッドによって処理された最新のエポック
latest_applied_binlog_epoch	実際にバイナリログに書き込まれた最新のエポック

詳細は、セクション18.6「MySQL Cluster レプリケーション」を参照してください。

クラスタのモニタリングにもっとも役立つ可能性のある SHOW ENGINE NDB STATUS の出力の残りの行を、次に Name で一覧表示します。

• NdbTransaction: 作成された NdbTransaction オブジェクトの数とサイズ。NdbTransaction は、NDB テーブル上で (CREATE TABLE や ALTER TABLE などの) テーブルスキーマ操作が実行されるたびに作成されます。

• NdbOperation: 作成された NdbOperation オブジェクトの数とサイズ。

• NdbIndexScanOperation: 作成された NdbIndexScanOperation オブジェクトの数とサイズ。

• NdbIndexOperation: 作成された NdbIndexOperation オブジェクトの数とサイズ。

• NdbRecAttr: 作成された NdbRecAttr オブジェクトの数とサイズ。一般に、これらのいずれかは、SQL ノードによってデータ操作ステートメントが実行されるたびに作成されます。

• NdbBlob: 作成された NdbBlob オブジェクトの数とサイズ。NdbBlob は、NDB テーブル内の BLOB カラムに関連する新しい操作が実行されるたびに作成されます。

• NdbReceiver: 作成されたすべての NdbReceiver オブジェクトの数とサイズ。created カラム内の数は、MySQL サーバーが接続されているクラスタ内のデータノードの数と同じです。

注記

現在のセッション中に、このステートメントが実行されている SQL ノードにアクセスしている MySQL クライアントによって NDB テーブルに関連する操作が実行されていない場合、SHOW ENGINE NDB STATUS は空の結果を返します。