MySQL на сервере: частые ошибки и решения

MAATRIX

Ошибки MySQL на сервере пугают текстом, но за большинством стоит одна из десятка типовых причин с коротким решением. Ниже — разбор частых проблем: access denied, «can't connect through socket», too many connections, переполнение таблиц и диска, кракозябры в кодировке и внезапно упавшая служба. Для каждой сначала идёт решение, потом причина — чтобы вы починили быстро, а разобрались спокойно.

Access denied for user

Классика: ERROR 1045 (28000): Access denied for user 'appuser'@'localhost'. Сервер работает, но пускать не хочет. Причин три, и они лечатся по-разному. Первая — неверный пароль или пользователь просто не заведён. Проверьте список пользователей и их хостов, зайдя администратором:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

Вторая причина — несовпадение хоста. В MySQL пользователь 'appuser'@'localhost' и 'appuser'@'127.0.0.1' — это два разных пользователя. Если приложение подключается по TCP к 127.0.0.1, а вы завели только localhost (сокет), доступа не будет. Заведите нужную комбинацию или подключайтесь через сокет. Третья причина — не хватает прав на конкретную базу: выдайте их явно через GRANT и не забудьте FLUSH PRIVILEGES.

Если забыли пароль root, его можно сбросить, запустив MySQL с --skip-grant-tables, но делать это нужно осторожно и только локально, временно закрыв сетевой доступ. В этом режиме база пускает вообще без проверки прав, поэтому на время сброса порт 3306 должен быть закрыт фаерволом наглухо, а сразу после смены пароля режим отключается и служба перезапускается нормально. Оставлять сервер в таком состоянии нельзя ни минуты дольше необходимого.

Ещё одна частая причина отказа — свежая база после mysql_secure_installation, где вы усилили политику паролей. Если приложение подключается со старым простым паролем, MySQL его не примет. Либо смените пароль пользователя на соответствующий политике, либо осознанно понизьте validate_password.policy — но простые пароли на боевом сервере это плохая идея, особенно если порт хоть как-то доступен извне.

Can't connect through socket

Ошибка Can't connect to local MySQL server through socket '/run/mysqld/mysqld.sock' почти всегда означает одно: сервер не запущен. Проверьте статус и, если служба лежит, посмотрите причину в журнале:

sudo systemctl status mysql
sudo journalctl -u mysql -n 50

Частые причины падения — закончилось место на диске, повреждён конфиг после ручной правки или проблемы с правами на каталог данных. Если в журнале видно InnoDB: Cannot allocate memory, серверу не хватило RAM под буфер — уменьшите innodb_buffer_pool_size или добавьте памяти на VPS. Если проблема в свободном месте, освободите диск и запустите службу заново.

Реже сокет просто лежит по другому пути: приложение ищет его в одном месте, а MySQL создаёт в другом. Тогда либо подключайтесь по TCP (-h 127.0.0.1), либо укажите правильный путь к сокету в настройках клиента. Путь всегда виден в конфиге сервера в секции [mysqld].

Too many connections

ERROR 1040: Too many connections — сервер упёрся в лимит max_connections. Быстро посмотреть, что происходит:

sudo mysql -e "SHOW STATUS LIKE 'Threads_connected'; SHOW PROCESSLIST;"

Часто виноваты «спящие» соединения в состоянии Sleep, которые приложение открыло и не закрыло — типичная беда при отсутствии пула соединений или при слишком долгом wait_timeout. Простое повышение лимита помогает лишь на время и ест память: каждое соединение резервирует буферы. Правильнее уменьшить wait_timeout, чтобы простаивающие коннекты закрывались быстрее, и настроить пул соединений на стороне приложения.

Если сайтов на сервере много и все они плодят коннекты, честный вывод простой: либо оптимизировать приложения, либо взять сервер с большим объёмом RAM. Задирать max_connections до тысячи на слабой машине — путь к тому, что база начнёт падать под собственным весом при первой волне трафика.

Table is full или No space left

Ошибка The table is full или отказ записи с No space left on device означает, что закончилось место — на диске или в лимите таблицы. Сначала проверьте диск:

df -h
sudo du -sh /var/lib/mysql/*

Чаще всего диск съедают три вещи: разросшийся бинарный лог репликации, файлы больших таблиц и старые дампы бэкапов рядом с базой. Бинлоги можно очистить, убедившись, что они уже не нужны репликам: PURGE BINARY LOGS BEFORE '2026-08-01 00:00:00';. И настройте автоматическую очистку через binlog_expire_logs_seconds, чтобы логи не копились бесконечно.

После освобождения места база обычно продолжает работу. На будущее вынесите бэкапы на отдельное хранилище и включите мониторинг свободного места с оповещением заранее. Переполнение диска — одна из самых частых причин падения БД, и она полностью предотвратима.

Кракозябры вместо русского текста

Текст сохраняется, но вместо русских букв — «Ð¿Ñивеѻ или вопросительные знаки. Это несовпадение кодировок между базой, таблицей, соединением и приложением. Проверьте текущие настройки:

sudo mysql -e "SHOW VARIABLES LIKE 'character_set%';"

Целевое состояние — всё в utf8mb4. Если база создана в старой кодировке, переведите таблицы: ALTER TABLE имя CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;. Важнее всего кодировка соединения: приложение при подключении должно выставлять SET NAMES utf8mb4 или указывать utf8mb4 в строке подключения. Если этого нет, данные будут искажаться независимо от настроек самой базы.

Отдельная ловушка — данные уже испорчены при вставке в неправильной кодировке. Тогда простой ALTER не спасёт: нужно восстанавливать из корректного дампа. Поэтому кодировку задают правильно с самого начала, до первой записи. При переносе базы дампом через mysqldump тоже следите за кодировкой: снимайте дамп с явным указанием --default-character-set=utf8mb4, иначе на этапе выгрузки текст может исказиться ещё до восстановления, и вы будете чинить проблему не там, где она возникла.

Служба падает или не стартует после перезагрузки

MySQL не поднимается после ребута сервера — частая ситуация на слабых VPS. Смотрите журнал: если там Out of memory или процесс убит OOM-killer, серверу не хватает RAM. На машине с 1 ГБ памяти MySQL 8 с настройками по умолчанию может не влезать. Уменьшите innodb_buffer_pool_size, отключите ненужные компоненты (Performance Schema съедает заметную память) или, что честнее, добавьте RAM.

Иногда помогает swap как страховка от резких пиков, но постоянная работа базы в swap — это медленно и является признаком, что сервер мал для задачи. Если MySQL стабильно упирается в память, это прямой сигнал перейти на тариф с большим объёмом RAM. В MAATRIX можно быстро арендовать VPS в России, США или Великобритании с нужной памятью под MySQL и перенести базу без спешки. Оплата — картой РФ, по СБП, криптой или токеном MAAT, иностранная карта не требуется.

Частые вопросы