#Что означает неисправность
Сообщение «Lost connection to MySQL server during query» означает разрыв соединения, пока клиент ожидал или получал результат SQL-запроса. Для тяжёлого отчёта причины различаются: авария mysqld, сетевой обрыв, слишком крупный пакет, долгий вывод результата или тайм-аут внешнего посредника. Увеличение wait_timeout вслепую обычно не устраняет ошибку активного запроса.
#Возможные причины и признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Результат слишком велик для передачиОдна строка или пакет результата превышает допустимый предел клиента или сервера. | Сбой на крупном BLOB/JSON, иногда в журнале ER_NET_PACKET_TOO_LARGE. | Измерить объём и предел max_allowed_packet, уменьшить размеры возвращаемых полей. |
| Сервер перезапущен или завершился аварийноДолгий запрос связан с нехваткой памяти, перезапуском службы или ошибкой хранилища. | В журнале mysqld время разрыва совпадает с новым запуском сервера или сигналом OOM. | Разобрать системный журнал и план запроса; не маскировать проблему тайм-аутом. |
| Сеть, прокси или ожидание отправкиПромежуточный узел рвёт простаивающий поток, медленный клиент не читает ответ. | SELECT COUNT(*) работает, а поток больших строк прекращается при передаче. | Сверить тайм-ауты конкретного слоя и способ получения результата. |
#Пошаговая диагностика и решение
- Зафиксируйте момент разрыва и полное сообщениеВ журнале приложения сохраните точную ошибку, время начала/окончания отчёта, размер набора и тип клиента — PHP, Python, Workbench или консоль mysql. Отметьте, происходит ли сбой только на большом наборе или и при простом
SELECT 1. Не запускайте тяжёлый отчёт подряд на работающем сервере ради диагностики: он может ухудшить нагрузку. - Проверьте доступность БД лёгким запросомПосле неудачи откройте новое соединение через MySQL Workbench или терминал
mysql -u ИМЯ_ПОЛЬЗОВАТЕЛЯ -pи выполнитеSELECT VERSION(), NOW(), CONNECTION_ID();. Если соединение не открывается, сначала проверяйте доступность службы и сетевой маршрут с администратором. Если лёгкий запрос проходит, проблема связана с конкретной длительностью, объёмом или клиентским чтением. - Оцените масштаб чтения без повторной полной выгрузкиВ тестовой копии найдите запрос и выполните
EXPLAINдля SELECT: это покажет предполагаемые таблицы, способы соединения и индексы без выборки всех строк. Сравните LIMIT и даты фильтра. Если запрос выводит поля BLOB или длинные JSON, оцените необходимость этих полей. Не используйтеEXPLAIN ANALYZEна рабочей БД без оценки затрат: он действительно исполняет запрос. - Проверьте серверный журнал в точное время сбояАдминистратор может открыть журнал MySQL через панель управления сервером или
journalctl -u mysqlв Linux, если имя службы действительно mysql (иногда mysqld). Сверьте отметку времени с ошибкой приложения и проверьте OOM, crash, restart, out of disk. Если сервер перезапускался, настройка сетевого тайм-аута бесполезна до устранения причины. - Прочитайте актуальные пределы пакета и сетевого ожиданияВ том же соединении MySQL выполните
SHOW VARIABLES LIKE 'max_allowed_packet';и запросы к net_read_timeout/net_write_timeout. Обратите внимание: max_allowed_packet имеет настройки у клиента и сервера; клиентские параметры могут отличаться. net_read_timeout действует при приёме от клиента, net_write_timeout — при отправке клиенту. Это не разрешение без ограничений увеличивать лимиты. - Уменьшите стоимость запроса и объём передаваемых данныхВ тестовой версии отчёта сначала возвращайте только необходимые столбцы и ограничивайте период; большие выгрузки делите на устойчивые порции по ключу, например
WHERE id > last_id ORDER BY id LIMIT 1000. Если нужны согласованные данные на весь момент отчёта, отдельный проектный план снимка обязателен: простое разбиение при параллельных изменениях может пропускать или повторять строки. - Сверьте клиентские и внешние тайм-ауты по цепочкеВ клиенте найдите параметры socket/read timeout именно используемого драйвера, а в инфраструктуре — тайм-аут прокси, туннеля или балансировщика. Не путайте
wait_timeout(простой бездействующего соединения) с длительной активной передачей. Изменяйте только доказанно виновный предел после теста и с оценкой нагрузки; настройки можно вернуть к прежнему значению. - Повторите отчёт в тестовой среде и проверьте целостность результатаСравните число и контрольные суммы записей до и после оптимизации; для загрузки в файл убедитесь, что не осталась обрезанная часть от предыдущего сбоя. При повторной ошибке снимите новый журнал, размер ответа, показатель памяти и точку разрыва, затем передайте администратору. Если в журнале есть server has gone away при подключении до запроса, это отдельный сценарий диагностики.
#Команды для диагностики и проверки
SQLКоманда
Набор запросов чтения в клиенте MySQL; параметры показывают значения текущего сервера/сеанса. Не меняет конфигурацию.
SELECT VERSION(), NOW(), CONNECTION_ID();SHOW VARIABLES LIKE 'max_allowed_packet';SHOW VARIABLES LIKE 'net_write_timeout';SHOW VARIABLES LIKE 'net_read_timeout';SQLКоманда
Учебный SELECT: таблица report_events здесь не создаётся, поэтому замените на существующую тестовую таблицу и её поля. EXPLAIN не выполняет обычную выборку, а показывает план.
EXPLAIN SELECT id, created_at FROM report_events WHERE created_at >= '2026-10-01' ORDER BY id LIMIT 1000;#Пример для отдельной тестовой базы или учебного проекта
SQL
Отдельный учебный запрос возвращает строку и число байтов. Он не создаёт тяжёлую нагрузку и помогает отличить объём в байтах от числа символов.
SELECT REPEAT('а', 10) AS sample_text, OCTET_LENGTH(REPEAT('а', 10)) AS bytes;#Проверка результата и дальнейшие действия
Успешное исправление: отчёт завершается в ожидаемое время, число записей совпадает с контрольным подсчётом, сервер не перезапускается и не появляется сообщение о потере соединения. Если вывод в файл неполон, восстановите исходный файл из копии и повторите загрузку только после устранения причины. При воспроизводимом разрыве приложите к заявке время, версию MySQL, EXPLAIN и обезличенные журналы.