15.7.1.4 DROP ROLE Statement

DROP ROLE [IF EXISTS] role [, role ] ...

DROP ROLE removes one or more roles (named collections of privileges). To use this statement, you must have the global DROP ROLE or CREATE USER privilege. When the read_only system variable is enabled, DROP ROLE additionally requires the CONNECTION_ADMIN privilege (or the deprecated SUPER privilege).

Users who have the CREATE USER privilege can use this statement to drop accounts that are locked or unlocked. Users who have the DROP ROLE privilege can use this statement only to drop accounts that are locked (unlocked accounts are presumably user accounts used to log in to the server and not just as roles).

Roles named in the mandatory_roles system variable value cannot be dropped.

DROP ROLE either succeeds for all named roles or rolls back and has no effect if any error occurs. By default, an error occurs if you try to drop a role that does not exist. If the IF EXISTS clause is given, the statement produces a warning for each named role that does not exist, rather than an error.

The statement is written to the binary log if it succeeds, but not if it fails; in that case, rollback occurs and no changes are made. A statement written to the binary log includes all named roles. If the IF EXISTS clause is given, this includes even roles that do not exist and were not dropped.

Each role name uses the format described in Section 8.2.5, “Specifying Role Names”. For example:

DROP ROLE 'admin', 'developer';
DROP ROLE 'webapp'@'localhost';

The host name part of the role name, if omitted, defaults to '%'.

A dropped role is automatically revoked from any user account (or role) to which the role was granted. Within any current session for such an account, its adjusted privileges apply beginning with the next statement executed.

For role usage examples, see Section 8.2.10, “Using Roles”.