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

116

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

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

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

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

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

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

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

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

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

Mysql 1050 Error "Table already exists" when in fact, it does not

MySQL Table does not exist error, but it does exist

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

<code>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'
</code>

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

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

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

Можете ли вы открыть клиент MySQL и ввести несколько команд, демонстрирующих проблему, а затем скопировать и вставитьexact Копия команд и вывод здесь. Хорошо, что вы описали свою проблему во многих деталях, но было бы еще лучше, если бы вы отправляли точные команды и сообщения. Mark Byers
Вы используете innodb_file_per_table? ESG
какое у вас имя таблицы? sblom
Что вы получаете в ответ наSHOW FULL TABLES IN askyou а такжеSELECT * FROM information_schema.TABLES WHERE TABLE_SCHEMA LIKE 'askyou'? eggyal
@RafaelBarros: Совершенно верно. Опечатка. Спасибо за разъяснения. eggyal

Ваш Ответ

12   ответов
0

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

  • I needed to simply get rid-of-and-rebuild the particular table. I'm usually in a position that this is OK since the table is being built. (Your situation may be different if you need to recover data)
  • As an admin, go into the mysql installation (on windows its may be "...program files/mysql/MySQL Server xx/data/<schemaname>
  • Find the offending file with the table name in the <schemaname> folder - and delete it.
  • Check for orphaned temporary files and delete them too. #...frm files if they happen to be there.
  • MySQL will let you CREATE the table again

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

  • it isn't a table belonging to another user, or in another database
  • it isn't the upper/lower case issue, I use all lower-case, but that was an interesting issue!
  • it was extra extra frustrating seeing responses with variations of "it definitely was <there/not-there/some-other-user-table-case> and you're just not doing it right" :)
  • the table didn't show on "show tables"
  • the table was (always was/had been) an INNODB table.
  • trying to DROP the table gave the error message that the table doesn't exist.
  • but trying to CREATE the table gave the error message that the table already exists.
  • using mysql 5.0 or 5.1
  • REPAIR is ineffective for this problem
-1

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

  • Search for orphan files: didn't exist anyone;
  • execute: show full tables in database;: didn't see the problematic one;
  • execute: describe table;: returned table doesn't exist;
  • execute: SELECT * FROM information_schema.TABLES WHERE TABLE_NAME='table';: returned Empty set;
  • Search by the phpMyAdmin manually the query above: didn't exist;

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

3

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

mysqladmin -uxxxxxx -pyyyyy flush-tables
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
18

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

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

Error: User Rate Limit Exceededinnodb_file_per_tableError: User Rate Limit Exceeded.ibdError: User Rate Limit Exceeded.frmError: User Rate Limit Exceeded Corkscreewe
Error: User Rate Limit Exceeded
-3

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

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

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

в Unix envoriment ASroot:

  • rm -rf /var/lib/mysql/YOUR_DATABASE;
  • OPTIONAL -> mysql_upgrade --force
  • mysqlcheck -uUSER -pPASS YOUR_DATABASE
  • mysqladmin -uUSER -pPASS drop YOUR_DATABASE
  • mysqladmin -uUSER -pPASS create YOUR_DATABASE
  • mysql -uUSER -pPASS YOUR_DATABASE < IMPORT_FILE

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

0

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

1

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

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

3

Я сомневаюсь, что это прямой ответ на вопрос здесь, но вот как я решилthis exact perceived problem на моей системе OS X Lion.

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

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

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

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

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

3

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

Error: User Rate Limit Exceeded
13

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

  1. Delete all schemas (excluding mysql)
  2. shut down the database
  3. Make sure that all folders in your data directory have been removed properly (again, excluding mysql)
  4. delete ibdata and log files
  5. restart the database. It should recreate the tablespace and logs from scratch.
Error: User Rate Limit Exceeded
0

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

Похожие вопросы