MySQL: ERROR 1040 — Too many connections

#Что означает ошибка

Ошибка MySQL «Too many connections» (1040) значит, что достигнут предел max_connections. Причины: неэффективные соединения без закрытия, всплеск трафика, медленные запросы, удерживающие слоты, либо слишком малое значение параметра.

Важно не только увеличить предел, но и найти источник лишних соединений.

Для входа при исчерпании предела есть резервное соединение для пользователя с привилегией SUPER (CONNECTION_ADMIN).

Сервер достиг лимита соединений max_connections. Причины — утечки соединений, лавина запросов, медленные запросы, малые лимиты. Нужно найти причину, а не только увеличить лимит.

#Причины и решения

#Пошаговое решение

1. Войдите как администраторЕсли есть доступ администратора базы, войдите в MySQL через терминал (mysql -u администратор -p с реальным именем) либо откройте раздел SQL панели. При полном исчерпании обычных соединений может потребоваться заранее предусмотренное административное подключение; не перезапускайте MySQL вслепую, поскольку это прервёт все запросы сайта.
2. Посмотрите процессыВ клиенте MySQL выполните SHOW FULL PROCESSLIST; и SHOW GLOBAL STATUS LIKE "Threads_connected";. Запишите длительные запросы, состояние Sleep и учётные записи. Если список сокращён из-за прав, попросите администратора с PROCESS предоставить диагностику. Не публикуйте вывод целиком: в текстах SQL могут содержаться конфиденциальные данные.
3. Завершите зависшие соединенияТолько если доказано, что конкретное соединение зависло, узнайте его ID из SHOW FULL PROCESSLIST и оцените, не выполняется ли важная запись/транзакция. Администратор может использовать KILL QUERY номер; для прекращения запроса либо KILL CONNECTION номер; для разрыва соединения; оба действия потенциально откатывают транзакции. Не завершайте соединения массово и не трогайте служебные потоки.
4. Поднимите max_connectionsПосмотрите SHOW VARIABLES LIKE "max_connections"; и SHOW GLOBAL STATUS LIKE "Max_used_connections";. Если лимит действительно достигается, сначала устраните утечки соединений и долгие запросы. Увеличивайте max_connections только после расчёта доступной памяти на поток и проверки ограничений операционной системы; меняйте конфигурацию по согласованной процедуре, а не бессрочно через SET GLOBAL без расчёта.
5. Найдите причинуВ журнале приложения и статистике базы найдите источник всплеска: пул подключений, задания cron, парсер, атака ботов или запросы без индекса. Ограничьте размер пула и число параллельных задач, добавьте корректное освобождение соединений. Затем несколько раз проверьте Threads_connected, задержки и число ошибок 1040 при обычной и пиковой нагрузке.
6. Текущие соединения и запросы

   ТекстКомандаКопировать всёВыделить

   Текущие соединения и запросы.

   SHOW PROCESSLIST;

#Диагностика

Зайдите под администратором: mysql -u root -p. Выполните SHOW VARIABLES LIKE 'max_connections';, SHOW STATUS LIKE 'Threads_connected';, SHOW STATUS LIKE 'Max_used_connections'; и SHOW FULL PROCESSLIST;. Смотрите на поля Time, State, Info: большое число соединений в Sleep означает, что приложение не закрывает соединения; много долгих запросов указывает на медленный SQL.

#Быстрое решение

Увеличьте лимит без перезапуска: SET GLOBAL max_connections = 300;, а затем закрепите в my.cnf: [mysqld] → max_connections = 300. Завершите зависшие соединения KILL ID;. Увеличивайте лимит осторожно: каждое соединение потребляет память (sort_buffer_size, read_buffer_size и др.). Проверьте оценку памяти и общий лимит ОЗУ.

#Устранение причины

Включите пулы соединений в приложении (PDO persistent осторожно, пул в Java/Node), закрывайте соединения, сократите wait_timeout (например, 60–300 секунд). Включите медленный журнал: SET GLOBAL slow_query_log = 1; SET GLOBAL long_query_time = 1; и добавьте индексы. Для CMS отключите ресурсоёмкие плагины. Для всплесков трафика настройте кэширование (Redis, страничный кэш) и ограничения на уровне веб-сервера.