DROP USER [IF EXISTS] user [, user] ...
The DROP USER
statement removes
one or more MySQL accounts and their privileges. It removes
privilege rows for the account from all grant tables.
Roles named in the
mandatory_roles
system variable
value cannot be dropped.
To use DROP USER
, you must have
the global CREATE USER
privilege,
or the DELETE
privilege for the
mysql
system schema. When the
read_only
system variable is
enabled, DROP USER
additionally
requires the CONNECTION_ADMIN
privilege (or the deprecated
SUPER
privilege).
DROP USER
fails with an error if
any account to be dropped is named as the
DEFINER
attribute for any stored object.
(That is, the statement fails if dropping an account would cause
a stored object to become orphaned.) To perform the operation
anyway, you must have the
SET_ANY_DEFINER
or
ALLOW_NONEXISTENT_DEFINER
privilege; in this case, the statement succeeds with a warning
rather than failing with an error. For additional information,
including how to identify which objects name a given account as
the DEFINER
attribute, see
Orphan Stored Objects.
DROP USER
either succeeds for all
named users or rolls back and has no effect if any error occurs.
By default, an error occurs if you try to drop a user that does
not exist. If the IF EXISTS
clause is given,
the statement produces a warning for each named user 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 users. If the IF EXISTS
clause is
given, this includes even users that do not exist and were not
dropped.
Each account name uses the format described in Section 8.2.4, “Specifying Account Names”. For example:
DROP USER 'jeffrey'@'localhost';
The host name part of the account name, if omitted, defaults to
'%'
.
DROP USER
does not
automatically close any open user sessions. Rather, in the
event that a user with an open session is dropped, the
statement does not take effect until that user's session is
closed. Once the session is closed, the user is dropped, and
that user's next attempt to log in fails. This
is by design.
DROP USER
does not automatically
drop or invalidate databases or objects within them that the old
user created. This includes stored programs or views for which
the DEFINER
attribute names the dropped user.
Attempts to access such objects may produce an error if they
execute in definer security context. (For information about
security context, see
Section 27.6, “Stored Object Access Control”.)