Access Control, Stage 2: Request Verification It is a common misconception to think that, for a given user name, all rows that explicitly name that user are used first when the server attempts to find a match for the connection. This is not true. The preceding example illustrates this, where a connection from  h1.example.net  by  jeffrey  is first matched not by the row containing  ’jeffrey’  as the  User  column value, but by the row with no user name. As a result,  jeffrey  is authenticated as an anonymous user, even though he specified a user name when connecting. If you are able to connect to the server, but your privileges are not what you expect, you probably are being authenticated as some other account. To find out what account the server used to authenticate you, use the  CURRENT_USER()  function. (See Section 12.16, “Information Functions” .) It returns a value in user_name @ host_name  format that indicates the  User  and  Host  values from the matching  user  table row. Suppose that  jeffrey  connects and issues the following query: The result shown here indicates that the matching  user  table row had a blank  User  column value. In other words, the server is treating  jeffrey  as an anonymous user. Another way to diagnose authentication problems is to print out the  user  table and sort it by hand to see where the first match is being made. After the server accepts a connection, it enters Stage 2 of access control. For each request that you issue through the connection, the server determines what operation you want to perform, then checks whether your privileges are sufficient. This is where the privilege columns in the grant tables come into play. These privileges can come from any of the  user ,  global_grants ,  db ,  tables_priv ,  columns_priv , or procs_priv  tables. (You may find it helpful to refer to Section 6.2.3, “Grant Tables” , which lists the columns present in each grant table.) The  user  and  global_grants  tables grant global privileges. The rows in these tables for a given account indicate the account privileges that apply on a global basis no matter what the default database is. For example, if the  user  table grants you the  DELETE  privilege, you can delete rows from any table in any database on the server host. It is wise to grant privileges in the  user  table only to people who need them, such as database administrators. For other users, leave all privileges in the  user  table set to  ’N’ and grant privileges at more specific levels only (for particular databases, tables, columns, or routines). It is also possible to grant database privileges globally but use partial revokes to restrict them from being exercised on specific databases (see Section 6.2.12, “Privilege Restriction Using Partial Revokes” ). The  db  table grants database-specific privileges. Values in the scope columns of this table can take the following forms: 1220 •The wildcard characters  %  and  _  can be used in the  Host  and  Db  columns. These have the same meaning as for pattern-matching operations performed with the  LIKE  operator. If you want to use either character literally when granting privileges, you must escape it with a backslash. For example, to include the underscore character ( _ ) as part of a database name, specify it as  \_  in the  GRANT  statement. •A blank  User  value matches the anonymous user. A nonblank value matches literally; there are no wildcards in user names. Note 6.2.7 Access Control, Stage 2: Request Verification mysql>  SELECT CURRENT_USER(); +----------------+ | CURRENT_USER() | +----------------+ | @localhost | +----------------+