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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

[mysqld]
max_allowed_packet=16M

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

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

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

Ответ 4

Добавьте в файл /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

Ответ 5

SET @@local.net_read_timeout=360;

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

SET @@global.net_read_timeout=360;

Ответ 6

Для этого сообщения об ошибке есть три причины

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

Для более подробной информации >>

Причина 2:

SET GLOBAL interactive_timeout=60;

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

Причина 3:

SET GLOBAL connect_timeout=60;

Ответ 7

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

Ответ 8

Спасибо, это сработало. Но с обновлениями mysqldb настройка стала:

max_allowed_packet

net_write_timeout

net_read_timeout

mysql doc

Ответ 9

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

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

sudo mysql_upgrade -u root -p

Ответ 10

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

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

Ответ 11

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

Ответ 12

Попробуйте снять флажки с ограничениями строк в разделе "Редактировать" → "Настройки" → "Запросы SQL"

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

Ответ 13

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

Мой 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

Ответ 14

У меня возникла такая же проблема при загрузке CSV файла. Преобразовал файл в .sql.

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

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

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

Ответ 15

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

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

Ответ 16

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

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

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

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

Ответ 17

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

Ответ 18

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

Ответ 19

Перейдите к:

Изменить → Настройки → Редактор SQL

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

Ответ 20

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

Ответ 21

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

Ответ 22

Проверьте, установлены ли индексы.

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

Ответ 23

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

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

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

Ответ 24

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

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

Ответ 25

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

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

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

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

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

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

Ответ 26

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

Если несколько запросов показывают потерянное соединение?
как вы используете набор запросов в MySQL?
как удалить + обновить запрос одновременно?

Ответы:

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

Ответ 27

проверить

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

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

Ответ 28

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

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