サーバには様々なステータス変数が存在し、オペレーションに関する情報交換をしています。その変数と値は、SHOW
[GLOBAL] STATUS
ステートメントを使用して、閲覧できます。オプションの
GLOBAL
キーワードは全体的な接続において、値を集約します。
mysql> SHOW GLOBAL STATUS;
+-----------------------------------+------------+
| Variable_name | Value |
+-----------------------------------+------------+
| Aborted_clients | 0 |
| Aborted_connects | 0 |
| Bytes_received | 155372598 |
| Bytes_sent | 1176560426 |
...
| Connections | 30023 |
| Created_tmp_disk_tables | 0 |
| Created_tmp_files | 3 |
| Created_tmp_tables | 2 |
...
| Threads_created | 217 |
| Threads_running | 88 |
| Uptime | 1389872 |
+-----------------------------------+------------+
ステータス変数の多くは、FLUSH
STATUS ステートメントで 0
にリセットされる。
次に様々なステータス変数を示します。バージョンについて記載のない変数は MySQL 5.1 より前から 実装しています。実装履歴については、MySQL 5.0 Reference Manual を参照してください。
-
接続を適切に閉じないままクライアントが終了したことが原因で中断した接続の数。項B.1.2.10. 「Communication Errors and Aborted Connections」 を参照のこと。
-
MySQLサーバに接続しようとして失敗した回数。 項B.1.2.10. 「Communication Errors and Aborted Connections」 を参照のこと。
-
binlog_cache_sizeの値を超えてテンポラリ ログ キャッシュを使用したトランザクションの回数。トランザクションからステートメントを保存するためにテンポラリ ファイルを使用した場合。 -
テンポラリ バイナリ ログ キャッシュを使用したトランザクションの回数。
-
すべてのクライアントから受信したバイト数。
-
すべてのクライアントへ送信したバイト数。
-
Com_ステートメントのカウンタ値は、それぞれのxxxxxxステートメントを実行した回数を示す。それぞれのステートメント タイプをそれぞれカウントする。たとえば、DELETEでCom_deleteを 1 とし、INSERTでCom_insertを 1 としてカウントする。クエリ結果がクエリ キャッシュから返される場合は、サーバはQcache_hitsステータス値の増加になる。Com_selectではないことに注意が必要。項4.13.4. 「クエリ キャッシュのステータスと保守」 を参照のこと。Com_stmt_値のすべては、準備された文 (prepared statement) の引数が未知、または実行中にエラーが発生した場合でも増加する。つまり、この値は、要求発行回数に対応し、要求を完了 (成功) した回数ではない。xxxCom_stmt_ステータス変数は次の通り。xxxCom_stmt_prepareCom_stmt_executeCom_stmt_fetchCom_stmt_send_long_dataCom_stmt_resetCom_stmt_close
これらの変数は、準備された文 (prepared statement)。名前は ネットワーク レイヤーでし使用した
COM_xxx のコマンド セットを示す。つまり、mysql_stmt_prepare() や mysql_stmt_execute() など、準備されたステートメントの API コールを実行すると、これらの値は増加する。
PREPARE、EXECUTE、DEALLOCATE PREPAREはCom_stmt_prepare、Com_stmt_execute、Com_stmt_closeに対応しているので、同様に増加する。さらに、MySQL 4.1.3 から実装しているため、古いステートメントのカウンタ値は、PREPARE、EXECUTE、DEALLOCATE PREPAREがCom_prepare_sql、Com_execute_sql、Com_dealloc_sqlに対応しているので、これも同様に増加する。Com_stmt_fetchはカーソルからフェッチしたときにネットワーク往復を発行した合計回数のこと。-
接続でクライアント/サーバ間の圧縮プロトコルを 使用しているかどうか (を指す)。(MySQL 5.1.2での追加)
-
(成功/不成功に関わらず) MySQL サーバへの接続試行回数。
-
ステートメント実行中に、ディスク上に作成された暗黙的テンポラリテーブルの数。
-
mysqld が生成したテンポラリ ファイルの数
-
ステートメント実行中に、メモリ上に作成された暗黙的テンポラリテーブルの数。
Created_tmp_disk_tablesの値が大きい場合には、tmp_table_sizeの値も大きくすることによって、テンポラリテーブルをディスクベースではなくメモリベースにすることもできる。 -
エラー発生（
duplicate keyの可能性）により、INSERT DELAYEDで書き込まれたレコードの数。 -
INSERT DELAYEDハンドラ スレッドの数。 -
INSERT DELAYEDで書き込んだレコードの数。 -
FLUSHコマンドの実行回数。 -
内部
COMMITコマンド数。 -
テーブルからレコードを削除した回数。
-
MySQL サーバが
NDB Clusterストレージエンジンに 指定の名前を持ったテーブル認識しているかどうかを問い合わせることができる。この操作をディスカバリー (discovery) と呼ぶ。Handler_discover値は、ディスカバーした回数。 -
2 フェーズ コミット操作の準備フェーズのカウンタ。
-
インデックスから最初のエントリを読み取った回数。 この値が大きい場合、サーバが何回もフル インデックス スキャンを実行している可能性がある。たとえば、
SELECT col1 FROM fooを実行したときに、col1がインデックスになっている場合など。 -
キーに基づいたレコード読み込み要求を受けた回数。この値が大きい場合、クエリをテーブルへ適切にインデックス化していることを示す。
-
キー順序で次レコードの読み込み要求を受けた回数。範囲指定をしてインデックス カラムに対してクエリを実行すると、これがインクリメントする。インデックス スキャンを実行した場合もインクリメントする。
-
キー順序で前レコードの読み込み要求を受けた回数。この読み取り方法は主に、
ORDER BY ... DESCの最適化に使用している。 -
固定位置に基づいたレコード読み込み要求を受けた回数。結果のソートを必要とするクエリを多く実行すると、この値が大きくなる。MySQL でテーブルの全件スキャンや適切にキーを使えない結合を持ったクエリがある可能性がある。
-
データ ファイルで次レコードの読み取り要求を受けた回数。テーブル スキャンの実行が多いと、この値が大きくなる。これは通常、テーブルに適切なインデックス化できない、またはインデックスを利用できないクエリを発行していることを意味する。
-
ROLLBACKを内部的 (ストレージ エンジン) に実行した回数。
-
内部的 (ストレージ エンジン) に セーブポイント (savepoint) の配置要求回数。
-
内部的 (ストレージ エンジン) に セーブポイント (savepoint) へロールバック要求回数。
-
テーブル内のレコードの更新要求回数。
-
テーブルへのレコードの挿入要求回数。
-
データがあるページ数 (ダーティ または クリーン)。
-
Innodb_buffer_pool_pages_dirtyダーティ ページの数。
-
Innodb_buffer_pool_pages_flushedInnoDB がキャッシュするために使用するメモリ バッファの数。
-
空き容量
-
Innodb_buffer_pool_pages_latchedInnoDBのメモリ バッファでラッチした数。データが読み込みまたは書き込みの対象になっていて、フラッシュまたは削除が何らかの理由でできない状態。 -
レコード ロックまたはアダプティブなハッシュ インデックスなどにより、オーバーヘッドの割り当てになったビジー (busy) 状態のデータ。この値は
Innodb_buffer_pool_pages_total–Innodb_buffer_pool_pages_free–Innodb_buffer_pool_pages_dataで算出。 -
Innodb_buffer_pool_pages_totalページのメモリ バッファの合計サイズ。
-
Innodb_buffer_pool_read_ahead_rndInnoDBが開始した 「random (ランダム)」 先読みの数。大型テーブルのクエリ スキャンをランダムに行うと発生する。 -
Innodb_buffer_pool_read_ahead_seqInnoDBが開始した順次的な先読み数。InnoDBが 順次的にフル テーブル スキャンを行うときに発生する。 -
Innodb_buffer_pool_read_requestsInnoDBが行った論理読み込みの数 -
InnoDBがバッファ プールの内容を利用できず、シングル ページ読み込みを行わなければならなかった論理読み込みの回数 -
' 通常、
InnoDBバッファ プールへの書き込みはバックグラウンドで行うが、ページの読み込みまたは作成を行う必要があるのに対して、クリーン ページが得られない場合に、まずそのページがフラッシュするまで待つ必要がある。このカウンタは、その待機回数をカウントする。バッファ プールの値が適切に設定すると、この値は小さくなる。 -
Innodb_buffer_pool_write_requestsInnoDBバッファープールへの書き込み数。 -
ここまでの
fsync()操作数。 -
現在の
fsync()操作保留 (pending) の数。 -
現在の読み込み保留の数。
-
現在の書き込み保留の数。
-
ここまでのデータの読み込み量 (単位:バイト)。
-
データ読み込みの合計数。
-
データ書き込みの合計数。
-
ここまでのデータの書き込み量 (単位:バイト)。
-
Innodb_dblwr_writes,Innodb_dblwr_pages_written二重書き込みの実行回数と、二重書き込みが発生したページ数。項13.5.14.1. 「
InnoDBディスク I/O」 を参照のこと。. -
ログ バッファが小さすぎるために、作業を継続する前にフラッシュ要求で待機した回数。
-
要求ログ書き込みの回数。
-
ログ ファイルへの物理的な書込みの回数。
-
ログ ファイルの
fsync()書き込みをした回数。 -
fsync()待ちのログ ファイル数。 -
ログ ファイルの書き込みの保留回数。
-
ログ ファイルへの書き込みの回数。
-
コンパイル時の
InnoDBページ サイズ (デフォルト 16KB)。多くの値がページ カウントの対象になり、ページ サイズは、それらを容易なバイト変換を可能にする。 -
作成したページの数。
-
読み込みしたページの数。
-
書き込みしたページの数。
-
現在待機している行ロック (row lock) の数。
-
行ロック (row lock)、列の獲得に使用した合計時間 (単位： ミリ秒)。
-
行ロック (row lock)、列の獲得に使用した平均時間 (単位： ミリ秒)。
-
行ロック (row lock)、列の獲得に使用した最長時間 (単位： ミリ秒)。
-
行ロックで待機する必要があった回数。
-
InnoDBテーブルから削除したレコード数。 -
InnoDBテーブルへの挿入レコード数。 -
InnoDBテーブルからの読み込みレコード数。 -
InnoDBテーブルでの更新レコード数。 -
変更後に、まだディスクに未フラッシュのキー キャッシュのキー ブロックの数。
-
キーキャッシュの未使用ブロックの数。どれだけ使用しているか測定するためにこの値を使用することができます。項4.2.3. 「システム変数」において
key_buffer_sizeに関する説明を参照のこと。 -
キーキャッシュのブロックの使用数。この値は、MySQLが起動してから現在に至るまでに同時に使用された最大のブロック数を示します。
-
キャッシュからキー ブロックを読み込んだリクエスト数。
-
ディスクからのキーブロックの物理的読み込み回数。
Key_readsが大きい場合、key_buffer_sizeの値が小さい可能性がある。キャッシュ ミス率はKey_reads/Key_read_requestsと計算する。 -
キャッシュへのキーブロックの書き込んだリクエスト数。
-
ディスクへのキー ブロックの物理的な書き込み回数。
-
クエリ オプティマイザが計算し、最後にコンパイルしたクエリの全コスト。同じクエリの異なるクエリ プランのコストを比較するときに使用する。デフォルト値 0 は、クエリがまだ未コンパイルであることを意味する。
Last_query_costにはセッション スコープがある。 -
サーバが起動してから同時使用した接続の最大数。
-
サーバが MySQL Cluster ノードとして作用している場合、この値はそのクラスタのノード ID。
サーバが MySQL Cluster の一部ではない場合、この値は 0 。
-
サーバが MySQL Cluster の一部である場合、この値は Cluster マネージメント サーバのホスト名または IP アドレスで、コンフィギュレーション データを取得する。
サーバが MySQL Cluster の一部ではない場合、この値は空文字列 。
MySQL 5.1.12 以前では、この変数は
Ndb_connected_hostと呼ばれていた。 -
サーバが MySQL Cluster の一部である場合、この値はポート番号で、ここから、コンフィギュレーション データを取得する Cluster マネージメント サーバに接続。
サーバが MySQL Cluster の一部ではない場合、この値は 0 。
MySQL 5.1.12 以前では、この変数は
Ndb_connected_portと呼ばれていた。 -
サーバが MySQL Cluster の一部である場合、この値はクラスタのデータ ノードの数。
サーバが MySQL Cluster の一部ではない場合、この値は 0 。
MySQL 5.1.12 以前では、この変数は
Ndb_number_of_storage_nodesと呼ばれていた。 -
INSERT DELAY行列への書き込み待ちの行数。 -
開いているファイルの数。
-
開いているストリームの数。(主に、ログの記録で使用）
-
開いているテーブルの数。
-
これまでに開いたテーブル数。
Opened_tablesの値が多い場合、table_open_cacheの値が小さい可能性がある。 -
準備されたステートメントの現在の数。
max_prepared_stmt_countで最大値を与える。(MySQL 5.1.14 での追加) -
クエリ キャッシュ内の空きメモリ ブロックの数
-
クエリ キャッシュ内の空きメモリ ブロック量
-
クエリ キャッシュ ヒットの数。
-
キャッシュに追加したクエリ数。
-
メモリ不足を解消するために、クエリ キャッシュから削除されたクエリの数。
-
キャッシュしないクエリの数。(キャッシュできないか、または
query_cache_typeでキャッシュしない設定) -
クエリ キャッシュに登録したクエリ数。
-
クエリ キャッシュの合計ブロック数。
-
サーバに送信したクエリ数。
-
フェイル セーフ (安全装備) レプリケーションのステータス。未実装。
-
インデックスを使用しない結合の数 (テーブル スキャン)。この値が 0 でない場合、テーブルのインデックスを調べること。
-
関連テーブルで範囲検索を使用した結合の数。
-
ファースト テーブルで範囲指定した部分を使用した結合の数。 通常は、この数値が大きくても、それほど致命的な問題にはならない。
-
キーなしの結合の数。これは、それぞれのレコードのあとにキー使用をチェックする。この値が 0 でない場合、テーブルのインデックスをチェックする必要がある。
-
ファースト テーブルのフル スキャンを行った結合の数。
-
スレーブの SQL スレッドで現在開いているテンポラリ テーブルの数。
-
サーバがマスタに接続しているスレーブの場合は、この値は
ON。 -
起動時から、レプリケーション スレーブの SQL スレッドがトランザクションを再試行した回数のこと。
-
slow_launch_time秒よりも、作成時間を要したスレッドの数。 -
slow_launch_time秒よりも、作成時間を要したクエリの数。項4.11.5. 「スロー クエリ ログ」 を参照のこと。 -
ソート アルゴリズムで必要としたマージ パスの回数。この値が大きい場合は、
sort_buffer_sizeの値を大きくすることを検討する。 -
範囲指定のソートを行った回数。
-
ソートしたレコードの数。
-
テーブル スキャンでソートした回数。
-
SSL接続に使用する変数 (ステータス)。
-
テーブル ロックを直ちに実行した回数。
-
テーブル ロックをすぐには実行できず、待機が必要だった回数。この値が大きい場合、パフォーマンス上の問題がある。まずクエリを最適化し、次にテーブルを分割するかレプリケーションを行う。
-
mysqld で使用するログのメモリ マップ実装では、それ自体が内部の XA トランザクションのリカバリに対してトランザクション コーディネータとして作用するとき、この値は、サーバが起動してからログに使用したページの最大数を示す。
Tc_log_max_pages_usedとTc_log_page_sizeの積が常に、ログ サイズよりも極端に小さい場合は、そのサイズは必要以上に大きいことを示し、減らすことを検討する。このサイズは、--log-tc-sizeオプションで指定できる。現在、この変数は未使用。これはバイナリ ログをベースとしたリカバリには不要で、メモリ マップのリカバリ ログ方法は、ストレージ エンジンが2 フェーズ コミットより大きなものを許容できる場合を除き、使用しない。InnoDBは唯一、対応できるエンジンである。 -
XA リカバリ ログのメモリ マップ実装のページ サイズ。デフォルトには
getpagesize()を使用して値を決める。現在、この変数は未使用で、その理由は、Tc_log_max_pages_usedに記述したものと同じである。 -
リカバリ ログのメモリ マップ実装で、この値は、サーバがトランザクションにコミットできず、ログの空きを待機する必要があると、その度にインクリメント (増加) する。この値が大きい場合、
--log-tc-sizeオプションでログ サイズの増加を検討する。バイナリ ログをベースとしたリカバリでは、この値は、バイナリ ログが 2 フェーズ コミット中のために閉じることができない場合に、その度にインクリメントする。これは、対象となるすべてのトランザクションが完了するまで待機となる。 -
スレッド キャッシュ内のスレッド数。
-
現在開いている接続の数。
-
接続を処理で作成されたスレッドの数。
Threads_createdの値が大きい場合、thread_cache_sizeの値を大きくして キャッシュ サイズを増やす。キャッシュヒット率の計算はThreads_created/Connectionsとする。 -
スリープ状態になっていないスレッドの数。
-
サーバ起動時からの経過秒数。
