MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.7.8.3 FLUSH ステートメント

9.1 English
9.0 English
8.4 English
8.0 English
5.7 English

MySQL 8.0 リファレンスマニュアル / ... / FLUSH ステートメント

このページは機械翻訳したものです。

13.7.8.3 FLUSH ステートメント

FLUSH [NO_WRITE_TO_BINLOG | LOCAL] {
    flush_option [, flush_option] ...
  | tables_option
}

flush_option: {
    BINARY LOGS
  | ENGINE LOGS
  | ERROR LOGS
  | GENERAL LOGS
  | HOSTS
  | LOGS
  | PRIVILEGES
  | OPTIMIZER_COSTS
  | RELAY LOGS [FOR CHANNEL channel]
  | SLOW LOGS
  | STATUS
  | USER_RESOURCES
}

tables_option: {
    TABLES
  | TABLES tbl_name [, tbl_name] ...
  | TABLES WITH READ LOCK
  | TABLES tbl_name [, tbl_name] ... WITH READ LOCK
  | TABLES tbl_name [, tbl_name] ... FOR EXPORT
}

FLUSH ステートメントには、さまざまな内部キャッシュをクリアまたはリロードしたり、テーブルをフラッシュしたり、ロックを取得したりするいくつかのバリアント形式があります。各 FLUSH 操作には、その説明に示されている権限が必要です。

注記

ストアドファンクションまたはトリガー内で FLUSH ステートメントを発行することはできません。ただし、ストアドプロシージャーでは、それがストアドファンクションまたはトリガーから呼び出されないかぎり、FLUSH を使用できます。セクション25.8「ストアドプログラムの制約」を参照してください。

デフォルトでは、FLUSH ステートメントはレプリカにレプリケートされるようにバイナリログに書き込まれます。ロギングを抑制するには、オプションの NO_WRITE_TO_BINLOG キーワード、またはそのエイリアス LOCAL を指定します。

注記

レプリカにレプリケートすると問題が発生するため、FLUSH LOGS, FLUSH BINARY LOGS, FLUSH TABLES WITH READ LOCK (テーブルリストの有無にかかわらず)、および FLUSH TABLES tbl_name ... FOR EXPORT はバイナリログに書き込まれません。

FLUSH ステートメントは暗黙的なコミットを発生させます。セクション13.3.3「暗黙的なコミットを発生させるステートメント」を参照してください。

mysqladmin ユーティリティーは、flush-hosts、flush-logs、flush-privileges、flush-status、flush-tables などのコマンドを使用して、いくつかのフラッシュ操作へのコマンド行インタフェースを提供します。セクション4.5.2「mysqladmin — A MySQL Server 管理プログラム」を参照してください。

SIGHUP または SIGUSR1 シグナルをサーバーに送信すると、FLUSH ステートメントのさまざまな形式に似たフラッシュ操作がいくつか発生します。シグナルは、root システムアカウントまたはサーバープロセスを所有するシステムアカウントによって送信できます。これにより、サーバーに接続せずにフラッシュ操作を実行できるようになり、その操作に十分な権限を持つ MySQL アカウントが必要になります。セクション4.10「MySQL での Unix シグナル処理」を参照してください。

RESET ステートメントは、FLUSH に似ています。レプリケーションでの RESET の使用の詳細は、セクション13.7.8.6「RESET ステートメント」を参照してください。

次のリストに、許可される FLUSH ステートメントの flush_option 値を示します。許可される tables_option 値の説明は、FLUSH TABLES 構文を参照してください。

FLUSH BINARY LOGS

サーバーが書き込んでいるバイナリログファイルを閉じてから再度開きます。バイナリロギングが有効になっている場合は、バイナリログファイルのシーケンス番号が、前のファイルを基準にして 1 増分されます。

この操作には、RELOAD 権限が必要です。
FLUSH ENGINE LOGS

インストールされているストレージエンジンのフラッシュ可能なログを閉じて再度開きます。これにより、InnoDB はログをディスクにフラッシュします。

この操作には、RELOAD 権限が必要です。
FLUSH ERROR LOGS

サーバーが書き込んでいるエラーログファイルを閉じて再度開きます。

この操作には、RELOAD 権限が必要です。
FLUSH GENERAL LOGS

サーバーが書き込んでいる一般クエリーログファイルを閉じて再度開きます。

この操作には、RELOAD 権限が必要です。

この操作は、一般クエリーログに使用されるテーブルには影響しません (セクション5.4.1「一般クエリーログおよびスロークエリーログの出力先の選択」を参照)。
FLUSH HOSTS

キャッシュの内容を公開するホストキャッシュとパフォーマンススキーマ host_cache テーブルを空にし、ブロックされたホストをブロック解除します。

この操作には、RELOAD 権限が必要です。

ホストキャッシュのフラッシュが推奨または望ましい理由については、セクション5.1.12.3「DNS ルックアップとホストキャッシュ」を参照してください。
注記

FLUSH HOSTS は、MySQL 8.0.23 では非推奨です。将来の MySQL リリースでは削除される予定です。代わりに、パフォーマンススキーマ host_cache テーブルを切り捨てます:
```
TRUNCATE TABLE performance_schema.host_cache;
```
TRUNCATE TABLE 操作には、RELOAD 権限ではなく、テーブルに対する DROP 権限が必要です。
FLUSH LOGS

サーバーが書き込んでいるログファイルを閉じて再度開きます。

この操作には、RELOAD 権限が必要です。

この操作の効果は、次の操作を組み合せた効果と同等です:
```
FLUSH BINARY LOGS
FLUSH ENGINE LOGS
FLUSH ERROR LOGS
FLUSH GENERAL LOGS
FLUSH RELAY LOGS
FLUSH SLOW LOGS
```
FLUSH OPTIMIZER_COSTS

コストモデルテーブルに格納されている現在のコスト見積りの使用をオプティマイザが開始するように、コストモデルテーブルを再読取りします。

この操作には、FLUSH_OPTIMIZER_COSTS または RELOAD 権限が必要です。

サーバーは、認識できないコストモデルテーブルエントリについて、エラーログに警告を書き込みます。これらのテーブルの詳細は、セクション8.9.5「オプティマイザコストモデル」を参照してください。この操作は、フラッシュ後に開始されるセッションにのみ影響します。既存のセッションでは、開始時の現行のコスト見積りが引き続き使用されます。
FLUSH PRIVILEGES

mysql システムスキーマの付与テーブルから権限を再度読み取ります。この操作の一環として、サーバーは動的権限割当てを含む global_grants テーブルを読み取り、そこで見つかった未登録の権限を登録します。

この操作には、RELOAD 権限が必要です。

MySQL 権限システムを無効にするためにサーバーの起動時に --skip-grant-tables オプションが指定された場合、FLUSH PRIVILEGES は実行時に権限システムを有効にする方法を提供します。

失敗したログイントラッキングをリセットし (またはサーバーが --skip-grant-tables で起動された場合は有効にします)、一時的にロックされたアカウントのロックを解除します。セクション6.2.15「パスワード管理」を参照してください。

GRANT, CREATE USER, CREATE SERVER および INSTALL PLUGIN ステートメントの結果としてサーバーによってキャッシュされたメモリーを解放します。このメモリーは、対応する REVOKE, DROP USER, DROP SERVER ステートメントおよび UNINSTALL PLUGIN ステートメントによって解放されないため、キャッシュを引き起こすステートメントの多くのインスタンスを実行するサーバーでは、FLUSH PRIVILEGES で解放されないかぎり、キャッシュされたメモリーの使用量が増加します。

caching_sha2_password 認証プラグインで使用されるインメモリーキャッシュをクリアします。 SHA-2 プラガブル認証のキャッシュ操作を参照してください。
FLUSH RELAY LOGS [FOR CHANNEL channel]

サーバーが書き込んでいるリレーログファイルを閉じてから再度開きます。リレーロギングが有効になっている場合、リレーログファイルのシーケンス番号は、前のファイルを基準にして 1 ずつ増分されます。

この操作には、RELOAD 権限が必要です。

FOR CHANNEL channel 句を使用すると、操作を適用するレプリケーションチャネルの名前を指定できます。 FLUSH RELAY LOGS FOR CHANNEL channel を実行して、特定のレプリケーションチャネルのリレーログをフラッシュします。チャネルが指定されておらず、追加のレプリケーションチャネルが存在しない場合、操作はデフォルトチャネルに適用されます。チャネルが指定されておらず、複数のレプリケーションチャネルが存在する場合、操作はすべてのレプリケーションチャネルに適用されます。詳細は、セクション17.2.2「レプリケーションチャネル」を参照してください。
FLUSH SLOW LOGS

サーバーが書き込んでいるスロークエリーログファイルを閉じてから再度開きます。

この操作には、RELOAD 権限が必要です。

この操作は、スロークエリーログに使用されるテーブルには影響しません (セクション5.4.1「一般クエリーログおよびスロークエリーログの出力先の選択」を参照)。
FLUSH STATUS

ステータスインジケータをフラッシュします。

この操作には、FLUSH_STATUS または RELOAD 権限が必要です。

この操作により、すべてのアクティブセッションのセッションステータスがグローバルステータス変数に追加され、すべてのアクティブセッションのステータスがリセットされ、切断されたセッションから集計されたアカウント、ホストおよびユーザーステータス値がリセットされます。セクション27.12.15「パフォーマンススキーマのステータス変数のテーブル」を参照してください。この情報は、クエリーのデバッグ時に使用できます。セクション1.6「質問またはバグをレポートする方法」を参照してください。
FLUSH USER_RESOURCES

時間当たりのすべてのユーザーリソースインジケータをゼロにリセットします。

この操作には、FLUSH_USER_RESOURCES または RELOAD 権限が必要です。

リソースインジケータをリセットすると、毎時の接続、クエリーまたは更新の制限に達したクライアントは、アクティビティをすぐに再開できます。 FLUSH USER_RESOURCES は、max_user_connections システム変数によって制御される同時接続の最大数の制限には適用されません。セクション6.2.20「アカウントリソース制限の設定」を参照してください。

FLUSH TABLES 構文

FLUSH TABLES はテーブルをフラッシュし、使用されているバリアントに応じてロックを取得します。 FLUSH ステートメントで使用される TABLES バリアントは、使用される唯一のオプションである必要があります。 FLUSH TABLE は、FLUSH TABLES のシノニムです。

注記

ここでは、テーブルを閉じることによってフラッシュされることを示す説明は、テーブルの内容をディスクにフラッシュし、開いたままにする InnoDB には異なる方法で適用されます。これにより、他のアクティビティによって変更されないかぎり、テーブルが開いている間もテーブルファイルをコピーできます。

FLUSH TABLES

オープンしているすべてのテーブルをクローズし、使用中のすべてのテーブルを強制的にクローズし、プリペアドステートメントキャッシュをフラッシュします。

この操作には、FLUSH_TABLES または RELOAD 権限が必要です。

プリペアドステートメントキャッシュの詳細は、セクション8.10.3「プリペアドステートメントおよびストアドプログラムのキャッシュ」を参照してください。

アクティブな LOCK TABLES ... READ がある場合、FLUSH TABLES は許可されません。テーブルをフラッシュしてロックするには、代わりに FLUSH TABLES tbl_name ... WITH READ LOCK を使用します。
FLUSH TABLES tbl_name [, tbl_name] ...

カンマ区切りのテーブル名のリストでは、サーバーが名前付きのテーブルのみをフラッシュする点を除き、この操作は名前のない FLUSH TABLES に似ています。指定したテーブルが存在しない場合、エラーは発生しません。

この操作には、FLUSH_TABLES または RELOAD 権限が必要です。
FLUSH TABLES WITH READ LOCK

開かれているすべてのテーブルを閉じ、グローバルな読み取りロックを保持しているすべてのデータベースのすべてのテーブルをロックします。

この操作には、FLUSH_TABLES または RELOAD 権限が必要です。

この操作は、時間内にスナップショットを取得できる Veritas や ZFS などのファイルシステムがある場合に、バックアップを取得するための非常に便利な方法です。このロックを解放するには、UNLOCK TABLES を使用します。

FLUSH TABLES WITH READ LOCK は、テーブルロックではなくグローバル読取りロックを取得するため、テーブルロックおよび暗黙的コミットに関して LOCK TABLES および UNLOCK TABLES と同じ動作を受けません:
- UNLOCK TABLES は、現在 LOCK TABLES でロックされているテーブルがある場合にのみ、アクティブなトランザクションをすべて暗黙的にコミットします。 FLUSH TABLES WITH READ LOCK はテーブルロックを取得しないため、このステートメントに続く UNLOCK TABLES に対してコミットは発生しません。
- トランザクションを開始すると、ユーザーが UNLOCK TABLES を実行したかのように、LOCK TABLES によって取得されたテーブルロックが解放されます。トランザクションを開始しても、FLUSH TABLES WITH READ LOCK によって取得されたグローバルな読み取りロックは解放されません。
FLUSH TABLES WITH READ LOCK では、サーバーがログテーブルに行を挿入することは妨げられません (セクション5.4.1「一般クエリーログおよびスロークエリーログの出力先の選択」を参照してください)。
FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK

指定されたテーブルの読取りロックをフラッシュおよび取得します。

この操作には、FLUSH_TABLES または RELOAD 権限が必要です。テーブルロックを取得するため、各テーブルに対する LOCK TABLES 権限も必要です。

この操作では、最初にテーブルの排他的メタデータロックが取得されるため、これらのテーブルが開いているトランザクションが完了するまで待機します。次に、操作によってテーブルキャッシュからテーブルがフラッシュされ、テーブルが再オープンされ、テーブルロック (LOCK TABLES ... READ など) が取得され、メタデータロックが排他から共有にダウングレードされます。操作によってロックが取得され、メタデータロックがダウングレードされた後、他のセッションはテーブルの読取りはできますが、変更はできません。

この操作は、既存の実テーブル (TEMPORARY) 以外のテーブル) にのみ適用されます。名前がベーステーブルを参照している場合は、そのテーブルが使用されます。 TEMPORARY テーブルを参照している場合、その名前は無視されます。名前がビューに適用される場合は、ER_WRONG_OBJECT エラーが発生します。それ以外の場合は、ER_NO_SUCH_TABLE エラーが発生します。

ロックを解放するには UNLOCK TABLES を、ロックを解放し、ほかのロックを取得するには LOCK TABLES を、またはロックを解放し、新しいトランザクションを開始するには START TRANSACTION を使用します。

この FLUSH TABLES バリアントを使用すると、単一の操作でテーブルをフラッシュおよびロックできます。これにより、アクティブな LOCK TABLES ... READ がある場合に FLUSH TABLES が許可されないという制限の回避策が提供されます。

この操作では暗黙的な UNLOCK TABLES は実行されないため、アクティブな LOCK TABLES がある間に操作を実行するか、最初に取得したロックを解放せずに再度使用すると、エラーが発生します。

フラッシュされたテーブルが HANDLER で開かれた場合、そのハンドラは暗黙的にフラッシュされ、その位置を失います。
FLUSH TABLES tbl_name [, tbl_name] ... FOR EXPORT

この FLUSH TABLES バリアントは、InnoDB テーブルに適用されます。これにより、指定されたテーブルへの変更がディスクにフラッシュされ、サーバーの実行中にバイナリテーブルのコピーを作成できるようになります。

この操作には、FLUSH_TABLES または RELOAD 権限が必要です。エクスポートの準備としてテーブルのロックを取得するため、テーブルごとに LOCK TABLES および SELECT 権限も必要です。

この操作は次のように機能します:
1. 指定されたテーブルに対する共有メタデータロックを取得します。他のセッションに、それらのテーブルを変更したアクティブなトランザクションがあるか、それらのテーブルのロックを保持しているかぎり、操作はブロックされます。ロックが取得されると、読取り専用操作の続行を許可しながら、テーブルの更新を試行するトランザクションがブロックされます。
2. これらのテーブルのすべてのストレージエンジンが FOR EXPORT をサポートしているかどうかをチェックします。存在しない場合は、ER_ILLEGAL_HA エラーが発生し、操作は失敗します。
3. この操作は、各テーブルのストレージエンジンに、テーブルをエクスポートできるように通知します。そのストレージエンジンは、保留中の変更がすべてディスクに書き込まれるようにする必要があります。
4. この操作によってセッションがロックテーブルモードになり、以前に取得したメタデータロックが FOR EXPORT 操作の完了時に解放されなくなります。
この操作は、既存の (TEMPORARY 以外の) 実テーブルにのみ適用されます。名前がベーステーブルを参照している場合は、そのテーブルが使用されます。 TEMPORARY テーブルを参照している場合、その名前は無視されます。名前がビューに適用される場合は、ER_WRONG_OBJECT エラーが発生します。それ以外の場合は、ER_NO_SUCH_TABLE エラーが発生します。

InnoDB は、独自の .ibd file ファイル (innodb_file_per_table 設定を有効にして作成されたテーブル) を持つテーブルに対して FOR EXPORT をサポートしています。 InnoDB では、FOR EXPORT 操作によって変更がディスクにフラッシュされたことが通知されます。これにより、.ibd ファイルはトランザクションの一貫性があり、サーバーの実行中にコピーできるため、FOR EXPORT 操作が有効な間にテーブルの内容のバイナリコピーを作成できます。 FOR EXPORT は、InnoDB システムテーブルスペースファイル、または FULLTEXT インデックスを持つ InnoDB テーブルには適用されません。

FLUSH TABLES ...FOR EXPORT は、パーティション化された InnoDB テーブルでサポートされています。

FOR EXPORT から通知されると、InnoDB は、通常はメモリー内か、またはテーブルスペースファイルの外部にある個別のディスクバッファーに保持される特定の種類のデータをディスクに書き込みます。 InnoDB はまた、テーブルごとに、そのテーブルと同じデータベースディレクトリ内に table_name.cfg という名前のファイルも生成します。 .cfg ファイルには、あとでテーブルスペースファイルを同じサーバーまたは別のサーバーに再インポートするために必要なメタデータが含まれています。

FOR EXPORT 操作が完了すると、InnoDB はすべての dirty pages をテーブルデータファイルにフラッシュしました。変更バッファーのエントリはすべて、フラッシュの前にマージされます。この時点で、テーブルはロックされ、静止します。これらのテーブルはディスク上でトランザクション的に一貫性のある状態にあるため、.ibd テーブルスペースファイルを対応する .cfg ファイルとともにコピーすることによって、これらのテーブルの整合性のあるスナップショットを取得できます。

コピーされたテーブルデータを MySQL インスタンスに再インポートする手順については、セクション15.6.1.3「InnoDB テーブルのインポート」を参照してください。

テーブルの処理を完了したあと、ロックを解放するには UNLOCK TABLES を、ロックを解放し、ほかのロックを取得するには LOCK TABLES を、またはロックを解放し、新しいトランザクションを開始するには START TRANSACTION を使用します。

セッション内で次のいずれかのステートメントが有効になっている間は、FLUSH TABLES ... FOR EXPORT を使用しようとするとエラーが生成されます。
```
FLUSH TABLES ... WITH READ LOCK
FLUSH TABLES ... FOR EXPORT
LOCK TABLES ... READ
LOCK TABLES ... WRITE
```
セッション内で FLUSH TABLES ... FOR EXPORT が有効になっている間は、次のいずれかのステートメントを使用しようとするとエラーが生成されます。
```
FLUSH TABLES WITH READ LOCK
FLUSH TABLES ... WITH READ LOCK
FLUSH TABLES ... FOR EXPORT
```

PREV HOME UP NEXT