In what order MySQL permissions are applied on database? I want to understand the priority of executing MySQL grants privileges.

For e.g.: 

I want to grant two different types of privileges on a single db Demo.

1.GRANT SELECT ON Demo.table1 TO abc@123;

2.GRANT ALL PRIVILEGES ON Demo.* TO abc@123;

As per my assumption, no 2 grant will overwrite the limitations of no 1 grant, therefore, ends up giving access to all tables including table1 to abc user. 

And if I want to give SELECT privilege for table1 then I should change the order of executing permissions so that they don't get overwritten by *.

I'm not sure if this is how MySQL manages such permissions. 
Anyone with a different opinion?

Thanks in advance.
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
  all databases.
  


From this, the order is:


Global Privileges
Database Privileges
Table Privileges


The tables that drive the order are:


mysql.user
mysql.db
mysql.tables_priv
mysql.columns_priv


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
  execute it.
  
  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
  myhost.example.com, %.example.com, %.com, and %, all of them
  match a client who connects from myhost.example.com.
  
  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 localhost, 127.0.0.1,
  and myhost.example.com sort ahead of values such as %.example.com
  that have pattern characters in them. Pattern values are sorted
  according to how specific they are. For example, %.example.com is
  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
  access control.


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 mysql.tables_priv
GRANT ALL PRIVILEGES ON Demo.* TO abc@123; is stored in mysql.db
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;