ALL, ALL PRIVILEGES

これらの権限指定子は、「「特定の権限レベルで使用可能なすべての権限」」 (GRANT OPTION を除く) の短縮形です。 たとえば、グローバルレベルまたはテーブルレベルで ALL を付与すると、すべてのグローバル権限またはすべてのテーブルレベル権限がそれぞれ付与されます。

ALTER

ALTER TABLE ステートメントを使用してテーブルの構造を変更できます。 ALTER TABLE には CREATE および INSERT 権限も必要です。 テーブルの名前を変更するには、古いテーブルで ALTER および DROP を、新しいテーブルで CREATE および INSERT を実行する必要があります。

ALTER ROUTINE

ストアドルーチン (ストアドプロシージャーおよびストアドファンクション) を変更または削除するステートメントの使用を有効にします。 権限が付与されるスコープ内にあり、ユーザーがルーチン DEFINER として指定されたユーザーではないルーチンの場合、ルーチン定義以外のルーチンプロパティーへのアクセスも有効になります。

CREATE

新しいデータベースおよびテーブルを作成するステートメントの使用を有効にします。

CREATE ROLE

CREATE ROLE ステートメントの使用を有効にします。 (CREATE USER 権限により、CREATE ROLE ステートメントの使用も可能になります。) セクション6.2.10「ロールの使用」を参照してください。

CREATE ROLE および DROP ROLE 権限は、アカウントの作成および削除にのみ使用できるため、CREATE USER ほど強力ではありません。 これらは、CREATE USER でアカウント属性を変更したり、アカウントの名前を変更できるため、使用できません。 ユーザーとロールの互換性を参照してください。

CREATE ROUTINE

ストアドルーチン (ストアドプロシージャーとストアドファンクション) を作成するステートメントの使用を有効にします。 権限が付与されるスコープ内にあり、ユーザーがルーチン DEFINER として指定されたユーザーではないルーチンの場合、ルーチン定義以外のルーチンプロパティーへのアクセスも有効になります。

CREATE TABLESPACE

テーブルスペースおよびログファイルグループを作成、変更または削除するステートメントを使用可能にします。

CREATE TEMPORARY TABLES

CREATE TEMPORARY TABLE ステートメントを使用した一時テーブルの作成を有効にします。

セッションが一時テーブルを作成したあと、サーバーはそのテーブルに対するそれ以上の権限チェックを実行しません。 セッションの作成によって、DROP TABLE、INSERT、UPDATE、SELECT などのあらゆる操作をテーブル上で実行できます。 詳細は、セクション13.1.20.2「CREATE TEMPORARY TABLE ステートメント」を参照してください。

CREATE USER

ALTER USER, CREATE ROLE, CREATE USER, DROP ROLE, DROP USER, RENAME USER および REVOKE ALL PRIVILEGES ステートメントの使用を有効にします。

CREATE VIEW

CREATE VIEW ステートメントの使用を有効にします。

DELETE

データベース内のテーブルから行を削除できます。

DROP

既存のデータベース、テーブルおよびビューを削除するステートメントを使用可能にします。 パーティションテーブルで ALTER TABLE ... DROP PARTITION ステートメントを使用するには、DROP 権限が必要です。 DROP 権限は TRUNCATE TABLE のためにも必要です。

DROP ROLE

DROP ROLE ステートメントの使用を有効にします。 (CREATE USER 権限により、DROP ROLE ステートメントの使用も可能になります。) セクション6.2.10「ロールの使用」を参照してください。

CREATE ROLE および DROP ROLE 権限は、アカウントの作成および削除にのみ使用できるため、CREATE USER ほど強力ではありません。 これらは、CREATE USER でアカウント属性を変更したり、アカウントの名前を変更できるため、使用できません。 ユーザーとロールの互換性を参照してください。

EVENT

イベントスケジューラのイベントを作成、変更、削除、または表示するステートメントの使用を有効にします。

EXECUTE

ストアドルーチン (ストアドプロシージャーとストアドファンクション) を実行するステートメントの使用を有効にします。 権限が付与されるスコープ内にあり、ユーザーがルーチン DEFINER として指定されたユーザーではないルーチンの場合、ルーチン定義以外のルーチンプロパティーへのアクセスも有効になります。

FILE

次の操作およびサーバーの動作に影響します:

セキュリティ対策として、サーバーは既存のファイルを上書きしません。

ファイルの読取りおよび書込みが可能な場所を制限するには、secure_file_priv システム変数を特定のディレクトリに設定します。 セクション5.1.8「サーバーシステム変数」を参照してください。

GRANT OPTION

自分が所有する権限を他のユーザーに付与したり、他のユーザーから取り消すことができます。

INDEX

インデックスを作成または削除するステートメントの使用を有効にします。 INDEX は既存のテーブルに適用されます。 テーブルに対する CREATE 権限を持つ場合、CREATE TABLE ステートメントにインデックス定義を含めることも可能です。

INSERT

データベースのテーブルに行を挿入できます。 ANALYZE TABLE、OPTIMIZE TABLE、REPAIR TABLE などのテーブル保守に関するステートメントにも、INSERT 権限が必要です。

LOCK TABLES

明示的な LOCK TABLES ステートメントを使用して、SELECT 権限を持つテーブルをロックできます。 これには、他のセッションによるロックされたテーブルの読取りを防止する書込みロックの使用が含まれます。

PROCESS

PROCESS 権限は、サーバー内で実行されているスレッドに関する情報 (セッションによって実行されているステートメントに関する情報) へのアクセスを制御します。 SHOW PROCESSLIST ステートメント、mysqladmin processlist コマンド、INFORMATION_SCHEMA.PROCESSLIST テーブル、およびパフォーマンススキーマ processlist テーブルを使用して使用可能なスレッド情報には、次のようにアクセスできます:

PROCESS 権限では、SHOW ENGINE ステートメントの使用、INFORMATION_SCHEMA InnoDB テーブル (INNODB_で始まる名前を持つテーブル) へのアクセスおよび、(MySQL 8.0.21 の時点で) INFORMATION_SCHEMA FILES テーブルへのアクセスも可能です。

PROXY

あるユーザーが別のユーザーになりすましたり、別のユーザーとして知られるようにします。 セクション6.2.18「プロキシユーザー」を参照してください。

REFERENCES

外部キー制約を作成するには、親テーブルに対する REFERENCES 権限が必要です。

RELOAD

RELOAD では、次の操作が可能です:

REPLICATION CLIENT

SHOW MASTER STATUS、SHOW REPLICA | SLAVE STATUS および SHOW BINARY LOGS ステートメントの使用を有効にします。 レプリカがレプリケーションソースサーバーとして現在のサーバーに接続するために使用するアカウントにこの権限を付与します。

REPLICATION SLAVE

SHOW REPLICAS | SHOW SLAVE HOSTS、SHOW RELAYLOG EVENTS および SHOW BINLOG EVENTS ステートメントを使用して、レプリケーションソースサーバー上のデータベースに対して行われた更新をアカウントがリクエストできるようにします。 この権限は、mysqlbinlog オプションの --read-from-remote-server (-R) および --read-from-remote-master を使用する場合にも必要です。 レプリカがレプリケーションソースサーバーとして現在のサーバーに接続するために使用するアカウントにこの権限を付与します。

SELECT

データベース内のテーブルから行を選択できます。 SELECT ステートメントには、実際にテーブルにアクセスする場合にのみ SELECT 権限が必要です。 一部の SELECT ステートメントはテーブルにアクセスしないため、あらゆるデータベースへのアクセス権がなくても実行できます。 たとえば、テーブルを参照しない式を評価するための単純な計算機として SELECT を使用することができます。

SELECT 1+1;
SELECT PI()*2;

SELECT 権限は、カラム値を読み取るほかのステートメントについても必要です。 たとえば、UPDATE ステートメントの代入 col_name=expr の右辺で参照されるカラムや、DELETE または UPDATE ステートメントの WHERE 句で指定されるカラムについて、SELECT が必要です。

EXPLAIN で使用されるテーブルまたはビュー (ビュー定義の基礎となるテーブルを含む) には、SELECT 権限が必要です。

SHOW DATABASES

SHOW DATABASE ステートメントを発行して、アカウントがデータベース名を表示できるようにします。 この権限を持たないアカウントには、アカウントが一部の権限を持つデータベースしか表示されず、サーバーが --skip-show-database オプションで起動されている場合はステートメントを一切使用できません。

SHOW VIEW

SHOW CREATE VIEW ステートメントの使用を有効にします。 この権限は、EXPLAIN で使用されるビューにも必要です。

SHUTDOWN

SHUTDOWN および RESTART ステートメント、mysqladmin shutdown コマンドおよび mysql_shutdown() C API 関数の使用を有効にします。

SUPER

SUPER は強力で遠いリカバリ権限であるため、軽く付与しないでください。 アカウントで SUPER 操作のサブセットのみを実行する必要がある場合は、かわりに 1 つ以上の動的権限を付与することで、必要な権限セットを実現できる場合があり、それぞれがより制限された機能を構成します。 動的権限の説明を参照してください。

SUPER は、次の操作およびサーバーの動作に影響します:

セクション25.7「ストアドプログラムバイナリロギング」 で説明されているように、バイナリロギングが有効になっている場合は、ストアドファンクションを作成または変更するために SUPER 権限が必要になることもあります。

TRIGGER

トリガー操作を有効にします。 テーブルのトリガーを作成、削除、実行または表示するには、そのテーブルに対するこの権限が必要です。

トリガーが (トリガーに関連付けられたテーブルに対して INSERT、UPDATE または DELETE ステートメントを実行する権限を持つユーザーによって) アクティブ化された場合、トリガーの実行には、トリガーを定義したユーザーがそのテーブルに対する TRIGGER 権限を持っている必要があります。

UPDATE

データベース内のテーブルで行を更新できます。

USAGE

この権限指定子は、「「権限なし」」を表します。 GRANT でグローバルレベルで使用され、権限リスト内の特定のアカウント権限に名前を付けずに WITH GRANT OPTION などの句を指定します。 SHOW GRANTS には、アカウントに権限レベルの権限がないことを示す USAGE が表示されます。

APPLICATION_PASSWORD_ADMIN (MySQL 8.0.14 で追加)

デュアルパスワード機能の場合、この権限により、自分のアカウントに適用される ALTER USER ステートメントおよび SET PASSWORD ステートメントに RETAIN CURRENT PASSWORD 句および DISCARD OLD PASSWORD 句を使用できます。 ほとんどのユーザーは 1 つのパスワードのみを必要とするため、自分のセカンダリパスワードを操作するにはこの権限が必要です。

アカウントがすべてのアカウントのセカンダリパスワードの操作を許可される場合は、APPLICATION_PASSWORD_ADMIN ではなく CREATE USER 権限を付与する必要があります。

デュアルパスワードの使用の詳細は、セクション6.2.15「パスワード管理」 を参照してください。

AUDIT_ADMIN

監査ログ構成を有効にします。 この権限は、audit_log プラグインによって定義されます。セクション6.4.5「MySQL Enterprise Audit」 を参照してください。

BACKUP_ADMIN

LOCK INSTANCE FOR BACKUP ステートメントの実行およびパフォーマンススキーマ log_status テーブルへのアクセスを有効にします。

以前のバージョンから MySQL 8.0 へのインプレースアップグレードを実行すると、RELOAD 権限を持つユーザーに BACKUP_ADMIN 権限が自動的に付与されます。

BINLOG_ADMIN

PURGE BINARY LOGS および BINLOG ステートメントを使用してバイナリログ制御を有効にします。

BINLOG_ENCRYPTION_ADMIN

バイナリログファイルおよびリレーログファイルの暗号化をアクティブまたは非アクティブにするシステム変数 binlog_encryption の設定を有効にします。 この機能は、BINLOG_ADMIN、SYSTEM_VARIABLES_ADMIN または SESSION_VARIABLES_ADMIN 権限では提供されません。 サーバーの再起動時にバイナリログマスターキーを自動的にローテーションする関連システム変数 binlog_rotate_encryption_master_key_at_startup には、この権限は必要ありません。

CLONE_ADMIN

CLONE ステートメントの実行を有効にします。 BACKUP_ADMIN および SHUTDOWN 権限が含まれます。

CONNECTION_ADMIN

KILL ステートメントまたは mysqladmin kill コマンドを使用して、他のアカウントに属するスレッドを強制終了できます。 (アカウントは常に独自のスレッドを強制終了できます。)

クライアント接続に関連するシステム変数の設定、またはクライアント接続に関連する制限の回避を有効にします。 CONNECTION_ADMIN は、次のシステム変数の影響に適用されます:

ENCRYPTION_KEY_ADMIN

InnoDB 暗号化キーのローテーションを有効にします。

FIREWALL_ADMIN

ユーザーは、任意のユーザーのファイアウォールルールを管理できます。 この権限は、MYSQL_FIREWALL プラグインによって定義されます。セクション6.4.7「MySQL Enterprise Firewall」 を参照してください。

FIREWALL_USER

ユーザーが独自のファイアウォールルールを更新できるようにします。 この権限は、MYSQL_FIREWALL プラグインによって定義されます。セクション6.4.7「MySQL Enterprise Firewall」 を参照してください。

FLUSH_OPTIMIZER_COSTS (MySQL 8.0.23 で追加)

FLUSH OPTIMIZER_COSTS ステートメントの使用を有効にします。

FLUSH_STATUS (MySQL 8.0.23 で追加)

FLUSH STATUS ステートメントの使用を有効にします。

FLUSH_TABLES (MySQL 8.0.23 で追加)

FLUSH TABLES ステートメントの使用を有効にします。

FLUSH_USER_RESOURCES (MySQL 8.0.23 で追加)

FLUSH USER_RESOURCES ステートメントの使用を有効にします。

GROUP_REPLICATION_ADMIN

START GROUP REPLICATION および STOP GROUP REPLICATION ステートメントを使用してグループレプリケーションを開始および停止し、group_replication_consistency システム変数のグローバル設定を変更し、group_replication_set_write_concurrency() および group_replication_set_communication_protocol() UDF を使用できるようにします。 レプリケーショングループのメンバーであるサーバーの管理に使用されるアカウントにこの権限を付与します。

INNODB_REDO_LOG_ARCHIVE

アカウントが redo ログアーカイブをアクティブ化および非アクティブ化できるようにします。

INNODB_REDO_LOG_ENABLE

ALTER INSTANCE {ENABLE|DISABLE} INNODB REDO_LOG ステートメントを使用して redo ロギングを有効または無効にします。 MySQL 8.0.21 で導入されました。

redo ロギングの無効化を参照してください。

NDB_STORED_USER

特定の NDB Cluster に参加するとすぐに、ユーザーまたは役割とその権限をすべての NDB 対応 MySQL サーバー間で共有および同期できるようにします。 この権限は、NDB ストレージエンジンが有効になっている場合にのみ使用できます。

指定されたユーザーまたはロールに対して行われた権限の変更または取消しは、接続されているすべての MySQL サーバー (SQL ノード) とただちに同期化されます。 異なる SQL ノードから発生した権限に影響する複数のステートメントが、すべての SQL ノードで同じ順序で実行されることは保証されないことに注意してください。 このため、すべてのユーザー管理は単一の指定された SQL ノードから実行することを強くお薦めします。

NDB_STORED_USER はグローバル権限であり、ON *.* を使用して付与または取り消す必要があります。 この権限に他のスコープを設定しようとすると、エラーになります。 この権限は、ほとんどのアプリケーションユーザーおよび管理ユーザーに付与できますが、mysql.session@localhost や mysql.infoschema@localhost などのシステム予約アカウントには付与できません。

NDB_STORED_USER 権限を付与されたユーザーは、この権限を持つロールと同様に、NDB に格納されます (したがって、すべての SQL ノードで共有されます)。 NDB_STORED_USER を持つロールのみを付与されたユーザーは、NDB には格納されません。各 NDB 格納ユーザーには、権限を明示的に付与する必要があります。

NDB でのこの動作の詳細は、セクション23.5.12「NDB_STORED_USER での分散 MySQL 権限」 を参照してください。

NDB_STORED_USER 権限は NDB 8.0.18 以降で使用できます。

PERSIST_RO_VARIABLES_ADMIN

SYSTEM_VARIABLES_ADMIN も持っているユーザーの場合、PERSIST_RO_VARIABLES_ADMIN を使用すると、SET PERSIST_ONLY を使用してグローバルシステム変数をデータディレクトリの mysqld-auto.cnf オプションファイルに永続化できます。 このステートメントは SET PERSIST と似ていますが、ランタイムグローバルシステム変数の値は変更されません。 これにより、SET PERSIST_ONLY は、サーバーの起動時にのみ設定できる読取り専用システム変数の構成に適しています。

セクション5.1.9.1「システム変数権限」も参照してください。

REPLICATION_APPLIER

アカウントをレプリケーションチャネルの PRIVILEGE_CHECKS_USER として機能させ、mysqlbinlog 出力で BINLOG ステートメントを実行できるようにします。 CHANGE REPLICATION SOURCE TO (MySQL 8.0.23 から) または CHANGE MASTER TO (MySQL 8.0.23 より前) を使用して割り当てられたアカウントにこの権限を付与して、レプリケーションチャネルのセキュリティコンテキストを提供し、それらのチャネルでレプリケーションエラーを処理します。 REPLICATION_APPLIER 権限と同様に、レプリケーションチャネルで受信したトランザクションまたは mysqlbinlog 出力に含まれるトランザクションを実行するために必要な権限をアカウントに付与して、影響を受けるテーブルを更新する必要があります。 詳細は、セクション17.3.3「レプリケーション権限チェック」を参照してください。

REPLICATION_SLAVE_ADMIN

アカウントがレプリケーションソースサーバーに接続し、START REPLICA | SLAVE および STOP REPLICA | SLAVE ステートメントを使用してレプリケーションを開始および停止し、CHANGE REPLICATION SOURCE TO ステートメント (MySQL 8.0.23 から) または CHANGE MASTER TO ステートメント (MySQL 8.0.23 より前) および CHANGE REPLICATION FILTER ステートメントを使用します。 レプリカがレプリケーションソースサーバーとして現在のサーバーに接続するために使用するアカウントにこの権限を付与します。 この権限はグループレプリケーションには適用されません。そのためには GROUP_REPLICATION_ADMIN を使用します。

RESOURCE_GROUP_ADMIN

リソースグループの作成、変更および削除、およびリソースグループへのスレッドとステートメントの割当てで構成されるリソースグループ管理を有効にします。 この権限を持つユーザーは、リソースグループに関連する操作を実行できます。

RESOURCE_GROUP_USER

リソースグループへのスレッドとステートメントの割り当てを有効にします。 この権限を持つユーザーは、SET RESOURCE GROUP ステートメントおよび RESOURCE_GROUP オプティマイザヒントを使用できます。

ROLE_ADMIN

ロールの付与と取消し、GRANT ステートメントの WITH ADMIN OPTION 句の使用、および ROLES_GRAPHML() 関数からの結果の空でない <graphml> 要素コンテンツを有効にします。 mandatory_roles システム変数の値を設定するために必要です。

SERVICE_CONNECTION_ADMIN

管理接続のみを許可するネットワークインタフェースへの接続を有効にします (セクション5.1.12.1「接続インタフェース」 を参照)。

SESSION_VARIABLES_ADMIN (MySQL 8.0.14 で追加)

ほとんどのシステム変数では、セッション値の設定に特別な権限は必要なく、すべてのユーザーが現在のセッションに影響を与えることができます。 一部のシステム変数では、セッション値を設定すると、現在のセッションの外部に影響を与える可能性があるため、操作が制限されます。 これらの場合、SESSION_VARIABLES_ADMIN 権限により、ユーザーはセッション値を設定できます。

システム変数が制限されていて、セッション値を設定するために特別な権限が必要な場合、変数の説明にその制限が示されます。 例として、binlog_format、sql_log_bin および sql_log_off があります。

SESSION_VARIABLES_ADMIN が追加された MySQL 8.0.14 より前は、SYSTEM_VARIABLES_ADMIN または SUPER 権限を持つユーザーのみが制限付きセッションシステム変数を設定できます。

SESSION_VARIABLES_ADMIN 権限は、SYSTEM_VARIABLES_ADMIN および SUPER 権限のサブセットです。 これらの権限のいずれかを持つユーザーは、制限付きセッション変数の設定も許可され、効果的には SESSION_VARIABLES_ADMIN を意味するため、SESSION_VARIABLES_ADMIN を明示的に付与する必要はありません。

セクション5.1.9.1「システム変数権限」も参照してください。

SET_USER_ID

ビューまたはストアドプログラムの実行時に有効な承認 ID を設定できるようにします。 この権限を持つユーザーは、ビューまたはストアドプログラムの DEFINER 属性として任意のアカウントを指定できます。

MySQL 8.0.22 では、SET_USER_ID を使用して、(おそらく誤って) ストアドオブジェクトが孤立したり、現在孤立しているストアドオブジェクトを採用する原因となる操作を防ぐために設計されたセキュリティチェックをオーバーライドすることもできます。 詳細は、孤立したストアドオブジェクトを参照してください。

SHOW_ROUTINE (MySQL 8.0.20 で追加)

ユーザーがルーチン DEFINER として指定されていないストアドルーチン (ストアドプロシージャーおよびストアドファンクション) の定義およびプロパティーにアクセスできるようにします。 このアクセスには、次のものが含まれます:

MySQL 8.0.20 より前では、ユーザーが定義しなかったルーチンの定義にアクセスするには、グローバルな SELECT 権限が必要です。これは非常に広範です。 8.0.20 の時点では、代わりに、ルーチン定義へのアクセスを許可するより制限されたスコープを持つ特権として SHOW_ROUTINE を付与できます。 (つまり、管理者は、それを必要としないユーザーからグローバル SELECT を廃棄し、かわりに SHOW_ROUTINE を付与できます。) これにより、アカウントは広範囲の権限を必要とせずにストアドルーチンをバックアップできます。

SYSTEM_USER (MySQL 8.0.16 で追加)

SYSTEM_USER 権限は、システムユーザーを通常のユーザーと区別します:

SYSTEM_USER 権限は、特定のユーザーが他の権限を適用できるアカウント、およびそのユーザーが他のアカウントから保護されているかどうかに影響します:

詳細は、セクション6.2.11「アカウントカテゴリ」を参照してください。

SYSTEM_USER 権限によってシステムアカウントに付与される通常のアカウントによる変更からの保護は、mysql システムスキーマに対する権限を持つ通常のアカウントには適用されないため、そのスキーマの付与テーブルを直接変更できます。 完全保護のために、mysql スキーマ権限を通常のアカウントに付与しないでください。 通常アカウントによる操作からのシステムアカウントの保護を参照してください。

SYSTEM_VARIABLES_ADMIN

次の操作およびサーバーの動作に影響します:

TABLE_ENCRYPTION_ADMIN (MySQL 8.0.16 で追加)

table_encryption_privilege_check が有効な場合に、ユーザーがデフォルトの暗号化設定をオーバーライドできるようにします。スキーマおよび一般テーブルスペースの暗号化デフォルトの定義 を参照してください。

VERSION_TOKEN_ADMIN

バージョントークンのユーザー定義関数の実行を有効にします。 この権限は、version_tokens プラグインによって定義されます。セクション5.6.6「バージョントークン」 を参照してください。

XA_RECOVER_ADMIN

XA RECOVER ステートメントの実行を有効にします。セクション13.3.8.1「XA トランザクション SQL ステートメント」 を参照してください。

MySQL 8.0 より前は、すべてのユーザーが XA RECOVER ステートメントを実行して、未処理の準備済 XA トランザクションの XID 値を検出できたため、XA トランザクションを開始したユーザー以外のユーザーによる XA トランザクションのコミットまたはロールバックが発生する可能性がありました。 MySQL 8.0 では、XA RECOVER は XA_RECOVER_ADMIN 権限を持つユーザーにのみ許可されます。これは、それを必要とする管理ユーザーにのみ付与されることが予想されます。 たとえば、XA アプリケーションがクラッシュし、ロールバックできるようにアプリケーションによって開始された未処理のトランザクションを検索する必要がある場合などです。 この権限要件により、ユーザーは自分以外の未処理の準備済 XA トランザクションの XID 値を検出できなくなります。 XA トランザクションを開始したユーザーが XID を認識しているため、XA トランザクションの通常のコミットまたはロールバックには影響しません。

FILE を使用すると、MySQL サーバーがサーバーホスト上で読み取ることができるファイルをデータベーステーブルに読み込むことができます。 これにはすべてのユーザーが読み取り可能なすべてのファイルと、サーバーのデータディレクトリ内のファイルが含まれます。 そのあと、SELECT を使用してそのテーブルにアクセスし、テーブルの内容をクライアントホストに送信することができます。

GRANT OPTION を使用すると、ユーザーは他のユーザーに権限を付与できます。 異なる権限を持つ 2 人のユーザーが GRANT OPTION 権限を持っていれば、権限を組み合わせることができます。

ALTER を使用すると、テーブルの名前を変更して権限システムを再変換できます。

SHUTDOWN では、サーバーを終了することで、他のユーザーに対するサービスを完全に拒否できます。

PROCESS を使用すると、パスワードを設定または変更するステートメントを含む、現在実行中のステートメントのプレーンテキストを表示できます。

SUPER を使用すると、他のセッションを終了したり、サーバーの動作方法を変更できます。

mysql システムデータベース自体に付与された権限を使用して、パスワードおよびその他のアクセス権限情報を変更できます:

静的権限はサーバーに組み込まれています。 これらは常にユーザーアカウントに付与でき、登録解除できません。

動的権限は、実行時に登録および登録解除できます。 これは可用性に影響: 登録されていない動的権限は付与できません。

サーバーは、(--skip-grant-tables オプションが指定されていないかぎり) サーバーの起動時に global_grants で指定された権限を自動的に登録します。

GRANT および REVOKE ステートメントによって、global_grants の内容が変更されます。

global_grants にリストされている動的権限割当ては永続的です。 サーバーの停止時には削除されません。

グローバルレベルの GRANT ALL では、すべての静的グローバル権限および現在登録されているすべての動的権限が付与されます。 GRANT ステートメントの実行後に登録された動的権限は、どのアカウントにも遡及的に付与されません。

グローバルレベルの REVOKE ALL は、付与されているすべての静的グローバル権限および付与されているすべての動的権限を取り消します。