Когда Вы пытаетесь соединиться с сервером MySQL, сервер принимает или отклоняет соединение, основанное на Ваших идентификационных данных и можно ли проверить свои идентификационные данные, предоставляя корректный пароль. В противном случае сервер лишает доступа Вам полностью. Иначе, сервер принимает соединение, и затем вводит Этап 2 и ожидает запросов.

Ваши идентификационные данные основаны на двух сведениях:

Проверка идентификационных данных выполняется, используя три user табличные столбцы контекста (Host, User, и Password). Сервер принимает соединение только если Host и User столбцы в некоторых user соответствие строки таблицы имя хоста клиента и имя пользователя и клиент предоставляет пароль, определенный в той строке. Правила для допустимого Host и User значения даются в Разделе 6.2.3, "Определение Имен учетной записи".

Если User значение столбца является непробелом, имя пользователя во входящем соединении должно соответствовать точно. Если User значение является пробелом, оно соответствует любое имя пользователя. Если user у строки таблицы, которая соответствует входящее соединение, есть пустое имя пользователя, пользователь, как полагают, является анонимным пользователем без имени, не пользователем с именем что клиент, фактически определенный. Это означает, что пустое имя пользователя используется для всей дальнейшей проверки доступа продолжительность соединения (то есть, во время Этапа 2).

Password столбец может быть пробелом. Это не подстановочный знак и не означает, что любой пароль соответствует. Это означает, что пользователь должен соединиться, не определяя пароль. Если сервер аутентифицирует клиент, использующий плагин, метод аутентификации, что сменные реализации могут или, возможно, не используют пароль в Password столбец. В этом случае возможно, что внешний пароль также используется, чтобы аутентифицировать к серверу MySQL.

Непробел Password значения в user таблица представляет зашифрованные пароли. MySQL не хранит пароли в форме простого текста для любого, чтобы видеть. Скорее пароль, предоставленный пользователем, который пытается соединиться, шифруется (использование PASSWORD() функция). Зашифрованный пароль тогда используется во время процесса соединения, проверяя, корректен ли пароль. Это делается без зашифрованного пароля, когда-либо перемещаясь по соединению. См. Раздел 6.3.1, "Имена пользователей и Пароли".

С точки зрения MySQL зашифрованный пароль является реальным паролем, таким образом, никогда недопустимо предоставлять никому доступ к этому. В частности не давайте неадминистративный пользовательский доступ для чтения к таблицам в mysql база данных.

Следующая таблица показывает как различные комбинации Host и User значения в user таблица применяется к входящим соединениям.

Для имени хоста клиента и имени пользователя входящего соединения возможно соответствовать больше чем одну строку в user таблица. Предыдущий набор примеров демонстрирует это: Несколько из записей, показанных соответствие соединение от thomas.loc.gov fred.

Когда многократные соответствия возможны, сервер должен определить который из них, чтобы использовать. Это решает этот вопрос следующим образом:

Использование сервера, сортирующее правила, что строки порядка с самым специфичным Host значения сначала. Литеральные имена хоста и IP-адреса являются самыми определенными. (На специфику литерального IP-адреса не влияют тем, есть ли у нее сетевая маска, таким образом, 192.168.1.13 и 192.168.1.0/255.255.255.0 считаются одинаково определенными.) Образец '%' означает "любой узел" и является наименее определенным. Пустая строка '' также означает "любой узел", но виды после '%'. Строки с тем же самым Host значение упорядочивается с самым специфичным User значения сначала (пробел User значение означает "любого пользователя" и является наименее определенным).

Чтобы видеть, как это работает, предположите что user таблица похожа на это:

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

Когда сервер читает таблицу в память, это сортирует строки, используя правила, только описанные. Результат после сортировки похож на это:

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

Когда клиент пытается соединиться, сервер просматривает сортированные строки и использует первое найденное соответствие. Для соединения от localhost jeffrey, две из строк от табличного соответствия: тот с Host и User значения 'localhost' и '', и тот со значениями '%' и 'jeffrey'. 'localhost' строка кажется первой в сортированном порядке, так, чтобы был тот использование сервера.

Вот другой пример. Предположите что user таблица похожа на это:

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

Сортированная таблица похожа на это:

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

Соединение jeffrey от thomas.loc.gov является соответствующим первой строкой, тогда как соединение jeffrey от любого узла является соответствующим вторым.

Если Вы в состоянии соединиться с сервером, но Ваши полномочия не состоят в том тем, что Вы ожидаете, Вы, вероятно, аутентифицируетесь как некоторая другая учетная запись. Чтобы узнать, что считает сервер используемым, чтобы аутентифицировать Вас, используйте CURRENT_USER() функция. (См. Раздел 12.14, "информационные Функции".) Это возвращает значение в user_name@host_name формат, который указывает User и Host значения от соответствия user строка таблицы. Предположите это jeffrey соединяет и выпускает следующий запрос:

mysql> SELECT CURRENT_USER();+----------------+| CURRENT_USER() |+----------------+| @localhost     |+----------------+

Результат, показанный здесь, указывает что соответствие user у строки таблицы был пробел User значение столбца. Другими словами сервер обрабатывает jeffrey как анонимный пользователь.

Другой способ диагностировать проблемы аутентификации состоит в том, чтобы распечатать user таблица и вид это вручную, чтобы видеть, где первое соответствие делается.