Код ошибки: 2013. Потеря соединения с сервером MySQL во время запроса

Я получил код ошибки: 2013. Потеря соединения с сервером MySQL во время ошибки запроса, когда я пытался добавить индекс в таблицу с помощью MySQL Workbench. Я также заметил, что это появляется всякий раз, когда я запускаю длинный запрос.

Можно ли увеличить значение тайм-аута?

Новые версии MySQL WorkBench имеют возможность изменять определенные таймауты.

Для меня это было под Редактировать → Настройки → Редактор SQL → Время ожидания соединения с СУБД (в секундах): 600

Изменено значение до 6000.

Также непроверенные строки предела, поскольку установка предела в каждый раз, когда я хочу искать весь набор данных, становится утомительной.

Запуск сервера БД с опцией comandline net_read_timeout/ wait_timeoutи подходящего значения (в секундах) - например: --net_read_timeout=100.

Для справки смотрите здесь и здесь .

Если ваш запрос содержит данные BLOB-объектов, эту проблему можно исправить, применив my.iniизменение, предложенное в этом ответе :

[mysqld]
max_allowed_packet=16M

По умолчанию это будет 1M (максимально допустимое значение 1024M). Если предоставленное значение не кратно 1024K, оно будет автоматически округлено до ближайшего кратного 1024K.

В то время как ссылки нить об ошибке MySQL 2006 , устанавливая max_allowed_packetот 1М до 16М сделал исправление ошибки 2013 , который показал на меня , когда работает длинный запрос.

Для пользователей WAMP: вы найдете флаг в [wampmysqld]разделе.

Добавьте следующее в файл / etc / mysql / cnf:

innodb_buffer_pool_size = 64M

пример:

key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
innodb_buffer_pool_size = 64M

SET @@local.net_read_timeout=360;

Предупреждение: следующее не будет работать, когда вы применяете его в удаленном соединении:

SET @@global.net_read_timeout=360;

Есть три вероятных причины для этого сообщения об ошибке

1. Обычно это указывает на проблему с сетевым подключением, и вы должны проверить состояние вашей сети, если эта ошибка возникает часто
2. Иногда форма «во время запроса» возникает, когда миллионы строк отправляются как часть одного или нескольких запросов.
3. В более редких случаях это может произойти, когда клиент пытается установить исходное соединение с сервером.

Подробнее читайте >>

Причина 2:

SET GLOBAL interactive_timeout=60;

по умолчанию от 30 секунд до 60 секунд или дольше

Причина 3:

SET GLOBAL connect_timeout=60;

Спасибо! Это сработало. Но с обновлениями mysqldb конфигурация стала:

max_allowed_packet

net_write_timeout

net_read_timeout

MySQL док

Вы должны установить свойства 'interactive_timeout' и 'wait_timeout' в файле конфигурации mysql на нужные вам значения.

Просто выполните обновление MySQL, которое перестроит механизм innoDB вместе с перестроением многих таблиц, необходимых для правильного функционирования MySQL, таких как performance_schema, information_schemaи т. Д.

Введите следующую команду из вашей оболочки:

sudo mysql_upgrade -u root -p

Я знаю его старый, но на Mac

1. Control-click your connection and choose Connection Properties.
2. Under Advanced tab, set the Socket Timeout (sec) to a larger value.

Измените время ожидания чтения в Edit-> Preferences-> SQL editor-> MySQL session

Попробуйте снять отметки с ограниченных строк в меню «Правка» → «Настройки» → «SQL-запросы».

потому что вы должны установить свойства 'interactive_timeout' и 'wait_timeout' в файле конфигурации mysql на нужные вам значения.

Если вы столкнулись с этой проблемой во время восстановления большого файла дампа и можете исключить проблему, связанную с сетью (например, выполнением на локальном хосте), моё решение может быть полезным.

Мой mysqldump содержал по крайней мере одну INSERT, которая была слишком большой для mysql, чтобы вычислить. Вы можете просмотреть эту переменную, набрав show variables like "net_buffer_length";внутри вашего mysql-cli. У вас есть три возможности:

• увеличить net_buffer_length внутри mysql -> это потребует перезагрузки сервера
• создать дамп с --skip-extended-insert, для каждой вставки используется одна строка -> хотя эти дампы намного приятнее читать, это не подходит для больших дампов> 1 ГБ, потому что это имеет тенденцию быть очень медленным
• создать дамп с расширенными вставками (который используется по умолчанию), но ограничить net-buffer_length, например, --net-buffer_length NR_OF_BYTESгде NR_OF_BYTES меньше, чем net_buffer_length сервера -> Я думаю, что это лучшее решение, хотя медленнее перезапуск сервера не требуется.

Я использовал следующую команду mysqldump: mysqldump --skip-comments --set-charset --default-character-set=utf8 --single-transaction --net-buffer_length 4096 DBX > dumpfile

Я получил ту же проблему при загрузке файла .csv. Преобразовал файл в .sql.

Используя приведенную ниже команду, мне удается обойти эту проблему.

mysql -u <user> -p -D <DB name> < file.sql

Надеюсь, это поможет.

Если все остальные решения здесь не сработают - проверьте системный журнал (/ var / log / syslog или аналогичный), чтобы убедиться, что во время запроса серверу не хватает памяти.

Возникла эта проблема, когда innodb_buffer_pool_size был установлен слишком близко к физической памяти без настроенного файла подкачки. MySQL рекомендует для сервера базы данных установить параметр innodb_buffer_pool_size на макс. Около 80% физической памяти , у меня он был установлен на уровне около 90%, ядро ​​убивало процесс mysql. Перемещение innodb_buffer_pool_size обратно на 80%, и это решило проблему.

В моем случае установка интервала ожидания соединения до 6000 или выше не работала.

Я просто сделал то, что говорит верстак, что я могу сделать.

Максимальный период времени, в течение которого запрос может вернуть данные из СУБД. Установите 0, чтобы пропустить тайм-аут чтения.

В настройках Mac -> Редактор SQL -> Перейти в MySQL Session -> установить интервал ожидания чтения соединения равным 0.

И это работает 😄

Я столкнулся с этой же проблемой. Я считаю, что это происходит, когда у вас есть внешние ключи для больших таблиц (что занимает много времени).

Я попытался снова запустить оператор create table без объявлений внешнего ключа и обнаружил, что он работает.

Затем после создания таблицы я добавил ограничения внешнего ключа с помощью запроса ALTER TABLE.

Надеюсь, это кому-нибудь поможет.

Это случилось со мной, потому что мой innodb_buffer_pool_size был установлен больше размера оперативной памяти, доступной на сервере. Вещи были прерваны из-за этого, и это выдает эту ошибку. Исправление состоит в том, чтобы обновить my.cnf с правильной настройкой для innodb_buffer_pool_size.

Перейдите в Workbench Edit → Preferences → SQL Editor → Время ожидания соединений СУБД: до 3000. Ошибка больше не возникала.

Перейти к:

Правка -> Настройки -> Редактор SQL

Там вы можете увидеть три поля в группе «MySQL Session», где теперь вы можете установить новые интервалы подключения (в секундах).

Оказывается, наше правило брандмауэра блокировало мое соединение с MYSQL. После того, как политика брандмауэра была отменена, чтобы разрешить соединение, я смог успешно импортировать схему.

У меня была та же проблема - но для меня решением был пользователь БД со слишком строгими разрешениями. Я должен был позволить Executeспособность на mysqlстоле. После того, как я позволил, у меня больше не было сбрасываемых соединений.

Сначала проверьте, есть ли индексы .

SELECT *
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = '<schema>'

Я столкнулся с этим во время выполнения хранимого процесса, который создавал много строк в таблицу в базе данных. Я мог видеть, что ошибка появилась сразу после того, как время пересекло 30-секундную границу.

Я перепробовал все предложения в других ответах. Я уверен, что кое-что из этого помогло, однако, что действительно заставило меня работать, так это переключение на SequelPro из Workbench.

Я предполагаю, что это было какое-то соединение на стороне клиента, которое я не смог обнаружить в Workbench. Может быть, это поможет кому-то еще?

Если вы используете SQL Work Bench, вы можете попробовать использовать индексирование, добавив индекс в ваши таблицы, чтобы добавить индекс, щелкните по значку гаечного ключа (гаечного ключа) в таблице, он должен открыть настройки для таблицы ниже. щелкните представление индекса, введите имя индекса и установите тип индекса. В столбцах индекса выберите основной столбец в своей таблице.

Сделайте тот же шаг для других первичных ключей на других таблицах.

Кажется, здесь нет ответа для тех, кто использует SSH для подключения к своей базе данных MySQL. Вам нужно проверить два места, а не 1, как предлагают другие ответы:

Редактирование рабочей среды → Настройки → Редактор SQL → СУБД

Рабочее место Правка → Настройки → SSH → Тайм-ауты

Мои тайм-ауты SSH по умолчанию были установлены очень низкими и вызывали некоторые (но, очевидно, не все) мои проблемы тайм-аута. После, не забудьте перезапустить MySQL Workbench!

Наконец, возможно, стоит обратиться к администратору БД и попросить его увеличить свойства wait_timeout и interactive_timeout в самом mysql через my.conf + mysql restart или сделать глобальный набор, если перезапуск mysql не является опцией.

Надеюсь это поможет!

Три вещи, которым нужно следовать и убедитесь:

1. Многократные запросы показывают потерянное соединение?
2. как вы используете set query в MySQL?
3. как удалить + обновить запрос одновременно?

ответы:

1. Всегда пытайтесь удалить определитель, поскольку MySQL создает свой собственный определитель, и если несколько таблиц, задействованных для обновления, пытаются сделать один запрос, так как иногда несколько запросов показывают потерянное соединение
2. Всегда устанавливайте значение сверху, но после УДАЛИТЬ, если его условие не включает значение SET.
3. Используйте УДАЛИТЬ ПЕРВЫЕ, ТОГДА ОБНОВЛЕНИЯ, ЕСЛИ ОБА ИХ ОПЕРАЦИИ ВЫПОЛНЕНЫ НА РАЗНЫХ СТОЛБАХ

проверить о

OOM on /var/log/messages ,
modify innodb_buffer_pool_size value ; when load data , use 50% of os mem ; 

Надеюсь это поможет

Обычно это означает, что у вас есть «несовместимости с текущей версией MySQL Server», см. Mysql_upgrade. Я столкнулся с той же самой проблемой и просто должен был бежать:

mysql_upgrade --password В документации говорится, что «mysql_upgrade должен выполняться при каждом обновлении MySQL».