Код ошибки: 2013. Потеря соединения с сервером MySQL во время запроса
Я получил код ошибки: 2013. Потеря соединения с сервером MySQL во время ошибки запроса при попытке добавить индекс в таблицу с помощью MySQL Workbench. Я также заметил, что это появляется всякий раз, когда я запускаю длинный запрос.
Можно ли увеличить значение тайм-аута?
38 ответов
Новые версии MySQL WorkBench имеют возможность изменять определенные таймауты.
Для меня это было под Edit → Preferences → SQL Editor → Время ожидания соединения с СУБД (в секундах): 600
Изменено значение до 6000.
Кроме того, непроверенные строки ограничения, поскольку установка предела при каждом поиске по всему набору данных становится утомительной.
Если в вашем запросе есть данные BLOB-объектов, эту проблему можно исправить, применив my.ini изменить как предложено в этом ответе:
[mysqld]
max_allowed_packet=16M
По умолчанию это будет 1M (максимально допустимое значение - 1024M). Если предоставленное значение не кратно 1024K, оно будет автоматически округлено до ближайшего кратного 1024K.
В то время как упомянутый поток связан с ошибкой MySQL 2006, установка max_allowed_packet от 1M до 16M исправил ошибку 2013 года, которая появилась у меня при выполнении длинного запроса.
Для пользователей WAMP: вы найдете флаг в[wampmysqld]раздел.
Запустите сервер БД с параметром командной строки net_read_timeout / wait_timeout и подходящее значение (в секундах) - например: --net_read_timeout=100,
SET @@local.net_read_timeout=360;
Предупреждение: следующее не будет работать, когда вы применяете его в удаленном соединении:
SET @@global.net_read_timeout=360;
Добавьте следующее в файл /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
В моем случае установка интервала тайм-аута соединения на 6000 или что-то большее не сработала.
Я только что сделал то, что говорит верстак.
Максимальное время, в течение которого запрос может вернуть данные из СУБД. Установите 0, чтобы пропустить таймаут чтения.
В настройках Mac -> Редактор SQL -> Перейти к сеансу MySQL -> установите для интервала ожидания чтения значение 0.
И это работает
На основании того, что я понял, эта ошибка была вызвана из-за
read timeoutа также
max allowed packetпо умолчанию 4M. если ваш файл запроса больше 4 Мб, вы получите сообщение об ошибке. это сработало для меня
- изменить тайм-аут чтения. Для изменения перейдите к
Workbench Edit → Preferences → SQL Editor
2. изменить max_allowed_packet вручную, отредактировав файл . для редактирования перейдите в
"C:\ProgramData\MySQL\MySQL Server 8.0\my.ini". Папка
ProgramDataпапка скрыта, поэтому, если вы ее не видели, выберите «Показать скрытый файл» в настройках просмотра. установить
max_allowed_packet = 16Mв
my.iniфайл. 3. Перезапустите MySQL. для перезапуска перейдите к
win+ R -> services.mscи перезапустите MySQL.
Есть три вероятных причины для этого сообщения об ошибке
- Обычно это указывает на проблему с сетевым подключением, и вы должны проверить состояние вашей сети, если эта ошибка возникает часто
- Иногда форма "во время запроса" возникает, когда миллионы строк отправляются как часть одного или нескольких запросов.
- В более редких случаях это может произойти, когда клиент пытается установить исходное соединение с сервером.
Подробнее читайте >>;;
Причина 2:
SET GLOBAL interactive_timeout=60;
по умолчанию от 30 секунд до 60 секунд или дольше
Причина 3:
SET GLOBAL connect_timeout=60;
Вы должны установить свойства 'interactive_timeout' и 'wait_timeout' в файле конфигурации mysql на нужные вам значения.
Спасибо! Это сработало. Но с обновлениями mysqldb конфигурация стала:
max_allowed_packet
net_write_timeout
net_read_timeout
Если вы столкнулись с этой проблемой во время восстановления большого файла дампа и можете исключить проблему, связанную с сетью (например, выполнением на локальном хосте), моё решение может быть полезным.
Мой 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
Просто выполните обновление MySQL, которое перестроит механизм innoDB вместе с перестроением многих таблиц, необходимых для надлежащего функционирования MySQL, таких как performance_schema, information_schema, так далее.
Введите следующую команду из вашей оболочки:
sudo mysql_upgrade -u root -p
Иногда ваш SQL-сервер заходит в тупик, я сталкивался с этой проблемой около 100 раз. Вы можете либо перезагрузить свой компьютер/ноутбук, чтобы перезапустить сервер (простой способ), ИЛИ вы можете перейти в диспетчер задач> службы> ИМЯ ВАШЕГО СЕРВЕРА (для меня это было MySQL785 что-то вроде этого). И щелкните правой кнопкой мыши> перезагрузить. Попробуйте выполнить запрос еще раз.
Я знаю его старый, но на 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 на нужные вам значения.
Если все остальные решения здесь не сработают - проверьте системный журнал (/var/log/syslog или аналогичный), чтобы убедиться, что на вашем сервере не хватает памяти во время запроса.
Возникла эта проблема, когда innodb_buffer_pool_size был установлен слишком близко к физической памяти без настроенного файла подкачки. MySQL рекомендует для сервера базы данных установить параметр innodb_buffer_pool_size на макс. Около 80% физической памяти, у меня он был установлен на уровне около 90%, ядро убивало процесс mysql. Перемещение innodb_buffer_pool_size обратно на 80%, и это решило проблему.
Я получил ту же проблему при загрузке файла.csv. Преобразовал файл в.sql.
Используя приведенную ниже команду, мне удается обойти эту проблему.
mysql -u <user> -p -D <DB name> < file.sql
Надеюсь, это поможет.
Перейдите в Workbench Edit → Preferences → SQL Editor → Время ожидания соединений СУБД: до 3000. Ошибка больше не возникала.
Я столкнулся с этой же проблемой. Я считаю, что это происходит, когда у вас есть внешние ключи для больших таблиц (что занимает много времени).
Я попытался снова запустить оператор create table без объявлений внешнего ключа и обнаружил, что он работает.
Затем после создания таблицы я добавил ограничения внешнего ключа с помощью запроса ALTER TABLE.
Надеюсь, это кому-нибудь поможет.
Идти к:
Правка -> Настройки -> Редактор SQL
Там вы можете увидеть три поля в группе "MySQL Session", где вы можете установить новые интервалы подключения (в секундах).
Это произошло со мной, потому что мой innodb_buffer_pool_size был установлен больше, чем размер оперативной памяти, доступной на сервере. Вещи были прерваны из-за этого, и это выдает эту ошибку. Исправление состоит в том, чтобы обновить my.cnf с правильной настройкой для innodb_buffer_pool_size.
Попробуйте подать заявку.
Случай со мной
Изначально запрос был
SELECT * FROM TABLE1;
Это давало
Error Code: 2013. Lost connection to MySQL server during query
Решение
После применения
SELECT * FROM TABLE1 LIMIT 10;
это сработало. И когда снова попробовал запрос без
LIMIT, это тоже сработало.
Примечание. Если это сработало для вас, и вы выяснили, почему это сработало, оставьте комментарий.
Намасте
Оказывается, наше правило брандмауэра блокировало мое соединение с MYSQL. После того, как политика брандмауэра была отменена, чтобы разрешить соединение, я смог успешно импортировать схему.
Сначала проверьте, есть ли индексы.
SELECT *
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = '<schema>'
У меня было это сообщение об ошибке из-за проблемы после обновления Mysql. Ошибка появилась сразу после того, как я попытался сделать любой запрос
Проверьте файлы журнала ошибок mysql в пути
/var/log/mysql(линукс)
В моем случае у меня сработало переназначение владельца Mysql в системную папку Mysql.
chown -R mysql:mysql /var/lib/mysql
У меня была та же проблема - но для меня решением был пользователь БД со слишком строгими разрешениями. Я должен был позволить Execute способность на mysql Таблица. После того, как я допустил, что у меня больше не было разрывов соединений
Три вещи, которым нужно следовать и убедиться:
- Показывают ли множественные запросы потерянное соединение?
- как вы используете набор запросов в MySQL?
- как удалить + обновить запрос одновременно?
Ответы:
- Всегда пытайтесь удалить определитель, так как MySQL создает свой собственный определитель, и если для обновления задействовано несколько таблиц, попробуйте сделать один запрос, поскольку иногда несколько запросов показывают потерянное соединение
- Всегда устанавливайте значение вверху, но после DELETE, если его условие не включает значение SET.
- Используйте УДАЛИТЬ ПЕРВЫЙ, ЗАТЕМ ОБНОВИТЬ, ЕСЛИ ОБЕ ИХ ОПЕРАЦИИ ВЫПОЛНЯЮТСЯ НА РАЗНЫХ ТАБЛИЦАХ
Использование MySql Server 8.0.28 Community Edition. Более 100 таблиц, созданных в моих схемах. MySql Server работает некорректно и много раз дает сбой. Я нашел проблемы и решения.
Я написал запросы «выберите количество (*) из таблицы1.. таблица100» и запустил их в файле .sql.
Проблема 1: настройка сервера MySql для utf8mb4 и моих таблиц, созданных с помощью utf8.
Решение 1. Вы должны установить свои таблицы и столбцы или воссоздать их с помощью utf8mb4.
Проблема 2: необходимо перенастроить параметр back_log .
Решение 2: установить back_log=50+(coonectioncount/5)
Проблема 3: необходимо перенастроить параметр wait_timeout .
Решение 3. Вы должны установить его 180+ (вы можете попробовать более высокие значения)
Эти действия решили мои проблемы.
Остановите все запущенные приложения, использующие ту же базу данных. Таким образом, верстак все изменит.