Ошибка mysql в файле engine classes mysql php в строке 59
Обновлено: 04.07.2024
Я установил путь к классам, убедился, что my.cnf отключил опцию пропускной сети.
версия java - 1.2.0_26 (64 бит) mysql 5.5.14 Разъем mysql 5.1.17
Я убедился, что пользователь имеет доступ к моей базе данных.
ОТВЕТЫ
Ответ 1
У меня была такая же проблема в двух моих программах. Моя ошибка:
Я провел несколько дней, чтобы решить эту проблему. Я проверил множество подходов, которые были упомянуты на разных веб-сайтах, но не работали. Наконец, я изменил свой код и выяснил, в чем проблема. Я попытаюсь рассказать вам о разных подходах и суммировать их здесь.
Пока я искал интернет, чтобы найти решение этой ошибки, я понял, что существует множество решений, которые работали хотя бы для одного человека, но другие говорят, что он не работает для них! почему существует много подходов к этой ошибке? Кажется, что эта ошибка может возникать в общем случае при возникновении проблемы при подключении к серверу. Возможно, проблема связана с неправильной строкой запроса или слишком большим количеством подключений к базе данных.
Поэтому я предлагаю вам попробовать все решения по одному и не сдаваться!
Вот решения, которые я нашел в Интернете и для каждого из них, по крайней мере, у человека, который решил проблему с этим решением.
Совет. Для решений, которые необходимо изменить параметры MySQL, вы можете обратиться к следующим файлам:
Linux:/etc/mysql/my.cnf или /etc/my.cnf(в зависимости от дистрибутива Linux и используемого пакета MySQL)
Windows: C: ** ProgramData **\MySQL\MySQL Server 5.6\my.ini(обратите внимание на ProgramData, а не на программные файлы)
- изменение атрибута "привязка-адрес"
Исключить атрибут "связывать-адрес" или изменить его на один из следующих IP-адресов:
- комментирование "skip-networking"
- изменить "wait_timeout" и "interactive_timeout"
Добавьте эти строки в конфигурационный файл MySQL:
- Убедитесь, что Java не переводит 'localhost' в [: 1] вместо [127.0.0.1]
Так как MySQL распознает 127.0.0.1 (IPv4), но не: 1 (IPv6)
Этого можно избежать, используя один из двух подходов:
Вариант №1: В строке подключения используйте 127.0.0.1 вместо localhost, чтобы избежать перевода локального хоста в: 1
- проверить настройки прокси-сервера операционной системы, брандмауэры и антивирусные программы
Убедитесь, что брандмауэр или антивирусное программное обеспечение не блокируют службу MySQL.
Остановить iptables временно на linux. Если iptables неправильно сконфигурированы, они могут разрешать отправку пакетов tcp в порт mysql, но блокировать tcp-пакеты от возврата в том же соединении.
Остановите антивирусное программное обеспечение в Windows.
Проверьте строку запроса. ваша строка подключения должна быть примерно такой:
Убедитесь, что в строке нет пробелов. Вся строка соединения должна продолжаться без каких-либо пробелов.
Попробуйте заменить "localhost" на адрес loopback 127.0.0.1. Также попробуйте добавить номер порта в строку подключения, например:
Обычно порт по умолчанию для MySQL - 3306.
Не забудьте изменить имя пользователя и пароль на имя пользователя и пароль вашего сервера MySQL.
- обновить файл библиотеки драйверов JDK
- проверить разные JDK и JRE (например, JDK 6 и 7)
- не изменять max_allowed_packet
" max_allowed_packet" - это переменная в конфигурационном файле MySQL, которая указывает максимальный размер пакета, а не максимальное количество пакетов. Поэтому это не поможет решить эту ошибку.
изменить TOMCAT6_SECURITY = да на TOMCAT6_SECURITY = нет
- использовать свойство validationQuery
используйте validationQuery = "select now()", чтобы убедиться, что у каждого запроса есть ответы
Добавьте этот код в строку подключения:
Хотя эти решения не работали, я предлагаю вам попробовать их. Потому что есть некоторые люди, которые решили свою проблему, выполнив следующие шаги.
Но что решило мою проблему?
Моя проблема заключалась в том, что у меня было много SELECT в базе данных. Каждый раз, когда я создавал соединение, а затем закрывал его. Хотя я закрывал соединение каждый раз, но система столкнулась со многими подключениями и дала мне эту ошибку. Я сделал то, что я определил свою переменную подключения как общедоступную (или приватную) переменную для всего класса и инициализировал ее в конструкторе. Затем каждый раз, когда я просто использовал это соединение. Это решило мою проблему, а также резко увеличило мою скорость.
Нет простого и уникального способа решения этой проблемы. Я предлагаю вам подумать о своей собственной ситуации и выбрать выше решения. Если вы берете эту ошибку в начале программы, и вы вообще не можете подключиться к базе данных, у вас может возникнуть проблема в вашей строке подключения. Но если вы предпримете эту ошибку после нескольких успешных взаимодействий с базой данных, проблема может быть связана с количеством подключений, и вы можете подумать об изменении "wait_timeout" и других параметров MySQL или переписать код, чтобы уменьшить количество подключений.
Ответ 2
Если вы используете MAMP PRO, это простое исправление, которое я действительно хотел бы реализовать, прежде чем я начал искать интернет в течение нескольких дней, пытаясь понять это. Это действительно так просто.
Вам нужно просто щелкнуть "Разрешить доступ к сети MySQL" на вкладке MAMP MySQL.
Действительно, вот оно.
Ответ 3
Настройка bind-address на сетевой IP-адрес сервера вместо localhost по умолчанию, и для меня работают настройки прав для моего пользователя.
Ответ 4
Как говорится в подробном ответе выше, эта ошибка может быть вызвана многими вещами.
У меня тоже была эта проблема. Моя настройка была Mac OSX 10.8, с использованием виртуальной виртуальной машины Vagrant от Ubuntu 12.04 с MySQL 5.5.34.
Я правильно настроил переадресацию портов в файле конфигурации Vagrant. Я мог бы использовать telnet для экземпляра MySQL как с моего Mac, так и из VM. Поэтому я знал, что демон MySQL работает и доступен. Но когда я пытался подключиться через JDBC, я получил ошибку "Ошибка связи".
Ответ 5
В моем случае это был тайм-аут простоя, из-за которого соединение было отключено на сервере. Соединение поддерживалось открытым, но не использовалось в течение длительного периода времени. Затем перезапускается клиентский перезапуск, в то время как я считаю, что повторное подключение также будет работать.
Неплохое решение состоит в том, чтобы время/время было подключаться к демону/службе.
Ответ 6
Я столкнулся с той же проблемой. Это произошло потому, что MySQL Daemon был привязан к IP-адресу машины, что требуется для установления связи с пользователем, у которого есть разрешение на подключение @your_machine. В этом случае у пользователя должно быть разрешение на подключение USER_NAME @MACHINE_NAME_OR_IP
Мне нужен удаленный доступ к моей машине, поэтому я изменил его в my.cnf из
Это позволит пользователю с localhost И даже снаружи (в моем случае) подключиться к экземпляру. Обе ниже разрешения будут работать, если вы привяжете MySQL к 0.0.0.0:
Ответ 7
На удаленном компьютере измените права пользователя mysql с помощью GRANT ALL PRIVILEGES ON *.* TO 'user'@'%' IDENTIFIED BY 'password';
ВАЖНО: перезапустите mysql на удаленном компьютере: sudo /etc/init.d/mysql restart
Ответ 8
Для меня решение заключалось в том, чтобы изменить в файле conf mysql server параметр bind-address = "127.0.0.1" или bind-address = "x.x.x.x" на bind-address = "0.0.0.0". Спасибо.
Ответ 9
Если у вас возникла проблема с набором контейнеров Docker, убедитесь, что вы не только EXPOSE порт 3306 , но также сопоставляете порт со стороны контейнера -p 3306:3306 . Для docker-compose.yml :
Ответ 10
Это случается (в моем случае), когда для MySQL недостаточно памяти. Перезапуск исправляет его, но если этот случай рассматривает nachine с большим объемом памяти или ограничивает память, полученную jvms
Ответ 11
Перейдите в службы Windows на панели управления и запустите службу MySQL. Для меня это сработало. Когда я выполнял проект Java EE, я получил эту ошибку "Ошибка связи". Я перезапустил свою систему, а потом сработал.
После этого я снова получил ту же ошибку даже после перезагрузки моей системы. Затем я попытался открыть консоль командной строки MySQL и войти в систему с помощью root, даже тогда это дало мне ошибку.
Наконец, когда я запустил службу MySQL из служб Windows, она сработала.
Ответ 12
Было то же самое. Удаление порта помогло в моем случае, поэтому я оставил его как jdbc: mysql://localhost/
Ответ 13
Если вы используете спящий режим, эта ошибка может быть вызвана тем, что для открытия объекта сеанса больше времени, чем wait_timeout
Я зарегистрировал случай в здесь для тех, кто заинтересован.
Ответ 14
Я нашел решение
поскольку MySQL нужен для работы в Localhost.
перейдите в файл /etc/network/interfaces и убедитесь, что у вас установлена локальная конфигурация:
СЕЙЧАС RESTART подсистему Networking и службы MySQL:
Ответ 15
Это в основном из-за слабой связи между клиентом mysql и удаленным сервером mysql.
В моем случае это из-за flaky VPN-соединения.
Ответ 16
В опции драйвера phpstorm + vagrant autoReconnect помогли.
Ответ 17
Решение, предоставленное Soheil, было успешным в моем случае.
Чтобы уточнить, единственное изменение, которое мне нужно было сделать, это конфигурация сервера MySQL;
Я использую внешний MySQL-сервер для своего приложения. Это базовая установка Debian 7.5 с MySQL Server 5.5 - настройка по умолчанию.
Всегда создавать резервные копии файлов конфигурации, которые вы можете изменить. Всегда будьте осторожны, когда вы становитесь суперпользователем.
Перезапустите службу MySQL Server:
Как вы можете видеть, я просто предоставил сетевой IP-адрес сервера и закомментировал запись по умолчанию. Обратите внимание, что просто скопировать и вставить мое решение не сработает для вас, если только каким-то чудом наши хосты не будут иметь один и тот же IP-адрес.
Ответ 18
У меня возникла аналогичная проблема, и решение для моего случая было
- change bind-address = 0.0.0.0 от 127.0.0.1
- изменение url localhost на localhost: 3306
вещь, которую я чувствовал, мы никогда не должны сдаваться, я пробовал все варианты с этой должности и с других форумов, а также. happy it works @saurab
Ответ 19
Я тоже столкнулся с этой проблемой.
Как предложил Сохейл, Я отправился в файл php.ini по пути C:\windows\php.ini, затем я пересмотрел номер порта в этом файле.
он находится в строке mysqli.default_port =.
Итак, я изменил его в своем приложении java, как и в файле php.ini, теперь он отлично работает со мной.
Ответ 20
Я знаю, что это старый поток, но я пробовал много вещей и исправил свою проблему, используя следующие средства.
Я разрабатываю кросс-платформенное приложение для Windows, но для использования на серверах Linux и Windows.
База данных MySQL, называемая "jtm", установлена в обеих системах. По какой-то причине в моем коде у меня было имя базы данных как "JTM". В Windows это работало нормально, ведь на нескольких системах Windows он летал.
В Ubuntu я снова и снова получал ошибку. Я проверил его с правильным кодом в коде "jtm", и он работает.
Linux, очевидно, намного менее прощает вопрос чувствительности к регистру (справедливо), тогда как Windows делает скидку.
Ответ 21
У меня была такая же проблема на MacOS (10.10.2) и MySql (5.6.21), установленном через homebrew.
Сбивчивая вещь заключалась в том, что одно из моих приложений прекрасно подключилось к базе данных, а другое - нет.
Причиной моей проблемы могло быть следующее, как было предложено в ответе в вышеупомянутой ссылке:
Используете ли вы пул соединений? Если да, попробуйте перезапустить сервер. Вероятно, несколько соединений в вашем пуле соединений находятся в закрытом состоянии.
Ответ 22
Для Windows: - Откройте меню "Пуск", напишите "Мастер настройки экземпляра MySqlserver" и перенастройте экземпляр сервера mysql. Надеюсь, что это решит вашу проблему.
Ответ 23
После нескольких лет, имеющих такую же проблему и без постоянного решения, это то, что разрешило ее в течение последних 3 недель (что является записью с точки зрения безошибочной работы).
установить глобальный wait_timeout = 3600;
установить global interactive_timeout = 230400;
Не забудьте сделать это постоянным, если оно работает для вас.
Ответ 24
В моем случае (я noob), я тестировал Servlet, делающий подключение к базе данных с MySQL, и одно из исключений - это упомянутое выше.
Это заставило мою голову качаться несколько секунд, но я понял, что это потому, что я не запустил свой сервер MySQL в localhost .
После запуска сервера проблема была исправлена.
Итак, проверьте, правильно ли работает сервер MySQL.
Ответ 25
Если вы используете локальный эмулятор, вам нужно использовать IP-адрес 10.0.2.2 вместо localhost для доступа к локальному серверу MySQL.
Здравствуйте! Ошибка в следующем, при попытки оставить коммент или зарегистрироватся на сайте, сайт подвисает на 5-10 сек после чего выскакивает ошибка:
MySQL error in file: /engine/modules/addcomments.php at line 83
Error Number: 2006
The Error returned was:
MySQL server has gone away
SQL query:
MySQL error in file: /engine/modules/register.php at line 135
Error Number: 2006
The Error returned was:
MySQL server has gone away
SQL query:
INSERT INTO dle_spam_log (ip, is_spammer, date) VALUES ('91.188.158.114','0', '1494816981')
Посмотрите лог ошибок MySQL. В нем должна быть причина падения сервера.
Есть ли свободное место на диске?
170514 20:32:02 InnoDB: Waiting for the background threads to start
170514 20:32:03 InnoDB: 5.5.56 started; log sequence number 2259226
170514 20:32:03 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
170514 20:32:03 [Note] - '0.0.0.0' resolves to '0.0.0.0';
170514 20:32:03 [Note] Server socket created on IP: '0.0.0.0'.
170514 20:32:06 [Note] Event Scheduler: Loaded 0 events
170514 20:32:06 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.56' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL) by Remi
170514 20:58:42 [Note] Plugin 'FEDERATED' is disabled.
170514 20:58:43 InnoDB: The InnoDB memory heap is disabled
170514 20:58:43 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170514 20:58:43 InnoDB: Compressed tables use zlib 1.2.3
170514 20:58:43 InnoDB: Using Linux native AIO
170514 20:58:44 InnoDB: Initializing buffer pool, size = 128.0M
170514 20:58:44 InnoDB: Completed initialization of buffer pool
170514 20:58:44 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
170514 20:58:44 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files.
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer.
170514 20:58:52 InnoDB: Waiting for the background threads to start
170514 20:58:53 InnoDB: 5.5.56 started; log sequence number 2259226
170514 20:58:53 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
170514 20:58:53 [Note] - '0.0.0.0' resolves to '0.0.0.0';
170514 20:58:53 [Note] Server socket created on IP: '0.0.0.0'.
170514 20:58:56 [Note] Event Scheduler: Loaded 0 events
170514 20:58:56 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.56' socket: '/var/lib/mysql/mysql.sock' port: 3306 MySQL Community Server (GPL) by Remi
Всегда ли вставка в таблицу dle_spam_log приводит к крэшу? Сделайте
CHECK TABLE dle_spam_log;
В начале этого года состоялся релиз новой 8 ветки сервера баз данных MySQL. Нумерация была измененена в связи с новыми принципами версионирования MySQL и, по факту, новый выпуск представляет собой версию 5.8.
Среди целого набора новшеств, включённых в новый выпуск, некоторые из них повлияли на обратную совместимость с кодом, использующим MySQL для хранения своих данных.
Ввиду того, что всем рано или поздно придётся развёртывать новые системы или переносить данные со старых установок, автор на своём примере решил осуществить миграцию с предыдущей версии MySQL 5.7 на новый 8 выпуск. С предварительными результатами о замеченными измненениями, оказавшимися критичными для работы прикладного программного обеспечения, а также путями их решения, вас ознакомит эта статья.
Итак, вы решили использовать MySQL 8. Опустим здесь сам процесс установки или обновления предыдущей инсталляции — в целом они стандартны и практически не отличаются от процедур применяемых ранее.
В распоряжении автора была последняя доступная на момент написания статьи версия MySQL 8 развёрнутая в среде FreeBSD 11.2.
Прикладной софт, который работает с сервером баз данных, написан на PHP и также использует последнюю версию.
Впрочем, выводы и решения приведённые далее, также применим и к любому другому клиентскому (отношению к серверу баз данных) коду.
Первым же отмеченным отличием MySQL 8 стало изменение схемы аутентификации по умолчанию. Вместо привычной mysql_native_password её место заняла новая caching_sha2_password в качестве Preferred Authentication Plugin, которая декларируется как более безопасная и надёжая альтернатива старой схемы.
Попытка использования аутентификации неподдерживающим новый тип софтом приводит к появлению соответствующих ошибок.
Однако, в настоящее время все стандартные драйверы PHP, к примеру, популярный PDO, за исключением девелоперского расширения mysql_xdevapi её не поддерживают. Реализация новой схемы ожидается в выпуске PHP 7.3.
В этой связи, рекомендуется предпринять ряд действий для обеспечения работы текущих версий софта. Первым может стать измнение схемы аутентификации по умолчанию на её традиционный вариант в файле конфигурации MySQL my.cnf путём добавления в секцию [mysqld] соответветствующего параметра.
Далее, если вы уже добавили пользователей с новой схемой аутентификации, а, по меньшей мере один из них — root, точно был добавлен на этапе инсталляции, то следует изменить им схему на традиционный вариант.
Вторым моментом, с которым некоторым придётся столкнуться, это появление ключевых и зарезервированных слов, которые нельзя использовать без экранирования знаком ` (backtick или знак акцента).
Их актуальный список можно получить непосредственно из базы со схемой данных MySQL information_schema.
В случае, если в SQL-коде в наименовании таблиц и/или полей встретится неэкранированное слово из данного списка, это приведёт к ошибке.
В данном случае, было использовано зарезервированное слово groups.
Безусловно, экранирование имён полей и таблиц при помощи ` является хорошим тоном оформления кода для MySQL. Однако, проблема возникает тогда, когда тот же SQL-код предполагается использовать и для обращения к другим серверам баз данных, к примеру, PostgreSQL. Использование символа ` является нестандартным и исключительной особенностью MySQL и её форков, поэтому написание и адаптация такого универсального кода под иные серверы может представлять некоторые трудности. Пожалуй, оптимальным в данном случае вариантом будет избегать использовать зарезервированных слов в SQL-коде, а если вы их уже используете, то, вероятно, следует озаботиться изменением наименований для обеспечения совместимости с будущими версиями.
Другим вариантом может быть разрешение использования двойных кавычек ", которые являются стандартным для SQL решением, в MySQL для экранирования имён таблиц и полей. Это реализуется через добавление в режимы работы sql_modes значения ANSI_QUOTES. Это можно сделать путём подачи SQL команды
и для постоянной установки этого режима добавить соответствующую строку к набору режимов в конфигурационном файле my.cnf
Ещё одним сюрпризом может стать отсутствие в MySQL 8 встроенного механизма кэширования запросов query cache, который широко использовался в предыдущих версиях. Данная функция уже довольно давно значилась как deprecated и вот, наконец, момент настал.
Среди основных причин называется его низкая эффективность из-за чересчур прямолинейных алгоритмов работы, которые, к тому же, затрудняют работу предсказательных механизмов кэширования InnoDB.
В случае, если вы уверены в необходимости кэширования запросов, то вам следует рассмотреть использование сторонних SQL-прокси с кэшированием, к примеру ProxySQL обладающим в разы более высокой эффективностью и настраиваемостью.
Миграция на новые версии программного обеспечения всегда имеет риски потери совместимости. Адаптация старого софта под новые требования процесс нормальный, стандартный, и требующий отдельного внимания для избежания возможных проблем в обозримой перспективе.
В этой связи, надеюсь, данная статья будет полезна всем разработчикам и системных администраторам в качестве подготовки к повсеместному внедрению MySQL 8.
Если вы заметили неточности или проблемы в процессе аналогичного обновления, прошу добавлять ваши мнения в комментарии ниже.
MySQL — система управления базами данных (СУБД) с открытым исходным кодом от компании Oracle. Она была разработана и оптимизирована специально для работы веб-приложений. MySQL является неотъемлемой частью таких веб-сервисов, как Facebook, Twitter, Wikipedia, YouTube и многих других.
Эта статья расскажет, как определять, с чем связаны частые ошибки на сервере MySQL, и устранять их.
Не удаётся подключиться к локальному серверу
Одной из распространённых ошибок подключения клиента к серверу является «ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)».
Эта ошибка означает, что на хосте не запущен сервер MySQL ( mysqld ) или вы указали неправильное имя файла сокета Unix или порт TCP/IP при попытке подключения.
Убедитесь, что сервер работает. Проверьте процесс с именем mysqld на хосте сервера, используя команды ps или grep, как показано ниже.
Если эти команды не показывают выходных данных, то сервер БД не работает. Поэтому клиент не может подключиться к нему. Чтобы запустить сервер, выполните команду systemctl.
Чтобы проверить состояние службы MySQL, используйте следующую команду:
Если в результате выполнения команды произошла ошибка службы MySQL, вы можете попробовать перезапустить службу и ещё раз проверить её состояние.
Если сервер работает (как показано) и вы по-прежнему видите эту ошибку, вам следует проверить, не заблокирован ли порт TCP/IP брандмауэром или любой другой службой блокировки портов.
Белкасофт , Удалённо , По итогам собеседования
Для поиска порта, который прослушивается сервером, используйте команду netstat .
Не удаётся подключиться к серверу MySQL
Ещё одна похожая и часто встречающаяся ошибка подключения — «(2003) Can’t connect to MySQL server on ‘server’ (10061)». Это означает, что в сетевом соединении было отказано.
Следует проверить, работает ли в системе сервер MySQL (смотрите выше) и на тот ли порт вы подключаетесь (как найти порт, можно посмотреть выше).
Похожие частые ошибки, с которыми вы можете столкнуться при попытке подключиться к серверу MySQL:
Ошибки запрета доступа в MySQL
В MySQL учётная запись (УЗ) определяется именем пользователя и клиентским хостом, с которого пользователь может подключиться. УЗ может также иметь данные для аутентификации (например, пароль).
Причин для запрета доступа может быть много. Одна из них связана с учётными записями MySQL, которые сервер разрешает использовать клиентским программам при подключении. Это означает, что имя пользователя, указанное в соединении, может не иметь прав доступа к базе данных.
В MySQL есть возможность создавать учётные записи, позволяющие пользователям клиентских программ подключаться к серверу и получать доступ к данным. Поэтому при ошибке доступа проверьте разрешение УЗ на подключение к серверу через клиентскую программу.
В консоли вводим команду:
Дать привилегии конкретному пользователю в БД по IP-адресу можно, используя следующие команды:
Ошибки запрещённого доступа могут также возникнуть из-за проблем с подключением к MySQL (см. выше).
Потеря соединения с сервером MySQL
С этой ошибкой можно столкнуться по одной из следующих причин:
- плохое сетевое соединение;
- истекло время ожидания соединения;
- размер BLOB больше, чем max_allowed_packet .
В первом случае убедитесь, что у вас стабильное сетевое подключение (особенно, если подключаетесь удалённо).
Если проблема с тайм-аутом соединения (особенно при первоначальном соединении MySQL с сервером), увеличьте значение параметра connect_timeout .
В случае с размером BLOB нужно установить более высокое значение для max_allowed_packet в файле конфигурации /etc/my.cnf в разделах [mysqld] или [client] как показано ниже.
Если файл конфигурации недоступен, это значение можно установить с помощью следующей команды.
Слишком много подключений
Эта ошибка означает, что все доступные соединения используются клиентскими программами. Количество соединений (по умолчанию 151) контролируется системной переменной max_connections . Устранить проблему можно, увеличив значение переменной в файле конфигурации /etc/my.cnf .
Недостаточно памяти
Если такая ошибка возникла, это может означать, что в MySQL недостаточно памяти для хранения всего результата запроса.
Сначала нужно убедиться, что запрос правильный. Если это так, то нужно выполнить одно из следующих действий:
- если клиент MySQL используется напрямую, запустите его с ключом --quick switch , чтобы отключить кешированные результаты;
- если вы используете драйвер MyODBC, пользовательский интерфейс (UI) имеет расширенную вкладку с опциями. Отметьте галочкой «Do not cache result» (не кешировать результат).
Также может помочь MySQL Tuner. Это полезный скрипт, который подключается к работающему серверу MySQL и даёт рекомендации по настройке для более высокой производительности.
MySQL продолжает «падать»
Если такая проблема возникает, необходимо выяснить, заключается она в сервере или в клиенте. Обратите внимание, что многие сбои сервера вызваны повреждёнными файлами данных или индексными файлами.
Вы можете проверить состояние сервера, чтобы определить, как долго он работал.
Чтобы узнать время безотказной работы сервера, запустите команду mysqladmin .
Кроме того, можно остановить сервер, сделать отладку MySQL и снова запустить службу. Для отображения статистики процессов MySQL во время выполнения других процессов откройте окно командной строки и введите следующее:
Заключение
Самое важное при диагностике — понять, что именно вызвало ошибку. Следующие шаги помогут вам в этом:
Читайте также: