--skip-grant-tables オプションを指定せずに mysqld サーバーを起動すると、起動シーケンス中にすべての付与テーブルの内容がメモリーに読み込まれます。 インメモリーテーブルは、その時点でアクセス制御に有効になります。
account-management ステートメントを使用して付与テーブルを間接的に変更すると、サーバーはこれらの変更に気付き、付与テーブルをすぐにメモリーに再度ロードします。 アカウント管理ステートメントについては、セクション13.7.1「アカウント管理ステートメント」 を参照してください。 たとえば、GRANT, REVOKE, SET PASSWORD や RENAME USER などです。
INSERT、UPDATE、DELETE (非推奨) などのステートメントを使用して付与テーブルを直接変更した場合、その変更は、テーブルをリロードするか再起動するようにサーバーに指示するまで、権限チェックには影響しません。 したがって、付与テーブルを直接変更してもリロードを忘れた場合、サーバーを再起動するまで変更には影響なしが含まれます。 このため、変更したのに違いが現れないことを不思議に思うことがあるかもしれません。
付与テーブルをリロードするようサーバーに指示するには、フラッシュ権限操作を実行します。 これは、FLUSH PRIVILEGES ステートメントを発行するか、mysqladmin flush-privileges または mysqladmin reload コマンドを実行することによって行うことができます。
付与テーブルのリロードは、次のように既存の各クライアントセッションの権限に影響します:
テーブルおよびカラムの権限の変更は、クライアントの次回のリクエストで有効になります。
-
データベース権限の変更は、クライアントが次回
USEステートメントを実行したときに有効になります。db_name注記クライアントアプリケーションはデータベース名をキャッシュできます。そのため、実際に別のデータベースに変更しないと、この効果が表示されない場合があります。
接続済みクライアントについてのグローバルな権限およびパスワードは影響されません。 これらの変更は、後続の接続のセッションでのみ有効になります。
セッション内のアクティブなロールのセットに対する変更は、そのセッションに対してのみ即時に有効になります。 SET ROLE ステートメントは、セッションロールのアクティブ化および非アクティブ化を実行します (セクション13.7.1.11「SET ROLE ステートメント」 を参照)。
サーバーが --skip-grant-tables オプションを指定して起動された場合、サーバーは付与テーブルを読み取ったりアクセス制御を実装したりしません。 すべてのユーザーがセキュアでないに接続し、任意の操作を実行できます。 そのように起動されたサーバーが、テーブルを読み取ってアクセスチェックを有効にするようにするには、権限をフラッシュします。