Ответ 1

Я бы попробовал:

• Резервное копирование/сохранение любых баз данных, имеющих важные данные.
• Удалить mySQL
• Переустановите mySQL
• Восстановить все резервные базы данных.

Ответ 2

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

UPDATE: вам нужно пойти в каталог базы данных MySQL и выполнить ls -la, чтобы убедиться, что злая БД такая же, как и остальные, в отношении разрешений, прав собственности и т.д., Например, здесь "исходную" базу данных нельзя отбросить (она была создана тупым инструментом, запущенным как root):

drwx------  2 mysql mysql      4096 Aug 27  2015 _db_graph
drwx------  2 mysql mysql      4096 Jul 13 11:58 _db_xatex
drwxrw-rw-  2 root  root      12288 May 18 14:27 _db_xatex_original
drwx------  2 mysql mysql     12288 Jun  9 08:23 _db_xatex_contab
drwx------  2 mysql mysql     12288 May 18 17:58 _db_xatex_copy
drwx------  2 mysql mysql      4096 Nov 24  2016 _db_xatex_test

Запуск chown mysql:mysql _db_xatex_original; chmod 700 _db_xatex_original устранит проблему (но проверьте внутри каталог, чтобы убедиться, что там тоже разрешений, а владельцы коаксиально).

В конце концов, я применил следующий уродливый взломать (после попытки остановки, перезапуска и восстановления того, что может быть нацелено на REPAIR):

• создал базу данных "козла отпущения"
• остановил сервер MySQL
• скопировал каталог, созданный MySQL Server,/var/lib/mysql/scapegoat, в /tmp
• перезапустил сервер MySQL, удалил базу данных "козлом отпущения", остановил сервер
• Теперь у меня была копия чистого, пустого DB файла, о котором MySQL больше ничего не знал.
• переместил каталог "evildb" в /tmp (чтобы, если что-то пошло не так, я мог бы вернуть его обратно)
• переместил каталог "scapegoat" в /var/lib/mysql, переименовав его в "evildb"
• запустил сервер MySQL
• Не уверен, что в этот момент я исправил еще какой-нибудь ремонт.
• и база данных "evildb" стала недоступной!

Мое объяснение заключается в том, что при обращении к базе данных MySQL Server сначала выполняет некоторые проверки файлов в каталоге базы данных. Если эти проверки не выполняются, падение также не выполняется. Эти проверки должны быть существенно отличны от тех, которые выполняются с помощью REPAIR. Возможно, в поврежденном каталоге есть что-то неожиданное.

Я думаю, что это было на MySQL 5.1 или 5.2 на дистрибутиве SuSE 11.2 Linux. Надеюсь, что это поможет.

UPDATE

Подумав, я не помню, чтобы получать ошибки о "proc". Поэтому я не уверен, что проблема заключается в каталоге. Он может быть связан с таблицей proc без повреждения таблицы. Пробовали ли вы визуально проверять таблицу базы данных proc, чтобы найти что-то там, которое принадлежит злой БД?

USE mysql;
SELECT * FROM proc;

Это или любые ошибки из этого могут помочь в решении проблемы. Вы можете, кто знает, иметь несколько строк с неправильным столбцом db. В крайнем случае вы можете экспортировать таблицу proc и перезагрузить ее после очистки (через SQL или через файл на диске).

TEST

У меня есть частичная проверка для вышеупомянутого обновления. Умышленно вставляя мусор в таблицу proc по сравнению с недавно созданной базой данных evil, я частично воспроизводит ваши симптомы (неразрушаемая база данных, сбой при соединении MySQL при попытке). Номер ошибки не равен 1548; но, возможно, это было бы, если бы я вставил правильный мусор в эту таблицу... в любом случае полезный бит состоит в том, что удалив все ссылки на evil db, последний снова стал недоступен:

mysql> drop database evil;
ERROR 2013 (HY000): Lost connection to MySQL server during query
mysql> use mysql;
No connection. Trying to reconnect...
Connection id:    1
Current database: *** NONE ***

Database changed
mysql> DELETE FROM proc WHERE db = 'evil';
Query OK, 2 rows affected (0.00 sec)

mysql> drop database evil;
Query OK, 0 rows affected (0.00 sec)

Ответ 3

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

• Посмотрите все процессы MySQL: mysqladmin processlist -u root -p

2. Убейте все процессы, связанные с caloriecalculator, поскольку это блокирует выполнение моих следующих запросов. mysqladmin -u root -p kill 4

3. Теперь запустите: drop caloriecalculator базы данных;

Ответ 4

Если вы используете XAMPP в Windows

Вы также можете удалить свою базу данных вручную

перейдите в xampp → mysql → data → [имя базы данных]

удалите свое [имя базы данных] сейчас.

Ответ 5

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