サーバステータスは、様々なサーバの状態を返します。
現在のサーバステータスを確認するには、以下のSQL文を発行します。
SHOW STATUS; SHOW STATUS LIKE 'Qcache%';
サーバステータスを変更することは出来ません。
サーバステータスは主に、各種システム変数の調整をするために
利用されます。つまりパフォーマンスチューニング用です。
以下、MySQL5.0.16対応のサーバステータス一覧です。
クエリキャッシュの空きブロック数。
この値が0以上の場合、クエリキャッシュにはまだ余裕があります。
query_cache_size システム変数でキャッシュサイズを指定できます。
クエリキャッシュの空きメモリ（byte単位）。
この値が0以上の場合、クエリキャッシュにはまだ余裕があります。
query_cache_size システム変数でキャッシュサイズを指定できます。
キャッシュヒット数。
SQL実行時、キャッシュ内から結果を返せる場合にこの値が増加します。
キャッシュに加えられたクエリ数。
SQL実行時、キャッシュ内から結果を返せないが
その後同じSQLが発行された場合にキャッシュを使えるように
キャッシュに加えられたクエリが発行された場合にこの値が増加します。
メモリ不足によりキャッシュから削除されたクエリ数。
この値が大きい場合、
query_cache_size システム変数でキャッシュサイズを増やすことで
キャッシュの効率を上げる事が出来るでしょう。
キャッシュされなかったクエリ数。
SQL_NO_CACHE キーワード付きでSQLが発行されたり
結果が query_cache_limit より大きかった場合など、
クエリ結果はキャッシュされません。
キャッシュに登録されているクエリ数。
クエリキャッシュの総ブロック数。
query_cache_size / query_cache_min_res_unit で計算できます。
MySQLはNDB Clusterストレージエンジンに
指定の名前を持ったテーブルについて知っているかどうかを問い合わせる事が出来ます。
この動作はディスカバリー(discovery)と呼ばれています。
このステータス値は、ディスカバーされた回数を返します。
中断された接続の数。
接続を明示的に閉じないままクライアントが終了した場合に
この値が増加します。
定期的に増えているようなら、どこかで接続を閉じていない
システムがあるかもしれません。
MySQLサーバに接続しようとして失敗した回数。
単一トランザクション間で binlog_cache_size を超えるSQL文が発行された
回数(トランザクション単位)。
この場合、バイナリログ出力のためにテンポラリファイルが使用された為に
パフォーマンス低下を招いている可能性があります。
バイナリログキャッシュが使用されたトランザクション数。
この数と Binlog_cache_disk_use の合計が
全体のトランザクション数になります。
クライアントから受け取ったデータ内容の総バイト数。
クライアントに送信したデータ内容の総バイト数。
SQLが発行される毎にインクリメントされるカウント。xxx の部分は、delete や insert などが当てはまります。
例えば、DELETE文が発行されると Com_delete ステータス値が1増加します。
SELECT文が発行されると Com_select ステータス値が増加しますが
クエリキャッシュが使われた場合は代わりに Qcache_hits ステータス値が増加します。
MySQL5.0.16から導入されました。
現在の接続がクライアント/サーバ間の圧縮プロトコルを
使っているかどうかを返します。
MySQLサーバへの接続試行回数(成功/不成功に関わらず)を返します。
サーバによって暗黙的にディスク上に生成されたテンポラリテーブルの数。
mysqldが生成したテンポラリファイルの数。
サーバによって暗黙的にメモリ内に生成されたテンポラリテーブルの数。
前述の Created_tmp_disk_tables の値が大きい場合には、
tmp_table_size を大きくすることによって
ディスクベースではなくメモリベースのテンポラリテーブルを
使う回数が増えるはずです。
INSERT DELAYED 文によるレコード挿入時に発生したエラー数。
大抵の場合、これはレコード重複エラーによるものです。
現在のMySQLでは、全てのカラムがデフォルト値を持っていて
挿入しようとした値が不正だった場合でも
MySQLは可能な限りその値を加工して挿入を試みます。
例えば、サイズ10のカラムに20文字の文字列をINSERTしようとした場合
MySQLは文字長を10に切り詰めます(エラーは返しません)。
これによって、MySQLではINSERT時にエラーが発生する場面というのは
限られてきます。
その中で最も一般的なのが、レコード重複エラーという訳です。
なお、この動作は将来のMySQLでは変更される可能性もあります。
不正な値を挿入しようとしたときに、エラーを返すようになるという事です。
これは他DBとの互換性が考慮されています。
一般的に、値の不正チェックはプログラム側で行いDB側で行うべきではありません。
なぜなら、DBによってそのチェック方法が異なるからです。
つまり、こういう手法を取っていると
他DBへ移行することが難しくなります。
INSERT DELAYED文によって生成されたスレッド数。
INSERT DELAYED文によって挿入されたレコード数。
FLUSH文を実行した回数。
COMMITを内部的に実行した回数。
テーブルから列が削除された回数。
インデックスから最初のエントリーが読み込まれた回数。
この値が大きい場合は、サーバがインデックスのフルスキャンを
多く行っているという事です。
例えば、col1にインデックスが張られたテーブルに対する
SELECT col1 FROM foo
文の実行などが当てはまります。
インデックスのフルスキャンは、インデックスを張らない場合より
処理が遅くなる可能性があります。
キーに基づいたレコード読み込みが要求された回数。
この値が大きい事は、適切にインデックス化されたテーブルおよび
クエリを使っているという証になります。
キー順序による次レコードの読み込みが要求された回数。
インデックススキャンやインデックスによる範囲指定を行ったときに
この値が増加します。
キー順序による前レコードの読み込みが要求された回数。
この読み込みは主に ORDER BY ... DESC を最適化するために利用されます。
固定位置に基づいたレコード読み込み要求の数。
結果のソートが必要なクエリを大量に発行した場合、この値が大きくなります。
テーブルの全件スキャンや適切にキーを使えない結合を持ったクエリを
発行している可能性があります。
データファイル上での次レコード読み込みが要求された回数。
テーブルスキャンを多く実行したとき、この値が大きくなります。
このことは通常、テーブルに適切なインデックスが張られていないか
インデックスを利用できないようなクエリを発行していることを意味します。
ROLLBACKを内部的に実行した回数。
レコード更新を行った回数。
レコード挿入を行った回数。
キーキャッシュ内で変更されたが
まだディスクにフラッシュされていないキーブロック数。
キーキャッシュ中の未使用ブロック数。
この値を元に、key_buffer_size システム変数の値を決定する
目安とすることが出来ます。
キーキャッシュ中の使用ブロック数。
この値は過去の最大数(high-water mark)を示します。
キャッシュ内キーブロックからの読み込み要求数。
ディスク内キーブロックからの読み込み要求数。
この値が大きい場合、おそらく
key_buffer_size システム変数の値が小さすぎます。
キャッシュミス率は「Key_reads / Key_read_requests」により計算できます。
キャッシュ内キーブロックへの書き込み要求数。
ディスク内キーブロックへの書き込み要求数。
MySQL5.0.1から導入されました。
最後にコンパイルされたクエリの総コスト。
これは、同一クエリに関する異なるクエリプランのコスト比較に有用です。
デフォルト値の0は、クエリがまだコンパイルされていない事を示します。
サーバが起動してから今までの間、同時接続していた数の最大値。
INSERT DELAYED文で発行された後、まだ書き込まれずに待機しているレコード数。
開いているファイル数。
開いているストリーム数(主にログとして使われる)。
現在開いているテーブル数。
今までに開いたテーブル数。
この値が大きい場合は、テーブルキャッシュのサイズが小さすぎるかもしれません。
table_cache システム変数で、キャッシュサイズを変更できます。
サーバに送信されたクエリ数。
未実装です。
インデックスを使わない結合を使った回数。
この値が0でない場合は、テーブルのインデックスを調べた方がいいでしょう。
参照テーブルで範囲指定をした結合を使った回数。
(結合の)先頭テーブルで範囲指定をした結合を使った回数。
この数値が大きくても、通常はそれほど致命的な問題ではありません。
各レコード毎にキー使用をチェックするキーを使わない結合の数。
…正直、自分でも訳してて意味がわかりません(笑)。
この値が0でない場合は、テーブルのインデックスを調べた方がいいでしょう。
(結合の)先頭テーブルでフルスキャンを行っている結合を使った回数。
これは非常に好ましくない結合なので、この値が0でない場合には
何らかの処置をして方が良いでしょう。
スレーブのSQLスレッドによって現在開かれているテンポラリテーブルの数。
この値が ON のとき、このサーバはマスタに繋ぐスレーブとして動作しています。
MySQL5.0.4から導入されました。
スレーブのSQLスレッドがトランザクションを再試行した回数。
生成に slow_launch_time で指定された秒数以上掛かったスレッドの数。
発行に long_query_time で指定された秒数以上掛かったクエリの数。
ソートアルゴリズムで必要になったマージパスの総数。
この値が大きい場合、sort_buffer_size システム変数の値を
大きくすることを検討しましょう。
範囲指定されたソートを行った回数。
ソートされた行数。
テーブルスキャンによるソートを行った回数。
SSL接続に使われるステータス。
テーブルロックが即座に実行された回数。
テーブルロックが即座には実行されず、ウェイトが必要だった回数。
この値が大きく、パフォーマンス上の問題が発生した場合
まずクエリを最適化しましょう。
さらに、テーブルを分割するか
レプリケーションを使用して負荷を分散するなどしましょう。
スレッドキャッシュ内に存在するスレッド数。
現在開かれている接続(スレッド)数。
接続用に生成されたスレッド数。
この値が大きい場合、thread_cache_size システム変数の値を大きくして
キャッシュサイズを増やしましょう。
Threads_created / Connections でキャッシュヒット率を計算できます。
現在動いているスレッド数。
サーバ起動時からの経過秒数。