How to Check MySQL Connectivity Without Confusing Availability with Permissions
We test connection, login, and table reading separately. A real MySQL 8.0.46 testbed demonstrates the differences between errors 2003, 1045, and 1142, as well as a successful ping.

In this article
- Уточните параметры подключения
- Важная особенность ping
- Проверьте вход и простой запрос
- Четыре результата на реальном стенде
- Сервер не принимает TCP-соединение
- Сервер отвечает, но вход запрещён
- Вход и простой запрос успешны
- Вход успешен, но чтение таблицы запрещено
- Какой аккаунт принял сервер
- Сравните окружение с приложением
- Краткая карта проверки
- Что передать ответственному специалисту
- Clarify connection parameters
- A key feature of ping
- Check login and a simple query
- Four results on a real testbed
- Server does not accept TCP connections
- Server responds, but access is denied
- Login and simple query succeed
- Login successful, but table read is forbidden
- Which account did the server accept
- Compare the environment with the application
- Quick verification card
- What to provide to the responsible specialist
Сообщение сайта об ошибке базы данных не объясняет, на каком этапе возник отказ. Сервер может быть доступен по сети, но отклонять пользователя. Или вход проходит, а у аккаунта нет нужных разрешений. Проверять эти уровни следует отдельно и из той среды, где работает приложение.
Уточните параметры подключения
Команды ниже предназначены для клиентов MySQL 8.x. Используйте согласованный диагностический аккаунт и фактические адрес и порт сервера. Имя diagnostic_user условное. Отдельный -p запросит пароль в терминале: не дописывайте его в команду и не включайте в переписку.
Введите имя или IP сервера, затем порт. При пустом ответе для порта пример использует 3306; если у приложения другое значение, укажите его:
read -r MYSQL_HOST
read -r MYSQL_PORT
MYSQL_PORT=${MYSQL_PORT:-3306}
mysqladmin --protocol=TCP --connect-timeout=5 -h "$MYSQL_HOST" -P "$MYSQL_PORT" -u diagnostic_user -p ping
printf 'exit=%s\n' "$?"
Читайте код завершения сразу после команды: любой следующий запуск заменяет значение $?. Не используйте один код ping как проверку пароля.
Почему нужно явно выбрать TCP и порт, объясняет документация MySQL о параметрах соединения. На Unix имя localhost без явного протокола обычно выбирает сокет, даже когда указан порт.
Явный TCP помогает не спутать проверку сетевого соединения с подключением через локальный Unix-сокет. Если приложение использует сокет, его нужно проверять отдельно с соответствующими параметрами.
Важная особенность ping
У mysqladmin ping успешный код завершения возможен даже при ответе об отказе в доступе: сервер ответил, а значит проверка его доступности достигла цели. Это не означает, что пароль верный или что приложение получило доступ к базе.
Это поведение прямо описано в руководстве mysqladmin: при отказе в доступе ping может завершиться с кодом 0. Переходите к проверке входа через mysql.
Поэтому читайте сообщение целиком. Отказ в аутентификации, отсутствие соединения и тайм-аут — разные результаты. Не объединяйте их в одно утверждение «база лежит» и не меняйте пароль, пока не установлено, какой аккаунт и способ подключения реально используются.
Проверьте вход и простой запрос
Для проверки аутентифицированного соединения:
mysql --protocol=TCP --connect-timeout=5 -h "$MYSQL_HOST" -P "$MYSQL_PORT" -u diagnostic_user -p --batch --raw -e 'SELECT 1;'
printf 'exit=%s\n' "$?"
Запрос не обращается к прикладной таблице. Его успех подтверждает вход и выполнение простого SQL, но не права на таблицы магазина. Для следующего этапа нужен заранее выбранный запрос чтения к нужной базе с минимальным набором разрешений.
Удалённое подключение должно использовать принятую в проекте защиту соединения. Если она предусматривает TLS и проверку имени по доверенному центру, сохраняйте эти параметры и в диагностике. Не ослабляйте проверку шифрования ради успешного теста.
Четыре результата на реальном стенде
2 октября 2026 года мы воспроизвели проверки на отдельном Linux-стенде: сервер, mysql и mysqladmin версии 8.0.46-0ubuntu0.24.04.3. Использовались только вымышленные данные, TCP на 127.0.0.1 и временный порт. Соединение с запущенным сервером было зашифровано. Это пример диагностики, а не измерение доступности рабочего сайта; ветка MySQL 8.4 сверена по документации, но в этом опыте не запускалась.
Сервер не принимает TCP-соединение
До запуска стендового сервера клиент не смог установить TCP-соединение. Код mysql — 1:
ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1:58345' (111)
ERROR 2003 означает, что клиент не подключился к указанному адресу и порту. В нашем опыте процесс ещё не работал. На другом сервере нужно различать отказ и тайм-аут, затем проверить адрес, порт, слушающий процесс и сетевые правила. Одно такое сообщение не доказывает, что потеряна база данных.
Сервер отвечает, но вход запрещён
После запуска сервера мы ввели неправильный пароль. mysqladmin ping сообщил Access denied, но завершился с кодом 0. Та же попытка входа через mysql с SELECT 1 завершилась с кодом 1:
ERROR 1045 (28000): Access denied for user 'diagnostic_user'@'127.0.0.1' (using password: YES)
ERROR 1045 отделяет отказ в доступе от отсутствия сетевого ответа. В стенде причиной был намеренно неверный пароль; в реальной системе код сам по себе не доказывает именно ошибку пароля. Нужно сверить выбранный аккаунт, источник подключения и способ аутентификации, сохраняя параметры защиты соединения.
Вход и простой запрос успешны
С правильным паролем SELECT 1 завершился с кодом 0 и вернул столбец 1 со значением 1. Это подтверждает аутентифицированное соединение и простой запрос. Прикладная таблица в этом тесте не читалась.
Вход успешен, но чтение таблицы запрещено
Этому же аккаунту разрешили чтение одной синтетической таблицы, а на другую разрешения не дали. Запрос к защищённой таблице:
SELECT id FROM diagnostic_lab.protected_rows LIMIT 1;
ERROR 1142 (42000) at line 1: SELECT command denied to user 'diagnostic_user'@'127.0.0.1' for table 'protected_rows'
mysql завершился с кодом 1, хотя вход и SELECT 1 уже были успешны. Запрос к разрешённой таблице readable_rows вернул id=1 и код 0. Для своего приложения выберите с администратором небольшой запрос чтения к нужной таблице: название diagnostic_lab относится только к нашему стенду.
Различия между отказом входа и запретом операции приведены в справочнике серверных ошибок MySQL. При ERROR 1142 проверяйте конкретное действие и объект, а не меняйте пароль и не выдавайте все права ради зелёного теста.
Какой аккаунт принял сервер
После успешного входа выполните запросы в этой же сессии mysql. Они показывают версию сервера, аккаунт, выбранный при аутентификации, и назначенные ему разрешения:
SELECT VERSION() AS server_version, CURRENT_USER() AS authenticated_account;
SHOW GRANTS;
На стенде сервер вернул версию 8.0.46-0ubuntu0.24.04.3 и diagnostic_user@127.0.0.1. SHOW GRANTS показал SELECT только на diagnostic_lab.readable_rows. Поэтому отказ чтения protected_rows был ожидаемым. В вашей системе сравните результат с аккаунтом приложения; диагностический пользователь с другими разрешениями не заменяет эту проверку.
Для своего аккаунта SHOW GRANTS не требует отдельного SELECT на системную схему mysql. Если права получены через роли, учитывайте и активные роли текущей сессии. Список назначений не заменяет выполнение нужного разрешённого запроса.
Сравните окружение с приложением
Проверка с административного ноутбука может пройти, тогда как контейнер приложения не видит сервер. Сравните адрес, порт, DNS, сетевые ограничения и имя аккаунта. Отдельно учитывайте, что права MySQL зависят не только от имени пользователя, но и от источника подключения.
Пример: локальный тест работает через сокет, а сайт использует TCP на другом адресе. Эти результаты не противоречат друг другу. Нужно повторить именно способ приложения, сохранив его необходимые параметры безопасности и не раскрывая пароль.
Краткая карта проверки
Проверка | Что подтверждает успех | Что проверить отдельно |
|---|---|---|
| Сервер отвечает на попытку связи | Аутентификацию и права |
| Вход и выполнение простого запроса | Доступ к прикладным таблицам |
Запрос чтения к нужной базе | Конкретный разрешённый сценарий чтения | Операции приложения и его окружение |
Что передать ответственному специалисту
Достаточно времени, точки проверки, протокола, обезличенного аккаунта и точного класса ошибки. Не прикладывайте конфигурационный файл с паролем. Если вход успешен, укажите отдельно результат простого запроса и проверки нужной базы.
После исправления выполните тот же тест из окружения приложения и проверьте пользовательский сценарий сайта. Наличие ответа сервера, успешный вход и корректная работа магазина — три разных подтверждения. Такая последовательность помогает найти нужный уровень ошибки без случайного изменения прав и настроек сети.
A database error message on the website does not explain at which stage the failure occurred. The server may be reachable over the network but reject the user. Or the login may succeed, but the account lacks the necessary permissions. These levels must be checked separately from the environment where the application runs.
Clarify connection parameters
The commands below are intended for MySQL 8.x clients. Use a consistent diagnostic account and the actual server address and port. The name diagnostic_user is conditional. The separate -p flag prompts for a password in the terminal: do not append it to the command or include it in correspondence.
Enter the server name or IP address, then the port. If the response is empty, the example uses 3306 for the port; if the application uses a different value, specify it:
read -r MYSQL_HOST
read -r MYSQL_PORT
MYSQL_PORT=${MYSQL_PORT:-3306}
mysqladmin --protocol=TCP --connect-timeout=5 -h "$MYSQL_HOST" -P "$MYSQL_PORT" -u diagnostic_user -p ping
printf 'exit=%s\n' "$?"
Read the exit code immediately after the command: any subsequent execution overwrites the $? value. Do not use a single ping code as a password check.
Why you must explicitly select TCP and a port is explained in the MySQL documentation on connection parameters. On Unix, the name localhost without an explicit protocol typically selects a socket, even when a port is specified.
Explicit TCP helps distinguish a network connection check from a connection via a local Unix socket. If the application uses a socket, it must be checked separately with the appropriate parameters.
A key feature of ping
With mysqladmin ping, a successful exit code is possible even when the response indicates access denial: the server responded, so the availability check reached its goal. This does not mean the password is correct or that the application gained access to the database.
This behavior is explicitly described in the mysqladmin guide: when access is denied, ping may complete with code 0. Proceed to verify the login via mysql.
Therefore, read the entire message. Authentication failure, no connection, and timeout are different results. Do not lump them into a single statement like "the database is down" and do not change the password until you confirm which account and connection method are actually in use.
Check login and a simple query
To verify an authenticated connection:
mysql --protocol=TCP --connect-timeout=5 -h "$MYSQL_HOST" -P "$MYSQL_PORT" -u diagnostic_user -p --batch --raw -e 'SELECT 1;'
printf 'exit=%s\n' "$?"
The query does not access the application table. Its success confirms login and execution of a simple SQL statement, but not permissions for the store tables. For the next stage, you need a pre-selected read query against the target database with the minimal set of required permissions.
Remote connections must use the connection protection adopted in the project. If it includes TLS and name verification by a trusted certificate authority, preserve these parameters in diagnostics as well. Do not weaken encryption verification just to pass a test.
Four results on a real testbed
On October 2, 2026, we reproduced the checks on a separate Linux staging environment: a server, mysql, and mysqladmin version 8.0.46-0ubuntu0.24.04.3. Only fictional data were used, TCP on 127.0.0.1, and a temporary port. The connection to the running server was encrypted. This is an example of diagnostics, not a measurement of a live site's availability; the MySQL 8.4 branch was verified against documentation, but it was not launched in this experiment.
Server does not accept TCP connections
Before the test server started, the client could not establish a TCP connection. The mysql error code is 1:
ERROR 2003 (HY000): Can't connect to MySQL server on '127.0.0.1:58345' (111)
ERROR 2003 means the client failed to connect to the specified address and port. In our experience, the process was not yet running. On another server, distinguish between a refusal and a timeout, then check the address, port, listening process, and network rules. A single such message does not prove that the database is lost.
Server responds, but access is denied
After starting the server, we entered an incorrect password. mysqladmin ping reported Access denied but exited with code 0. The same login attempt via mysql with SELECT 1 exited with code 1:
ERROR 1045 (28000): Access denied for user 'diagnostic_user'@'127.0.0.1' (using password: YES)
ERROR 1045 separates access denial from lack of network response. In the test environment, the cause was an intentionally incorrect password; in a real system, the code alone does not prove a password error. Verify the selected account, connection source, and authentication method while preserving connection security parameters.
Login and simple query succeed
With the correct password, SELECT 1 exited with code 0 and returned a column 1 with value 1. This confirms an authenticated connection and a simple query. The application table was not read in this test.
Login successful, but table read is forbidden
Read access was granted to one synthetic table for this account, but not to the other. Query to the protected table:
SELECT id FROM diagnostic_lab.protected_rows LIMIT 1;
ERROR 1142 (42000) at line 1: SELECT command denied to user 'diagnostic_user'@'127.0.0.1' for table 'protected_rows'
mysql exited with code 1, even though login and SELECT 1 were successful. The query to the allowed table readable_rows returned id=1 and code 0. For your application, choose a small read query for the required table together with the administrator: the name diagnostic_lab applies only to our test stand.
The differences between a login failure and an operation denial are provided in the MySQL server error reference. When encountering ERROR 1142, check the specific action and object, rather than changing the password or granting all privileges just to get a green test result.
Which account did the server accept
After a successful login, run queries in the same mysql session. They show the server version, the account selected during authentication, and the permissions assigned to it:
SELECT VERSION() AS server_version, CURRENT_USER() AS authenticated_account;
SHOW GRANTS;
On the staging environment, the server returned version 8.0.46-0ubuntu0.24.04.3 and diagnostic_user@127.0.0.1. SHOW GRANTS showed SELECT only on diagnostic_lab.readable_rows. Therefore, the failure to read protected_rows was expected. In your system, compare the result with the application account; a diagnostic user with different permissions does not replace this check.
For your account, SHOW GRANTS does not require a separate SELECT on the mysql system schema. If privileges are granted via roles, consider the active roles of the current session. The list of assignments does not replace executing the required authorized query.
Compare the environment with the application
A check from an administrative laptop may succeed, while the application container cannot see the server. Compare the address, port, DNS, network restrictions, and account name. Note separately that MySQL permissions depend not only on the username but also on the connection source.
Example: a local test works via socket, while the site uses TCP on a different address. These results do not contradict each other. You must replicate the application's method exactly, preserving its necessary security parameters without exposing the password.
Quick verification card
Check | What confirms success | What to check separately |
|---|---|---|
| The server responds to the connection attempt | Authentication and privileges |
| Login and execution of a simple query | Access to application tables |
Read request to the required database | Specific allowed read scenario | Application operations and its environment |
What to provide to the responsible specialist
Sufficient time, verification points, a protocol, an anonymized account, and the exact error class. Do not attach a configuration file containing a password. If the login is successful, separately report the result of a simple request and the database check.
After the fix, run the same test from the application environment and verify the website user scenario. A server response, a successful login, and correct store operation are three distinct confirmations. This sequence helps identify the precise error level without accidentally changing permissions or network settings.





Discussion 0
Share your experience and ask questions. Comments without links appear after editorial review.
No comments yet. Start the discussion.