当你试图连接MySQL服务器时，服务器基于你的身份以及你是否能通过供应正确的密码验证身份来接受或拒绝连接。如果不是，服务器完全拒绝你的访问，否则，服务器接受连接，然后进入阶段2并且等待请求。
你的身份基于2个信息：
- 你从那个主机连接
- 你的MySQL用户名
身份检查使用3个user表(Host, User和Password)范围列执行。服务器只有在user表记录的Host和User列匹配客户端主机名和用户名并且提供了正确的密码时才接受连接。
在user表Host值的指定方法：
- Host值可以是主机名或IP号，或'localhost'指出本地主机。
- 你可以在Host列值使用通配符字符“%”和“_”。
- Host值'%'匹配任何主机名，空Host值等价于'%'。它们的含义与LIKE操作符的模式匹配操作相同。例如，'%'的Host值与所有主机名匹配，而'%.mysql.com'匹配mysql.com域的所有主机。
· 对于指定为IP号的Host值，你可以指定一个网络掩码，说明使用多少位地址位来评比网络号。例如：
· mysql> GRANT ALL PRIVILEGES ON db.*
· -> -> TO david@'192.58.197.0/255.255.255.0';
允许david从任何客户端用IP号client_ip来连接，下面的条件为真：
client_ip & netmask = host_ip
That is, for the GRANT statement just shown:
client_ip & 255.255.255.0 = 192.58.197.0
满足该条件并可以连接MySQL服务器的IP号的范围为192.58.197.0到192.58.197.255。
· 注释：网络掩码只用来告诉服务器使用8、16、24或32位地址，例如：
· 192.0.0.0/255.0.0.0(192 A类网络的任何地址)
· 192.168.0.0/255.255.0.0(192.168 A类网络的任何地址)
· 192.168.1.0/255.255.255.0(192.168.1 C类网络的任何地址)
· 192.168.1.1(只有该IP)
下面的网络掩码(28 位)无效：
192.168.0.1/255.255.255.240
· db表记录中的空Host值表示它的权限应结合匹配客户端名的host表中的行使用。通过AND(相与)而不是或(联合)操作将权限组合到一起。你可以从5.7.6节，“访问控制, 阶段2：请求核实”找到关于host表的详细信息。
其它grant表的空Host值与'%'相同。
既然你能在Host字段使用IP通配符值(例如，'144.155.166.%'匹配在一个子网上的每台主机)，有可能某人可能企图探究这种能力，通过命名一台主机为144.155.166.somewhere.com。为了阻止这样的企图，MySQL不允许匹配以数字和一个点起始的主机名，这样，如果你用一个命名为类似1.2.foo.com的主机，它的名字决不会匹配授权表中的Host列。只有一个IP数字能匹配IP通配符值。
通配符字符在User列中不允许，但是你能指定空的值，它匹配任何名字。如果user表匹配的连接有一个空用户名，用户被认为是匿名用户(没有名字的用户)，而非客户端实际指定的名字。这意味着一个空的用户名被用于在连接期间的进一步的访问检查(即，在阶段2期间)。
Password列可以是空的。这不是通配符，也不意味着匹配任何密码，它意味着用户必须不指定一个密码进行连接。
user表中的非空Password值代表加密的密码。MySQL不以任何人可以看的明文文本格式存储密码，相反，正在试图联接的用户提供的密码被加密(使用PASSWORD( )函数)，在连接过程中使用加密的密码检查密码是否正确。(加密后的密码未通过连接即可实现）。从MySQL角度，加密的密码是实际密码，因此你不应让其它人访问它！特别是，绝对不要让非管理用户读mysql数据库中的表！
MySQL 5.1使用强鉴定方法(最先在MySQL 4.1中适用)在前面的版本中在连接进程中的密码保护较好。即使TCP/IP包被截取或mysql数据库 被捕获也很安全。5.7.9节，“MySQL 4.1中的密码哈希处理”中详细讨论了密码加密。
下面的例子显示出各种user表中Host和User值的组合如何应用于到来的连接：
| Host值 |
User值 |
被条目匹配的连接 |
| 'thomas.loc.gov' |
'fred' |
fred, 从thomas.loc.gov 连接 |
| 'thomas.loc.gov' |
'' |
任何用户, 从thomas.loc.gov连接 |
| '%' |
'fred' |
fred, 从任何主机连接 |
| '%' |
'' |
任何用户, 从任何主机连接 |
| '%.loc.gov' |
'fred' |
fred, 从在loc.gov域的任何主机连接 |
| 'x.y.%' |
'fred' |
fred, 从x.y.net、x.y.com,x.y.edu等联接。（这或许无用） |
| '144.155.166.177' |
'fred' |
fred, 从有144.155.166.177 IP地址的主机连接 |
| '144.155.166.%' |
'fred' |
fred, 从144.155.166 C类子网的任何主机连接 |
到来的连接中的客户端名和用户名可能与user表中的多行匹配。例如，由fred从thomas.loc.gov的连接匹配多个条目如上所述。
如果有多个匹配，服务器必须选择使用哪个条目。按照下述方法解决问题：
l 服务器在启动时读入user表后进行排序。
l 然后当用户试图连接时，以排序的顺序浏览条目
l 服务器使用与客户端和用户名匹配的第一行。
user表排序工作如下，假定user表看起来像这样：
+-----------+----------+-
| Host | User | …
+-----------+----------+-
| % | root | …
| % | jeffrey | …
| localhost | root | …
| localhost | | …
+-----------+----------+-
当服务器读取表时，它首先以最具体的Host值排序。主机名和IP号是最具体的。'%'意味着“任何主机”并且是最不特定的。有相同Host值的条目首先以最具体的User值排序(空User值意味着“任何用户”并且是最不特定的)。最终排序的user表看起来像这样：
+-----------+----------+-
| Host | User | …
+-----------+----------+-
| localhost | root | … ...
| localhost | | … ...
| % | jeffrey | … ...
| % | root | … ...
+-----------+----------+-
当客户端试图连接时，服务器浏览排序的条目并使用找到的第一匹配。对于由jeffrey从localhost的连接，表内有两个条目匹配：Host和User值为'localhost'和''的条目，和值为'%'和'jeffrey'的条目。'localhost'条目首先匹配，服务器可以使用。
还有一个例子。假定user表看起来像这样：
+----------------+----------+-
| Host | User | …
+----------------+----------+-
| % | jeffrey | …
| thomas.loc.gov | | …
+----------------+----------+-
排序后的表看起来像这样：
+----------------+----------+-
| Host | User | …
+----------------+----------+-
| thomas.loc.gov | | …
| % | jeffrey | …
+----------------+----------+-
由jeffrey从thomas.loc.gov的连接与第一行匹配，而由jeffrey从whitehouse.gov的连接被第二个匹配。
普遍的误解是认为，对给定的用户名，当服务器试图对连接寻找匹配时，明确命名那个用户的所有条目将首先被使用。这明显不符合事实。先前的例子说明了这点，在那里由jeffrey从thomas.loc.gov的连接没被包含'jeffrey'作为User列值的行匹配，但是由没有用户名的题目匹配！结果是，jeffrey被鉴定为匿名用户，即使他连接时指定了用户名。
如果你能够连接服务器，但你的权限不是你期望的，你可能被鉴定为其它账户。要想找出服务器用来鉴定你的账户，使用CURRENT_USER()函数。它返回user_name@host_name格式的值，说明User和Host 值匹配user表记录。假定jeffrey连接并发出下面的查询：
mysql> SELECT CURRENT_USER();
+----------------+
| CURRENT_USER() |
+----------------+
| @localhost |
+----------------+
这儿显示的结果说明user表行有空的User列值。换句话说，服务器将jeffrey视为匿名用户。
诊断鉴定问题的另一个方法是打印出user表并且手动排序它看看第一个匹配在哪儿进行。又见12.9.3节，“信息函数”。
