Você provavelmente tem um usuário anônimo
''@'localhost' ou ''@'127.0.0.1' . Conforme o manual :
Quando várias correspondências são possíveis, o servidor deve determinar qual delas usar. Ele resolve esse problema da seguinte forma:(...)
- Quando um cliente tenta se conectar, o servidor examina as linhas [da tabela mysql.user] em ordem ordenada.
- O servidor usa a primeira linha que corresponde ao nome do host do cliente e ao nome do usuário.
(...) O servidor usa regras de classificação que ordenam as linhas com os valores de Host mais específicos primeiro .Nomes de host literais [como 'localhost'] e os endereços IP são os mais específicos.
Portanto, um usuário anônimo "mascararia" qualquer outro usuário como
'[any_username]'@'%' ao conectar de localhost . 'bill'@'localhost' corresponde a 'bill'@'%' , mas corresponderia (por exemplo) ''@'localhost' de antemão. A solução recomendada é descartar esse usuário anônimo (isso geralmente é uma boa coisa a fazer de qualquer maneira).
As edições abaixo são irrelevantes para a pergunta principal. Eles servem apenas para responder a algumas perguntas levantadas em outros comentários neste tópico.
Editar 1
Autenticação como
'bill'@'%' através de um soquete.
example@sqldat.com:/home/mysql-5.5.16-linux2.6-x86_64# ./mysql -ubill -ppass --socket=/tmp/mysql-5.5.sock
Welcome to the MySQL monitor (...)
mysql> SELECT user, host FROM mysql.user;
+------+-----------+
| user | host |
+------+-----------+
| bill | % |
| root | 127.0.0.1 |
| root | ::1 |
| root | localhost |
+------+-----------+
4 rows in set (0.00 sec)
mysql> SELECT USER(), CURRENT_USER();
+----------------+----------------+
| USER() | CURRENT_USER() |
+----------------+----------------+
| example@sqldat.com | example@sqldat.com% |
+----------------+----------------+
1 row in set (0.02 sec)
mysql> SHOW VARIABLES LIKE 'skip_networking';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| skip_networking | ON |
+-----------------+-------+
1 row in set (0.00 sec)
Editar 2
Exatamente a mesma configuração, exceto que reativei a rede e agora crio um usuário anônimo
''@'localhost' .
example@sqldat.com:/home/mysql-5.5.16-linux2.6-x86_64# ./mysql
Welcome to the MySQL monitor (...)
mysql> CREATE USER ''@'localhost' IDENTIFIED BY 'anotherpass';
Query OK, 0 rows affected (0.00 sec)
mysql> Bye
example@sqldat.com:/home/mysql-5.5.16-linux2.6-x86_64# ./mysql -ubill -ppass \
--socket=/tmp/mysql-5.5.sock
ERROR 1045 (28000): Access denied for user 'bill'@'localhost' (using password: YES)
example@sqldat.com:/home/mysql-5.5.16-linux2.6-x86_64# ./mysql -ubill -ppass \
-h127.0.0.1 --protocol=TCP
ERROR 1045 (28000): Access denied for user 'bill'@'localhost' (using password: YES)
example@sqldat.com:/home/mysql-5.5.16-linux2.6-x86_64# ./mysql -ubill -ppass \
-hlocalhost --protocol=TCP
ERROR 1045 (28000): Access denied for user 'bill'@'localhost' (using password: YES)
Editar 3
Mesma situação da edição 2, agora fornecendo a senha do usuário anônimo.
example@sqldat.com:/home/mysql-5.5.16-linux2.6-x86_64# ./mysql -ubill -panotherpass -hlocalhost
Welcome to the MySQL monitor (...)
mysql> SELECT USER(), CURRENT_USER();
+----------------+----------------+
| USER() | CURRENT_USER() |
+----------------+----------------+
| example@sqldat.com | @localhost |
+----------------+----------------+
1 row in set (0.01 sec)
Conclusão 1, da edição 1:Pode-se autenticar como
'bill'@'%' através de um soquete. Conclusão 2, da edição 2:Se alguém se conecta por meio de TCP ou de um soquete não tem impacto no processo de autenticação (exceto que não se pode conectar como outra pessoa além de
'something'@'localhost' através de um soquete, obviamente). Conclusão 3, da edição 3:Embora eu tenha especificado
-ubill , recebi acesso como usuário anônimo. Isso ocorre por causa das "regras de classificação" aconselhadas acima. Observe que na maioria das instalações padrão, uma senha anônima usuário existe
(e deve ser protegido/removido). 
