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

Question

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

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

Answer 1

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

Для меня это было под Edit → Preferences → SQL Editor → подключение DBMS чтения тайм-аут (в секундах): 600

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

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

Answer 2

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

Для справки см. here и here.

Answer 3

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

Answer 4

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

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

sudo mysql_upgrade -u root -p 

Answer 5

Если запрос содержит данные большие двоичные объекты, эта проблема может быть решена применением my.ini изменений as proposed in this answer:

[mysqld] 
max_allowed_packet=16M 

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

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

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

Answer 6

Постарайся, пожалуйста, чтобы снять лимит строк в меню Правка → Настройки → SQL запросы

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

Answer 7

Я знаю, что его старый, но на макинтош

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

Answer 8

Спасибо! Это работало. Но обновляет MySQLdb Настроить уже стал:

max_allowed_packet

net_write_timeout

net_read_timeout

mysql doc

Answer 9

Добавьте следующее в/и т.д./кнф файл MySQL /:

innodb_buffer_pool_size = 64M 

пример:

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

Answer 10

SET @@local.net_read_timeout=360; 

Внимание: Ниже не будет работать, если вы подаете его в удаленном соединении:

SET @@global.net_read_timeout=360; 

Answer 11

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

В моем 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

Answer 12

Change "время зачитано" время в Edit-> Настройки-> SQL editor-> MySQL сессии

Answer 13

проверки о

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

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

Answer 14

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

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

Answer 15

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

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

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

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

Answer 16

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

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

For more detail read >>

Причина 2:

SET GLOBAL interactive_timeout=60; 

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

Причина 3:

SET GLOBAL connect_timeout=60; 

Answer 17

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

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

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

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

Answer 18

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

Если эта проблема возникла, когда innodb_buffer_pool_size был установлен слишком близко к физической памяти без конфигурации swap. MySQL recommends for a database specific server setting innodb_buffer_pool_size at a max of around 80% of physical memory, я установил его около 90%, ядро ​​убило процесс mysql. Перемещенный innodb_buffer_pool_size возвращается примерно до 80%, и это устраняет проблему.

Answer 19

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

Answer 20

Перейти к:

Edit -> Preferences -> Редактор SQL

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

Answer 21

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

Answer 22

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

Answer 23

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

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

Answer 24

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

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

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