その他の管理ステートメント

1. CACHE INDEX 構文
2. FLUSH 構文
3. KILL 構文
4. LOAD INDEX INTO CACHE 構文
5. RESET 構文

1. CACHE INDEX 構文

CACHE INDEX
  tbl_index_list [, tbl_index_list] ...
  IN key_cache_name

tbl_index_list:
  tbl_name [[INDEX|KEY] (index_name[, index_name] ...)]

CACHE INDEX ステートメントはテーブル インデックスを特定のキー キャッシュに割り当てます。これは MyISAM テーブルにしか利用されません。

次のステートメントは、インデックスをテーブル t1、t2、そして t3 から hot_cache という名前のキー キャッシュに割り当てます。

mysql> CACHE INDEX t1, t2, t3 IN hot_cache;
+---------+--------------------+----------+----------+
| Table   | Op                 | Msg_type | Msg_text |
+---------+--------------------+----------+----------+
| test.t1 | assign_to_keycache | status   | OK       |
| test.t2 | assign_to_keycache | status   | OK       |
| test.t3 | assign_to_keycache | status   | OK       |
+---------+--------------------+----------+----------+

CACHE INDEX の構文によって、テーブルからの特定のインデックスだけがキャッシュに割り当てられなければいけない、と指定する事ができます。現在のインプリメンテーションは、全てのテーブルのインデックスをキャッシュに割り当てるので、テーブル名以外を指定する利用は無いのです。

CACHE INDEX ステートメント内で参照されるキー キャッシュは、パラメータ設定ステートメントを設定するか、サーバ パラメータ設定の中で作成できます。例:

mysql> SET GLOBAL keycache1.key_buffer_size=128*1024;

キー キャッシュ パラメータには、構造化システム変数のメンバとしてアクセスできます。詳しくは 項1. 「構造化システム変数」 を参照してください。

キー キャッシュは、インデックスをそれに割り当てる前に存在していなければいけません。

mysql> CACHE INDEX t1 IN non_existent_cache;
ERROR 1284 (HY000): Unknown key cache 'non_existent_cache'

デフォルトで、テーブル インデックスは、サーバ起動時に作成された主要（デフォルト）キー キャッシュに割り当てられます。キー キャッシュが破壊される時、そこに割り当てられた全てのインデックスはデフォルト キーキャッシュに再び割り当てられます。

インデックスの割り当ては、サーバに対してグローバルに影響します。もし1つのクライアントが既存のキャッシュにインデックスを割り当てると、どのクライアントがクエリを発行したかに関わらず、このキャッシュはそのインデックスを含む全てのクエリに対して利用されます。

2. FLUSH 構文

FLUSH [LOCAL | NO_WRITE_TO_BINLOG]
    flush_option [, flush_option] ...

FLUSH ステートメントは、MySQL に利用された様々な内部キャッシュをクリア、または再ロードします。FLUSH を実行する為には、RELOAD 権限を持つ必要があります。

RESET ステートメントは FLUSH と似ています。詳しくは 項5. 「RESET 構文」 を参照してください。

flush_option は、次のうちのどれかになり得ます。

  • HOSTS

    ホスト キャッシュ テーブルを空にします。もし、いくつかのホストが IP 番号を変えたり、エラー メッセージ Host 'host_name' is blocked を受け取ったりしたら、ホスト テーブルをフラッシュする必要があります。MySQL サーバに接続中に、連続して max_connect_errors 以上のエラーがホストに発生すると、MySQL は何か異常があると仮定して、それ以上の接続の要求をブロックします。ホスト テーブルをフラッシュすると、ホストは再度接続を試みる事ができます。詳しくは 項B. 「Host 'host_name' is blocked」 を参照してください。このエラー メッセージを避ける為に、--max_connect_errors=999999999 を利用して mysqld をスタートする事ができます。

  • DES_KEY_FILE

    サーバ起動時に --des-key-file オプションを利用して指定されたファイルからの DES キーを再ロードします。

  • LOGS

    全てのログ ファイルを閉じ、再オープンします。もしバイナリ ログが有効であれば、バイナリ ログ ファイルのシーケンス番号は前のファイルと比較して1つ増加されます。これは Unix では、SIGHUP シグナルを mysqld サーバに送信する事と同じです。(mysqld が SIGHUP と SIGQUIT を無視する Mac OS X 10.3 バージョン以外)

    もしサーバが --log-error オプションでスタートされたら、それは FLUSH LOGS によって -old のサフィックスを利用して現在のエラー ログ ファイルをリネームし、新しく空のログ ファイルを作成します。もし --log-error オプションがなければリネームは行われません。

  • MASTER (DEPRECATED)全てのバイナリ ログを削除し、バイナリ ログ インデックス ファイルをリセットし、新しいバイナリ ログを作成します。FLUSH MASTER は RESET MASTER と置き換えられ廃止予定であり、現在は後方互換だけがサポートされています。詳しくは 項2. 「RESET MASTER 構文」 を参照してください。

  • PRIVILEGES

    mysql データベース内で供与テーブルから権限を再ロードします。

  • QUERY CACHE

    メモリ使用を向上させる為にクエリ キャッシュをデフラグします。FLUSH QUERY CACHE は RESET QUERY CACHE とは違い、キャッシュからクエリを削除しません。

  • SLAVE (DEPRECATED)リレー ログ ファイルやマスタのバイナリ ログ内の複製位置を含む、全ての複製スレーブ パラメータをリセットします。FLUSH SLAVE は RESET SLAVE と置き換えられ廃止予定であり、現在は後方互換だけがサポートされています。詳しくは 項5. 「RESET SLAVE 構文」 を参照してください。

  • STATUS

    このオプションは、グローバル値に現在のスレッドのセッション ステータス変数値を追加し、セッション値をゼロにリセットします。それはキー キャッシュ(デフォルトと名づけられた物)のカウンタをゼロにリセットし、現在オープンしている接続の数に Max_used_conections を設定します。これは、クエリをデバグしている時のみ利用するべき物です。詳しくは 項1.7. 「質問またはバグの報告」 を参照してください。

  • {TABLE | TABLES} [tbl_name [, tbl_name] ...]

    どのテーブル名づけられていない時に、全てのオープンなテーブルを閉じ、利用中の全てのテーブルを強制的に閉じます。これはクエリ キャッシュもフラッシュします。複数のテーブル名があると、与えられたテーブルだけをフラッシュします。FLUSH TABLES は RESET QUERY CACHE のように、クエリ キャッシュから全てのクエリ結果の削除もします。

  • TABLES WITH READ LOCK

    UNLOCK TABLES を実行して明示的にロックを解除するまで、リード ロックを利用して全てのデータベースの全てのオープン テーブルを閉じ、全てのテーブルをロックします。これは、もし Veritas のような、時間内にスナップショットを撮る事ができるファイル システムを持っているなら、バックアップを取るのに大変便利な方法になります。

    FLUSH TABLES WITH READ LOCK は、グローバル リード ロックは取得しますがテーブル ロックはしないので、テーブル ロックと暗黙的なコミットに関しては LOCK TABLES と UNLOCK TABLES と同じような動作の制約は受けません。

    • UNLOCK TABLES は、もしテーブルが現在 LOCK TABLES でロックされていたらトランザクションを行います。これは、FLUSH TABLES WITH READ LOCK ステートメントがテーブル レベル ロックを取得しない為、これに続く UNLOCK TABLES に対しては行われません。

    • トランザクションを開始すると、LOCK TABLES を利用して行ったテーブル ロックを、まるで UNLOCK TABLES を実行したかのように解除してしまいます。トランザクションを開始しても、FLUSH TABLES WITH READ LOCK を利用して行われたグローバル リード ロックの解除はしません。

  • USER_RESOURCES

    全ての時間あたりのユーザ リソースをゼロにリセットします。これは、時間ごとの接続、クエリ、更新リミットに達したクライアントがすぐに活動を再開できるようにします。FLUSH USER_RESOURCES は最大同時接続のリミットに適応しません。詳しくは 項3. 「GRANT 構文」 を参照してください。

FLUSH ステートメントは、任意の NO_WRITE_TO_BINLOG キーワード(またはそのエイリアス LOCAL) が利用されない限り、バイナリ ログに書きこまれます。これは、複製マスタとして機能している MySQL サーバ上で利用される FLUSH ステートメントが、複製スレーブにデフォルトで複製される為に行われます。

注意:FLUSH LOGS、FLUSH MASTER、FLUSH SLAVE、そして FLUSH TABLES WITH READ LOCK は、スレーブに複製されると問題を引き起こす為、ログインされません。

flush-hosts、flush-logs、flush-privileges、flush-status、または flush-tables コマンドを利用する mysqladmin ユーティリティで、いくつかのステートメントにアクセスする事ができます。

注意:MySQL 5.1 内では、ストアド ファンクションやトリガ内で FLUSH ステートメントを発行する事は不可能です。しかし、ストアド プロシージャ内の FLUSH がストアド ファンクションやトリガにコールされない限り、それらを利用してもよいでしょう。詳しくは 項D.1. 「ストアド ルーチンとトリガの規制」 を参照してください。

RESET ステートメントが複製の中でどのように利用されるかという情報については 項5. 「RESET 構文」 も参照してください。

3. KILL 構文

KILL [CONNECTION | QUERY] thread_id

mysqld への各接続は別々のスレッド内で起動します。どのスレッドが SHOW PROCESSLIST ステートメントを利用し、スレッドを停止させるのかを、KILL thread_id ステートメントを利用して確認する事ができます。

KILL は任意の CONNECTION か QUERY 修飾子を許容します。

  • KILL CONNECTION は修飾子を持たない KILL と同じです。それは thread_id と関連している接続を終了します。

  • KILL QUERY は現在接続が実行中であるステートメントを終了させますが、その接続自体には手をつけずそのまま残しておきます。

もし PROCESS 権限を持っていれば、全てのスレッドを見る事ができます。もし SUPER 権限を持っていれば、全てのスレッドとステートメントを停止する事ができます。そうでなければ、自分自身のスレッドとステートメントのみ確認、停止させる事ができます。

mysqladmin processlist と mysqladmin kill コマンドを利用して、スレッドを検査、停止する事もできます。

注意:埋め込みサーバは、ホスト アプリケーションのスレッド内ではほとんど起動しないので、KILL と埋め込み MySQL サーバ ライブラリを一緒に利用する事はできません。それは、それ自身の接続スレッドは作成しません。

KILL を利用する時、スレッド固有のキル フラッグがスレッドに設定されます。ほとんどの場合、キル フラッグは特定のインターバルでしか確認されないので、スレッドが停止するまでに少し時間がかかります。

  • SELECT,ORDER BY そして GROUP BY ループ内では、フラッグは行のブロックを読み込んだ後に確認されます。もしキル フラッグが設定されると、ステートメントは異常終了します。

  • ALTER TABLE の最中に、行の各ブロックが元テーブルから読み込まれる前にキル フラッグが確認されます。もしキル フラッグが設定されると、ステートメントは異常終了し、テンポラリ テーブルは削除されます。

  • UPDATE や DELETE 操作の最中に、各ブロックの読み込みや、行の各更新や削除の後でキル フラッグが確認されます。もしキル フラッグが設定されると、ステートメントは異常終了します。もしトランザクションを利用していなければ、変更はロールバックされない事に注意してください。

  • GET_LOCK() は NULL を異常終了し、返します。

  • INSERT DELAYED スレッドはメモリ内に持っている全ての行をすばやくフラッシュ(挿入)します。

  • もしスレッドがテーブル ロック ハンドラ内にあれば、(状態: Locked) テーブルロックは迅速に異常終了します。

  • もしスレッドが書き込みコール内でフリー ディスク スペースを待っていたら、その書き込みは 「disk full」 エラー メッセージを利用して異常終了されます。

  • 警告: MyISAM テーブル上で REPAIR TABLE や OPTIMIZE TABLE 操作を終了させると、テーブルが破損され、利用不可能になります。それを最適化、または修復するまで(割り込み無しで)、そのようなテーブルへの書き込みや読み込みは失敗します。

4. LOAD INDEX INTO CACHE 構文

LOAD INDEX INTO CACHE
  tbl_index_list [, tbl_index_list] ...

tbl_index_list:
  tbl_name
    [[INDEX|KEY] (index_name[, index_name] ...)]
    [IGNORE LEAVES]

LOAD INDEX INTO CACHE ステートメントは、明示的な CACHE INDEX ステートメントによって割り当てられたキー キャッシュに、またはそうでなければデフォルトのキー キャッシュに、テーブル インデックスをあらかじめロードしておきます。LOAD INDEX INTO CACHE は MyISAM テーブルにだけ利用されます。

IGNORE LEAVES 修飾子は、インデックスの非リーフ ノードの為のブロックだけがあらかじめロードされるよう働きかけます。

次のステートメントは、(index blocks) テーブル t1 と t2 のインデックスのノード(インデックスブロック)をあらかじめロードしておきます。

mysql> LOAD INDEX INTO CACHE t1, t2 IGNORE LEAVES;
+---------+--------------+----------+----------+
| Table   | Op           | Msg_type | Msg_text |
+---------+--------------+----------+----------+
| test.t1 | preload_keys | status   | OK       |
| test.t2 | preload_keys | status   | OK       |
+---------+--------------+----------+----------+

このステートメントは t1 から全てのインデックス ブロックをあらかじめロードしておきます。それは、t2 から非リーフ ノードのブロックだけをあらかじめロードします。

LOAD INDEX INTO CACHE の構文によって、テーブルからの特定のインデックスだけがあらかじめロードされなければいけない、と指定する事ができます。現在のインプリメンテーションは、全てのテーブルのインデックスをキャッシュ内に割り当てるので、テーブル名以外を指定する利用は無いのです。

LOAD INDEX INTO CACHE は、テーブル内の全てのインデックスが同じブロック サイズでなければ失敗します。myisamchk -dv を利用し、Blocksize カラムを確認する事で、テーブルのインデックス ブロック サイズを決定する事ができます。

5. RESET 構文

RESET reset_option [, reset_option] ...

RESET ステートメントは様々なサーバ操作の状態をクリアする為に利用されます。RESET を実行する為には RELOAD 権限を持つ必要があります。

RESET は FLUSH ステートメントの、より強力バージョンとして機能します。詳しくは 項2. 「FLUSH 構文」 を参照してください。

reset_option は、次のうちのどれかになり得ます。

  • MASTER

    インデックス ファイル内にリストされている全てのバイナリ ログを削除し、バイナリ ログ インデックス ファイルをゼロにリセットし、新しいバイナリ ログを作成します。(MySQL 3.23.26 以前のバージョンでは FLUSH MASTER として知られています。)詳しくは 項 「マスタ サーバをコントロールする SQL ステートメント」 を参照してください。

  • QUERY CACHE

    クエリ キャッシュから全てのクエリ結果を削除します。

  • SLAVE

    スレーブがマスタ バイナリ ログ内の複製位置を忘れるよう働きかけます。また、既存リレー ログ ファイルを削除する事で、リレー ログをリセットし、新しい物を開始します。(MySQL 3.23.26 以前のバージョンでは FLUSH SLAVE として知られています。)詳しくは 項 「スレーブ サーバをコントロールする SQL ステートメント」 を参照してください。