Таблица Шредингерса MySQL: существует, но не существует

У меня самая странная ошибка из всех.

Иногда при создании или изменении таблиц я получаю ошибку «таблица уже существует». Однако DROP TABLE возвращает «# 1051 - неизвестная таблица». Итак, у меня есть таблица, которую я не могу создать, не могу отбросить.

Когда я пытаюсь удалить базу данных, происходит сбой mysqld. Иногда помогает создать еще одну базу данных с другим именем, иногда - нет.

Я использую БД с ~ 50 таблицами, все InnoDB. Эта проблема возникает с разными таблицами.

Я испытал это в Windows, Fedora и Ubuntu, MySQL 5.1 и 5.5. Такое же поведение при использовании PDO, PHPMyAdmin или командной строки. Я использую MySQL Workbench для управления своей схемой - я видел некоторые связанные ошибки (конечные строки и прочее), однако ни одна из них не была актуальной для меня.

Нет, это не представление, это таблица. Все имена в нижнем регистре.

Я пробовал все, что мог в Google - стирать таблицы, перемещать файлы .frm из db в db, читать журнал mysql, ничего не помогало, кроме переустановки всей этой чертовой штуки.

«Показать таблицы» ничего не показывает, в «описании» таблицы говорится, что «таблица не существует», файла .frm нет, но «создать таблицу» все равно заканчивается ошибкой (как и «создать таблицу, если не существует») и удаление базы данных приводит к сбою mysql

Связанные, но бесполезные вопросы:

• Ошибка Mysql 1050 «Таблица уже существует», хотя на самом деле ее нет.

• Таблица MySQL не существует, но она существует

Редактировать:

mysql> use askyou;
Database changed

mysql> show tables;
Empty set (0.00 sec)

mysql> create table users_has_friends (id int primary key);
ERROR 1050 (42S01): Table '`askyou`.`users_has_friends`' already exists

mysql> drop table users_has_friends;
ERROR 1051 (42S02): Unknown table 'users_has_friends'

И все такое: таблица не существует, но не может быть создана;

mysql> drop database askyou;
ERROR 2013 (HY000): Lost connection to MySQL server during query

Смена имен, это не единственная таблица / база данных, с которой я столкнулся с проблемами

Я видел эту проблему, когда файл данных отсутствует в каталоге данных, но файл определения таблицы существует, или наоборот. Если вы используете innodb_file_per_table, проверьте каталог данных, чтобы убедиться, что у вас есть как .frmфайл, так и файл .ibd для рассматриваемой таблицы. Если это MYISAM, должны быть файлы .frm, .MYIи .MYD.

Обычно проблему можно решить, удалив потерянный файл вручную.

Пойдем на безумную догадку, но похоже, что innodb все еще имеет запись для ваших таблиц в табличном пространстве, вероятно, в ibdata. Если вам действительно не нужны какие-либо данные или у вас есть резервные копии, попробуйте следующее:

1. Удалить все схемы (кроме mysql)
2. выключить базу данных
3. Убедитесь, что все папки в вашем каталоге данных были правильно удалены (опять же, за исключением mysql)
4. удалить файлы ibdata и журналы
5. перезапустите базу данных. Он должен воссоздать табличное пространство и журналы с нуля.

Исправить это оказалось несложно; по крайней мере, то, что я разработал, работало для меня. Создайте таблицу "zzz" на другом экземпляре MySQL, где zzz - имя таблицы проблемы. (то есть, если таблица называется шредингером, замените это на zzz, где бы оно ни было написано.) Не имеет значения, каково определение таблицы. Это временный манекен; Скопируйте файл zzz.frm в каталог базы данных на сервере, где должна находиться таблица, убедившись, что права собственности на файл и права доступа к нему по-прежнему верны. В MySQL теперь вы можете сделать «показать таблицы;», и таблица zzz будет там. mysql> удалить таблицу zzz; ... теперь должно работать. При необходимости удалите все файлы zzz.MYD или ZZZ.MYI в каталоге.

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

Я часто создаю / удаляю таблицы для некоторых заданий аналитики, которые я запланировал. В какой-то момент я начал получать ошибки таблицы уже существует на полпути к моему сценарию. Обычно проблема решалась перезапуском сервера, но решение было слишком неприятным.

Затем я заметил в локальном файле журнала ошибок эту строку:

[Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive

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

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

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

mysqladmin -uxxxxxx -pyyyyy flush-tables

В моем случае проблема была решена путем передачи права собственности на каталог данных mysql пользователю, запустившему приложение. (В моем случае это было приложение Java, работающее на веб-сервере Jetty.)

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

Если будет эта ошибка 1051, и вы хотите только удалить базу данных и импортировать ее снова, выполните эти шаги, и все будет в порядке ....

в среде Unix как корень :

• rm -rf / var / lib / mysql / ВАША_ДАННАЯБАЗА;
• ДОПОЛНИТЕЛЬНО -> mysql_upgrade --force
• mysqlcheck -uUSER -p ПРОЙДИТЕ ВАШУ_БАЗУ ДАННЫХ
• mysqladmin -uUSER -pPASS удалить ВАШУ_БАЗУ ДАННЫХ
• mysqladmin -uUSER -pPASS создать ВАШУ_БАЗУ ДАННЫХ
• mysql -uUSER -p ПРОЙДИТЕ ВАШУ_БАЗУ ДАННЫХ <ИМПОРТ_ФАЙЛ

С уважением, Кристус

У меня была эта проблема, и я надеялся, что удаление файла IBD поможет, как указано выше, но это не имело значения. MySQL только воссоздал новый файл IBD. В моем случае на самом деле есть похожие таблицы в других базах данных в том же экземпляре MySQL. Поскольку файл FRM отсутствовал, я скопировал файл FRM из аналогичной таблицы в другую базу данных, перезапустил MySQL, и таблица сработала правильно.

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

Это происходит на нашем сайте (но редко), как правило, когда "событие" происходит во время выполнения определенных скриптов, которые выполняют много перестроек. События включают сбои в сети или проблемы с питанием.
Что я делаю для этого в очень редких случаях - я использую деспотичный подход:

• Мне нужно было просто избавиться от конкретной таблицы и перестроить ее. Обычно я считаю, что это нормально, поскольку таблица строится. (Ваша ситуация может быть другой, если вам нужно восстановить данные)
• Как администратор, войдите в установку mysql (в Windows это может быть "... program files / mysql / MySQL Server xx / data / <schemaname>
• Найдите в папке <schemaname> проблемный файл с именем таблицы и удалите его.
• Проверьте наличие потерянных временных файлов и удалите их тоже. # ... frm файлы, если они там есть.
• MySQL позволит вам снова СОЗДАТЬ таблицу

У меня была эта проблема в нескольких разных базах данных в течение длительного времени (лет). Это был тупик из-за противоречивых сообщений. В первый раз я сделал вариант удаления / восстановления / переименования базы данных, как описано в других ответах, и мне удалось наладить работу, но это определенно занимает больше времени. К счастью для меня, это всегда случалось со ссылочными таблицами, которые перестраиваются - DROP'd и CREATEd - обычно утром. Редко получал проблему, но пришел к выводу, что это особый необычный случай. (Я повторю: если вам нужно восстановить данные, посмотрите другие решения.)

• это не таблица, принадлежащая другому пользователю или в другой базе данных
• это не проблема верхнего / нижнего регистра, я использую все строчные буквы, но это была интересная проблема!
• Было очень неприятно видеть ответы с вариациями типа «это определенно было <there / not-there / some-other-user-table-case>, и вы просто делаете это неправильно» :)
• таблица не отображалась в "Показать столы"
• таблица была (всегда была / была) таблицей INNODB.
• попытка DROP таблицы дала сообщение об ошибке, что таблица не существует.
• но попытка СОЗДАТЬ таблицу дала сообщение об ошибке, что таблица уже существует.
• используя mysql 5.0 или 5.1
• РЕМОНТ неэффективен для этой проблемы

У меня была эта проблема с одной конкретной таблицей. Читая возможные решения, я сделал несколько шагов, например:

• Искать сиротские файлы: никого не существовало;
• execute:: show full tables in database;не увидел проблемного;
• выполнить describe table;:: возвращено table doesn't exist;
• выполнить SELECT * FROM information_schema.TABLES WHERE TABLE_NAME='table';:: возвращено Empty set;
• Выполните поиск с помощью phpMyAdmin вручную запроса выше: не существует;

И после этих шагов я снова проверяю с помощью show tables;и ... vualá! проблемная таблица исчезла. Я мог бы создать его и сбросить с тем же проблемным именем без проблем, и мне даже не пришлось перезапускать сервер! Weird ...