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

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

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

4b9b3361

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

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

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

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

300
ответ дан 09 окт. '12 в 1:49
источник

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

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

28
ответ дан 12 мая '12 в 15:17
источник

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

[mysqld]
max_allowed_packet=16M

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

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

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

14
ответ дан 03 июля '14 в 16:36
источник

Добавьте в файл /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
14
ответ дан 17 апр. '15 в 18:11
источник
SET @@local.net_read_timeout=360;

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

SET @@global.net_read_timeout=360;
10
ответ дан 20 апр. '15 в 6:58
источник

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

8
ответ дан 12 мая '12 в 15:19
источник

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

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

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

Причина 2:

SET GLOBAL interactive_timeout=60;

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

Причина 3:

SET GLOBAL connect_timeout=60;
8
ответ дан 08 дек. '16 в 9:30
источник

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

max_allowed_packet

net_write_timeout

net_read_timeout

mysql doc

8
ответ дан 07 апр. '15 в 6:48
источник

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

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

sudo mysql_upgrade -u root -p
7
ответ дан 19 мая '14 в 23:16
источник

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

4
ответ дан 21 апр. '16 в 12:25
источник

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

1. Control-click your connection and choose Connection Properties.
2. Under Advanced tab, set the Socket Timeout (sec) to a larger value.
3
ответ дан 27 марта '15 в 9:53
источник

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

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

3
ответ дан 08 янв. '16 в 14:07
источник

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

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

3
ответ дан 24 июля '14 в 12:59
источник

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

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

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

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

2
ответ дан 08 сент. '16 в 9:19
источник

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

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

1
ответ дан 05 янв. '17 в 21:46
источник

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

1
ответ дан 26 февр. '17 в 18:35
источник

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

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

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

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

1
ответ дан 23 дек. '16 в 10:22
источник

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

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

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

0
ответ дан 20 дек. '17 в 0:19
источник

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

0
ответ дан 01 сент. '18 в 5:50
источник

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

0
ответ дан 31 авг. '17 в 20:35
источник

Перейдите к:

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

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

0
ответ дан 05 мая '17 в 16:23
источник

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

0
ответ дан 11 мая '17 в 18:38
источник

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

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

0
ответ дан 25 июня '18 в 11:21
источник

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

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

-1
ответ дан 03 авг. '16 в 13:34
источник

проверить

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

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

-1
ответ дан 21 июля '16 в 7:30
источник