当服务器启动时，它读取这些项并存储它们（先主机，然后是主机的用户），其顺序是比较详细的值在前，不详细的在后：
带localhost 的两项一起存储，有root 的那个项放在前，因为这项比空白的更具体、更详细。带有p i t - v i per.snake.net 的项以类似的方法一起存储。这些项都是不带任何通配符的直接Host 值，因此它们都优先于fred 的项进行存储，而fred 项使用了一个通配符。特别地，匿名用户项在存储顺序上优先于fred 的项。
此结果是，当fred 试图从本地主机上进行连接时，带有空白用户名的项匹配先于在Host 列中包含%.snake.net 的项。该项的口令是空白的，因为缺省的匿名用户没有口令。由于fred 在连接时指定了口令，则产生一个错误匹配和错误连接。
这里要记住的事情是，尽管使用通配符指定用户可连接的主机这种方式非常方便，但只要您在user 表中保留匿名用户，就可能会出现从本地主机中连接的问题。
通常，笔者建议删除匿名用户项。这将使您的工作更轻松一些：
MySQL> DELETE FROM user WHERE User="";
如果想更彻底的话，可将其他授权表的匿名用户项也删除。有User 列的表是db、tables_priv 和c o l um n s _ priv。
本节给出的难题是一种特殊的情况，但包含了更为普遍的内容。如果某个用户的权限不按所希望的方式工作，则检查授权表，看看是否有某些项包含了比所讨论的该用户的项更详细的Host 值，以及试图通过那个用户匹配连接的Host 值。如果是这样的，问题的原因可能就是它。您可能需要使该用户的项更详细（或增加另一个项来包括更详细的情况）。
英特尔 酷睿(TM)2双核,送指纹识别器一个，再赠两份好礼，请电800-858-2418
