При попытке подключения к серверу MySQL сервер принимает или отклоняет подключение на основе следующих условий:

Сервер сначала проверяет учетные данные, а затем — состояние блокировки учетной записи. Неудача на любом этапе приводит к полному отказу в доступе. В противном случае сервер принимает подключение, переходит к этапу 2 и ожидает запросов.

Сервер выполняет проверку личности и учетных данных, используя столбцы в таблице user, принимая подключение только в случае выполнения этих условий:

Ваша личность определяется двумя параметрами:

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

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

Значения паролей, не являющиеся пустыми, хранящиеся в столбце authentication_string таблицы user, зашифрованы. MySQL не хранит пароли в открытом виде, чтобы их смог увидеть кто угодно. Вместо этого пароль, предоставленный пользователем, пытающимся подключиться, шифруется (с использованием метода хэширования паролей, реализованного плагином аутентификации учетных записей). Затем зашифрованный пароль используется во время процесса подключения для проверки правильности пароля. Это происходит без передачи зашифрованного пароля по каналу связи. См. раздел 6.2.1 «Имена пользователей и пароли учётных записей».

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

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

Возможно, что имя хоста клиента и имя пользователя входящего подключения соответствуют более чем одной строке в таблице user. Представленный выше набор примеров демонстрирует это: несколько записей соответствуют подключению с h1.example.net пользователем fred.

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

Сервер использует правила сортировки, которые ставят строки с наиболее конкретными значениями Host на первое место:

Подключения, не являющиеся TCP (файлы сокетов, именованные каналы и общая память), обрабатываются как локальные подключения и соответствуют части хоста localhost, если такие учётные записи есть, или части хоста с подстановочными символами, которые соответствуют localhost в противном случае (например, local%, l%, %).

Строки с одинаковым значением Host сортируются с использованием наиболее конкретных значений User в первую очередь. Пустое значение User означает “любой пользователь” и является наименее конкретным, поэтому для строк с одинаковым значением Host пользователи без анонимного статуса сортируются перед анонимными пользователями.

Для строк с одинаково конкретными значениями Host и 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  | ...
| h1.example.net |          | ...
+----------------+----------+-

Отсортированная таблица выглядит так:

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| h1.example.net |          | ...
| %              | jeffrey  | ...
+----------------+----------+-

Первая строка соответствует подключению любого пользователя с h1.example.net, а вторая строка соответствует подключению пользователя jeffrey с любого хоста.

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

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

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

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