According to MySQL 5.7 Documentation under
Privileges Provided by MySQL
The privileges granted to a MySQL account determine which operations
the account can perform. MySQL privileges differ in the contexts in
which they apply and at different levels of operation:
Administrative privileges enable users to manage operation of the
MySQL server. These privileges are global because they are not
specific to a particular database.
Database privileges apply to a database and to all objects within it.
These privileges can be granted for specific databases, or globally so
that they apply to all databases.
Privileges for database objects such as tables, indexes, views, and
stored routines can be granted for specific objects within a database,
for all objects of a given type within a database (for example, all
tables in a database), or globally for all objects of a given type in
From this, the order is:
- Global Privileges
- Database Privileges
- Table Privileges
The tables that drive the order are:
With regard to an identical username @ host, please note what pages 486,487 state about mysql's authentication algorithm from MySQL 5.0 Certification Study Guide
There are two stages of client access control:
In the first stage, a client attempts to connect and the server either
accepts or rejects the connection. For the attempt to succeed, some
entry in the user table must match the host from which the client
connects, the username, and the password.
In the second stage (which occurs only if a client has already
connected sucessfully), the server checks every query it receives from
the client to see whether the client has sufficient privileges to
The server matches a client against entries in the grant tables based
on the host from which the client connects and the user the client
provides. However, it's possible for more than one record to match:
Host values in grant tables may be specified as patterns contains
wildcard values. If a grant table contains entries from
%, all of them
match a client who connects from
Patterns are not allowed for the User values in grant table entries,
but a username may be given as an empty string to specify an anonymous
user. The empty string matches any username and thus effectively acts
as a wildcard.
When the Host and the User values in more than one user table record
match a client, the server must decide which one to use. It does this
by sorting records with the most specific Host and User column values
first, and choosing the matching record that occurs first in the
sorted list, Sorting take place as follows:
In the Host Column, literal values such as
myhost.example.com sort ahead of values such as
that have pattern characters in them. Pattern values are sorted
according to how specific they are. For example,
more specific than
%.com, which is more specific than
In the User column, non-blank usernames sort ahead of blank usernames.
That is, non-anonymous users sort ahead of anonymous users.
The server performs this sorting when it starts. It reads the grant
tables into memory, sorts them, and uses the in-memory copies for
When you look at these two perspectives, mysqld should always go top down when evaluating grants. Keep in mind that
GRANT SELECT ON Demo.table1 TO abc@123; is stored in
GRANT ALL PRIVILEGES ON Demo.* TO abc@123; is stored in
- For more information, please see my older post Unable to remove permission for mysql.user
AND THE OSCAR GOES TO ...
GRANT ALL PRIVILEGES ON Demo.* TO abc@123;