Quando você tenta se conectar a um servidor MySQL, o servidor aceita ou rejeita a conexão baseado na sua identidade e se pode ou não verificar sua identidade fornecendo a senha correta. Senão, o servidor nega o acesso a você completamente. De outra forma, o servidor aceita a conexão, entra no estágio 2 e espera por requisiçiões.

Sua identidade é baseada em duas partes de informação:

A conferência da identidade é feita utilizando os tres campos de escopo da tabela user (Host, User e Password). O servidor aceita a conexão somente se uma entrada na tabela user coincidir com a máquina, nome de usuário e a senha fornecidos.

Valores dos campos escopo na tabela user podem ser especificados como segue:

Valores de Password que não estão em branco são apresentados como senhas criptografadas. O MySQL não armazena senhas na forma de texto puro para qualquer um ver. Em vez disso, a senha fornecida por um usuário que está tentando se conectar é criptografada (utilizando a função PASSWORD()). A senha criptografada é então usada quando o cliente/servidor estiver conferindo se a senha é correta (Isto é feito sem a senha criptografada sempre trafegando sobre a conexão.) Perceba que do ponto de vista do MySQL a senha criptografada é a senha REAL, portanto você não deve passá-la para ninguém! Em particular, não forneça a usuários normais acesso de leitura para as tabelas no banco de dados mysql! A partir da versão 4.1, o MySQL emprega um mecanismo de senha e login diferente que é seguro mesmo se fizerem um sniff nos pacotes TCP/IP e/ou o banco de dados mysql é capturado.

Os exemplos abaixo mostram várias combinações de valores de Host e User nos registros da tabela user aplicando a novas conexões:

Como você pode usar valores coringas de IP no campo Host (por exemplo, '144.155.166.%' combina com todas máquinas em uma subrede), existe a possibilidade que alguém possa tentar explorar esta capacidade nomeando a máquina como 144.155.166.algumlugar.com. Para evitar tais tentativas, O MySQL desabilita a combinação com nomes de máquina que iniciam com dígitos e um ponto. Portanto se você possui uma máquina nomeada como 1.2.foo.com, este nome nunca irá combinar com uma coluna Host das tabelas de permissões. Somente um número IP pode combinar com um valor coringa de IP.

Uma conexão de entrada pode coincidir com mais de uma entrada na tabela user. Por exemplo, uma conexão a partir de thomas.loc.gov pelo usuário fred pode combinar com diversas das entradas vistas na tabela anterior. Como o servidor escolhe qual entrada usar se mais de uma coincide? O servidor resolve esta questão ordenando a tabela user no tempo de inicialização, depois procura pelas entradas na ordem da classificação quando um usuário tenta se conectar. A primeira entrada que coincidir é a que será usada.

A ordenação da tabela user funciona da forma mostrada a seguir. Suponha que a tabela user se pareça com isto:

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| %         | root     | ...
| %         | jeffrey  | ...
| localhost | root     | ...
| localhost |          | ...
+-----------+----------+-

Quando o servidor lê a tabela, ele ordena as entradas com os valores mais específicos de Host primeiro ('%' na coluna Host significa ``qualquer máquina'' e é menos específico). Entradas com o mesmo valor Host são ordenadas com os valores mais específicos de User primeiro (um valor em branco na coluna User significa ``qualquer usuário'' e é menos específico). O resultado da tabela user ordenada ficaria assim:

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| localhost | root     | ...
| localhost |          | ...
| %         | jeffrey  | ...
| %         | root     | ...
+-----------+----------+-

Quando uma conexão é iniciada, o servidor procura entre as entradas ordenadas e utiliza a primeira entrada coincidente. Para uma conexão a partir de localhost feito por jeffrey, as entradas com 'localhost' na coluna Host coincide primeiro. Destas, a entrada com o nome do usuário em branco combina com o nome da máquina e o nome do usuário. (A entrada '%'/'jeffrey' também casaria, mas ela não é a primeira entrada coincidente na tabela.

Aqui está outro exemplo. Suponha que a tabela user fosse assim:

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| %              | jeffrey  | ...
| thomas.loc.gov |          | ...
+----------------+----------+-

A tabela ordenada pareceria com isto:

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| thomas.loc.gov |          | ...
| %              | jeffrey  | ...
+----------------+----------+-

Uma conexão a partir de thomas.loc.gov feita por jeffrey coincide com a primeira entrada, no entanto, uma conexão de whitehouse.gov fetia por jeffrey coincidiria com a segunda entrada na tabela.

Um erro comum é pensar que para um determinado usuário, todas as entradas que citam explicitamente este usuário serão usadas primeiro quando o usuário tentar encontrar uma combinação para a conexão. Simplesmente isto não é verdade. O exemplo anterior ilustra isto, onde uma conexão de thomas.loc.gov feita por jeffrey combina primeiro não com a entrada contendo 'jeffrey' no valor do campo user, mas sim pela entrada sem o nome de usuário!

Se você tiver problemas conectando ao servidor, imprima a tabela user e ordene-a na manualmente para ver onde se deu o primeiro coincidência de valores. Se a conexão obtiver sucesso mas os seus privilégios não são os esperados, você pode usar a função CURRENT_USER() (nova na versão 4.0.6) para ver com qual combinação usuário/máquina a sua conexão coincide. See Secção 6.3.6.2, “Funções Diversas”.