Подтвердить что ты не робот

Таблица Schrödingers MySQL: существует, но она не

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

Иногда при создании или изменении таблиц я получаю ошибку "table already exists". Однако DROP TABLE возвращает "# 1051 - неизвестная таблица". Поэтому я получил таблицу, которую я не могу создать, не могу отказаться.

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

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

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

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

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

"Показать таблицы" ничего не показывает, "описать" таблицу говорит, что "таблица не существует", нет файла .frm, но "создать таблицу" по-прежнему заканчивается ошибкой (и поэтому "создает таблицу, если она не существует" ') и сброс базы данных сбой mysql

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

Edit:

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

mysqladmin -uxxxxxx -pyyyyy flush-tables

Ответ 7

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

в Unix envoriment AS root:

  • rm -rf/var/lib/mysql/YOUR_DATABASE;
  • ДОПОЛНИТЕЛЬНО → mysql_upgrade --force
  • mysqlcheck -uUSER -pPASS YOUR_DATABASE
  • mysqladmin -uUSER -pPASS drop YOUR_DATABASE
  • mysqladmin -uUSER -pPASS создать YOUR_DATABASE
  • mysql -uUSER -pPASS YOUR_DATABASE < IMPORT_FILE

С уважением, Christus

Ответ 8

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

Ответ 9

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

Ответ 10

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

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

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

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

Ответ 11

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

  • Поиск сиротских файлов: никого не было;
  • выполнить: 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...

Ответ 12

Эта проблема также может быть решена с помощью

DROP TABLE IF EXISTS `tablename` ;
FLUSH TABLES `tablename` ; /* or exclude `tablename` to flush all tables */
CREATE TABLE `tablename` ...