Documentation Home
MySQL 5.6 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 31.4Mb
PDF (A4) - 31.4Mb
PDF (RPM) - 30.5Mb
HTML Download (TGZ) - 7.6Mb
HTML Download (Zip) - 7.7Mb
HTML Download (RPM) - 6.6Mb
Man Pages (TGZ) - 185.4Kb
Man Pages (Zip) - 299.3Kb
Info (Gzip) - 2.9Mb
Info (Zip) - 2.9Mb
Excerpts from this Manual REVOKE Syntax

    priv_type [(column_list)]
      [, priv_type [(column_list)]] ...
    ON [object_type] priv_level
    FROM user [, user] ...

    FROM user [, user] ...

    FROM user [, user] ...

The REVOKE statement enables system administrators to revoke privileges from MySQL accounts.

When the read_only system variable is enabled, REVOKE requires the SUPER privilege in addition to any other required privileges described in the following discussion.

Each account name uses the format described in Section 6.2.3, “Specifying Account Names”. For example:

REVOKE INSERT ON *.* FROM 'jeffrey'@'localhost';

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

For details on the levels at which privileges exist, the permissible priv_type, priv_level, and object_type values, and the syntax for specifying users and passwords, see Section, “GRANT Syntax”

To use the first REVOKE syntax, you must have the GRANT OPTION privilege, and you must have the privileges that you are revoking.

To revoke all privileges, use the second syntax, which drops all global, database, table, column, and routine privileges for the named user or users:


To use this REVOKE syntax, you must have the global CREATE USER privilege, or the UPDATE privilege for the mysql database.

User accounts from which privileges are to be revoked must exist.

REVOKE removes privileges, but does not drop mysql.user table entries. To remove a user account entirely, use DROP USER. See Section, “DROP USER Syntax”.

If the grant tables hold privilege rows that contain mixed-case database or table names and the lower_case_table_names system variable is set to a nonzero value, REVOKE cannot be used to revoke these privileges. It will be necessary to manipulate the grant tables directly. (GRANT will not create such rows when lower_case_table_names is set, but such rows might have been created prior to setting the variable.)

When successfully executed from the mysql program, REVOKE responds with Query OK, 0 rows affected. To determine what privileges remain after the operation, use SHOW GRANTS. See Section, “SHOW GRANTS Syntax”.

User Comments
  Posted by sheila yao on March 4, 2009
Revoke statement has to match the grants issued. If grant is issued to *.*, you can only revoke *.* as well.
This in my opinion, is very inconvenient.

For example, there are only a few tables that users shouldn't have select permission and the database has over 100 tables.

The most efficient way is to grant select on database.* to this user and then revoke select on the few tables from this user.

But this won't work. Mysql will throw out an error:
revoke select on database.suchtable from 'blabal'@'localhost';
ERROR 1147 (42000): There is no such grant defined for user 'blabal' on host 'localhost' on table 'suchtable'.

So you will have to literally grant select on the 97 tables one by one in order to avoid giving the select permission on the 3 tables.

  Posted by May Doušak on June 4, 2009
Sheila, you can use script to grant all on * on selected user and then revoke what you don't want him to see.
PHP e.g.:

mysql_connect ('localhost', 'root', '******');
$r = mysql_query ("SHOW DATABASES");
while ($rr = mysql_fetch_row ($r)) {
mysql_query ("GRANT all ON " .$rr[0] .".* to user@host");

Then just revoke from the three databases you don't want him to see:
revoke all on mysql.* from user@host;

  Posted by Paul Caskey on October 11, 2011

RE: REVOKE on 3 tables out of 100
I solved this problem by creating a separate database to hold the sensitive tables, and joining those back to the master tables on unique IDs for 1-1 row joins. Yes permission changes could be scripted, but now I have a cleaner security design that is far easier to maintain as I add/remove tables from the master. There are usage inconveniences now, but I'm giving this a shot. It's easy to join across databases.


Sign Up Login You must be logged in to post a comment.