Schrödingers MySQL-Tabelle: existiert, existiert aber nicht

Ich habe den seltsamsten Fehler von allen.

Manchmal wird beim Erstellen oder Ändern von Tabellen der Fehler "Tabelle existiert bereits" angezeigt. DROP TABLE gibt jedoch '# 1051 - unbekannte Tabelle' zurück. Also habe ich eine Tabelle, die ich nicht erstellen und nicht löschen kann.

Wenn ich versuche, die Datenbank zu löschen, stürzt mysqld ab. Manchmal hilft es, eine andere Datenbank mit einem anderen Namen zu erstellen, manchmal nicht.

Ich benutze eine DB mit ~ 50 Tabellen, alle InnoDB. Dieses Problem tritt bei verschiedenen Tabellen auf.

Ich habe dies unter Windows, Fedora und Ubuntu, MySQL 5.1 und 5.5 erlebt. Gleiches Verhalten bei Verwendung von PDO, PHPMyAdmin oder der Befehlszeile. Ich verwende MySQL Workbench, um mein Schema zu verwalten. Ich habe einige verwandte Fehler (Endlinien und ähnliches) gesehen, aber keiner von ihnen war für mich relevant.

Nein, es ist keine Ansicht, es ist eine Tabelle. Alle Namen sind Kleinbuchstaben.

Ich habe alles versucht, was ich googeln konnte - Tabellen leeren, .frm-Dateien von Datenbank zu Datenbank verschieben, MySQL-Protokoll lesen, nichts half, als das ganze verdammte Ding neu zu installieren.

'Tabellen anzeigen' enthüllt nichts, 'beschreiben' Tabelle sagt 'Tabelle existiert nicht', es gibt keine .frm-Datei, dennoch 'Tabelle erstellen' endet immer noch mit einem Fehler (und 'Tabelle erstellen, wenn nicht vorhanden') und Das Löschen der Datenbank stürzt in MySQL ab

Verwandte, aber nicht hilfreiche Fragen:

• MySQL 1050 Fehler "Tabelle existiert bereits", obwohl dies nicht der Fall ist

• MySQL-Tabelle existiert nicht Fehler, aber es existiert

Bearbeiten:

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'

Und so, egal: Tabelle existiert nicht, kann aber nicht erstellt werden;

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

Namen ändern sich, dies ist nicht die einzige Tabelle / Datenbank, mit der ich Probleme habe

Ich habe dieses Problem gesehen, wenn die Datendatei im Datenverzeichnis fehlt, die Tabellendefinitionsdatei jedoch vorhanden ist oder umgekehrt. Wenn Sie innodb_file_per_table verwenden, überprüfen Sie das Datenverzeichnis, um sicherzustellen, dass Sie sowohl eine .frmDatei als auch eine .ibd-Datei für die betreffende Tabelle haben. Wenn es MYISAM ist, sollte es eine sein .frm, .MYIund eine .MYDDatei.

Das Problem kann normalerweise durch manuelles Löschen der verwaisten Datei behoben werden.

Ich gehe hier wild raten, aber es scheint, als hätte innodb immer noch einen Eintrag für Ihre Tabellen in einem Tablespace, wahrscheinlich in ibdata. Wenn Sie wirklich brauchen nicht jede der Daten, oder wenn Sie Sicherungen haben, versuchen Sie Folgendes:

1. Löschen Sie alle Schemas (außer MySQL).
2. Fahren Sie die Datenbank herunter
3. Stellen Sie sicher, dass alle Ordner in Ihrem Datenverzeichnis ordnungsgemäß entfernt wurden (wieder ausgenommen MySQL).
4. Löschen Sie ibdata und Protokolldateien
5. Starten Sie die Datenbank neu. Der Tabellenbereich und die Protokolle sollten von Grund auf neu erstellt werden.

Die Lösung stellt sich als einfach heraus; Zumindest was ich ausgearbeitet habe, hat für mich funktioniert. Erstellen Sie eine Tabelle "zzz" auf einer anderen MySQL-Instanz, wobei zzz der Name der Problemtabelle ist. (Wenn die Tabelle als Schrödinger bezeichnet wird, ersetzen Sie zzz durch das, was auch immer geschrieben wurde.) Es spielt keine Rolle, wie die Definition der Tabelle lautet. Es ist eine vorübergehende Attrappe; Kopieren Sie die Datei zzz.frm in das Datenbankverzeichnis auf dem Server, auf dem sich die Tabelle befinden soll, und stellen Sie sicher, dass der Dateieigentum und die Berechtigungen für die Datei weiterhin korrekt sind. Unter MySQL können Sie jetzt "show tables;" ausführen, und die Tabelle zzz wird dort angezeigt. mysql> drop table zzz; ... sollte jetzt funktionieren. Löschen Sie gegebenenfalls alle zzz.MYD- oder ZZZ.MYI-Dateien im Verzeichnis.

Ich bezweifle, dass dies hier eine direkte Antwort auf den Fragenfall ist, aber hier ist, wie ich dieses genau wahrgenommene Problem auf meinem OS X Lion-System gelöst habe .

Ich erstelle / lösche häufig Tabellen für einige von mir geplante Analysejobs. Irgendwann habe ich angefangen, bereits vorhandene Fehler in der Mitte meines Skripts abzurufen. Ein Neustart des Servers löste normalerweise das Problem, aber das war für eine Lösung zu ärgerlich.

Dann bemerkte ich in der lokalen Fehlerprotokolldatei diese bestimmte Zeile:

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

Dies brachte mich auf die Idee, dass MySQL, wenn meine Tabellen Großbuchstaben enthielten, zu dem Gedanken verleitet würde, dass sie auch nach dem Löschen noch vorhanden sind. Dies stellte sich als der Fall heraus und die Umstellung auf die Verwendung von Kleinbuchstaben für Tabellennamen ließ das Problem verschwinden.

Es ist wahrscheinlich das Ergebnis einer Fehlkonfiguration in meinem Fall, aber hoffentlich hilft dieser Fehlerfall jemandem, weniger Zeit damit zu verschwenden, nach einer Lösung zu suchen.

Dies ist eine alte Frage, aber ich habe nur das gleiche Problem festgestellt, und eine Antwort auf eines der oben verlinkten Probleme war genau das, was ich brauchte, und weitaus weniger drastisch als das Löschen von Dateien, Tabellen, das Herunterfahren des Servers usw.

mysqladmin -uxxxxxx -pyyyyy flush-tables

In meinem Fall wurde das Problem gelöst, indem der Besitz des MySQL-Datenverzeichnisses auf den Benutzer geändert wurde, der die Anwendung ausgeführt hat. (In meinem Fall war es eine Java-Anwendung, auf der Jetty Webserver ausgeführt wird.)

Obwohl MySQL ausgeführt wurde und andere Apps es ordnungsgemäß verwenden konnten, hatte diese App ein Problem damit. Nachdem Sie den Besitz des Datenverzeichnisses geändert und das Kennwort des Benutzers zurückgesetzt hatten, funktionierte alles ordnungsgemäß.

Wenn dieser Fehler 1051 vorrätig ist und Sie nur die Datenbank löschen und erneut importieren möchten, führen Sie diese Schritte aus, und alles wird gut.

in Unix Envoriment AS root :

• 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 erstelle YOUR_DATABASE
• mysql -uUSER -pPASS YOUR_DATABASE <IMPORT_FILE

Grüße, Christus

Ich hatte dieses Problem und hoffte, dass das Löschen der IBD-Datei wie oben beschrieben helfen würde, aber es machte keinen Unterschied. MySQL hat nur eine neue IBD-Datei neu erstellt. In meinem Fall gibt es tatsächlich ähnliche Tabellen in anderen Datenbanken in derselben MySQL-Instanz. Da die FRM-Datei fehlte, habe ich die FRM-Datei aus der ähnlichen Tabelle in eine andere Datenbank kopiert, MySQL neu gestartet und die Tabelle hat ordnungsgemäß funktioniert.

Ich bin auf diesen Fehler gestoßen, nachdem ich eine Tabelle erstellt und gelöscht hatte und sie dann erneut erstellen wollte. In meinem Fall hatte ich eine in sich geschlossene Dump-Datei, also habe ich mein Schema gelöscht, es neu erstellt und Tabellen und Daten mithilfe der Dump-Datei importiert.

Es passiert auf unserer Site (aber selten) normalerweise, wenn ein "Ereignis" auftritt, während bestimmte Skripte ausgeführt werden, die viel neu erstellen. Zu den Ereignissen gehören Netzwerkausfälle oder Stromprobleme.
Was ich in den sehr seltenen Fällen dafür tue - ich benutze den hartnäckigen Ansatz:

• Ich musste einfach die bestimmte Tabelle loswerden und neu erstellen. Ich bin normalerweise in der Lage, dass dies in Ordnung ist, da die Tabelle erstellt wird. (Ihre Situation kann anders sein, wenn Sie Daten wiederherstellen müssen)
• Gehen Sie als Administrator in die MySQL-Installation (unter Windows kann es sich um "... Programme / MySQL / MySQL Server xx / data / <Schemaname>" handeln
• Suchen Sie die fehlerhafte Datei mit dem Tabellennamen im Ordner <schemaname> - und löschen Sie sie.
• Suchen Sie nach verwaisten temporären Dateien und löschen Sie diese ebenfalls. # ... frm Dateien, wenn sie dort sind.
• Mit MySQL können Sie die Tabelle erneut erstellen

Ich hatte dieses Problem über lange Zeit (Jahre) in einigen verschiedenen Datenbanken. Es war ein Stumper wegen der widersprüchlichen Botschaften. Das erste Mal habe ich eine Variation der Datenbank zum Löschen / Wiederherstellen / Umbenennen durchgeführt, wie in den anderen Antworten beschrieben, und es geschafft, die Dinge in Gang zu bringen, aber es dauert definitiv länger. Zum Glück ist es immer passiert, dass Referenztabellen - DROP'd und CREATEd - normalerweise morgens neu erstellt werden. Ich habe das Problem selten bekommen, habe es aber als einen besonderen, eigenartigen Fall erkannt. (Ich werde noch einmal wiederholen: Wenn Sie die Daten wiederherstellen müssen, schauen Sie sich die anderen Lösungen an.)

• Es ist keine Tabelle, die einem anderen Benutzer oder einer anderen Datenbank gehört
• Es ist nicht das Problem der Groß- / Kleinschreibung, ich verwende alle Kleinbuchstaben, aber das war ein interessantes Problem!
• Es war besonders frustrierend, Antworten mit Variationen von "Es war definitiv <da / nicht da / irgendein anderer Benutzertabellenfall> zu sehen und du machst es einfach nicht richtig" zu sehen :)
• Die Tabelle wurde nicht auf "Tabellen anzeigen" angezeigt.
• Die Tabelle war (war / war immer) eine INNODB-Tabelle.
• Beim Versuch, die Tabelle zu TROPFEN, wurde die Fehlermeldung ausgegeben, dass die Tabelle nicht vorhanden ist.
• Beim Versuch, die Tabelle zu erstellen, wurde jedoch die Fehlermeldung angezeigt, dass die Tabelle bereits vorhanden ist.
• mit mysql 5.0 oder 5.1
• REPARATUR ist für dieses Problem unwirksam

Ich hatte dieses Problem mit einem bestimmten Tisch. Beim Lesen der möglichen Lösungen habe ich einige Schritte ausgeführt wie:

• Suche nach verwaisten Dateien: existierte niemand;
• execute :: show full tables in database;hat das Problem nicht gesehen;
• execute :: describe table;return table doesn't exist;
• execute :: SELECT * FROM information_schema.TABLES WHERE TABLE_NAME='table';return Empty set;
• Suchen Sie mit dem phpMyAdmin manuell die obige Abfrage: nicht vorhanden;

Und nach diesen Schritten überprüfe ich noch einmal mit dem show tables;und ... vualá! Der problematische Tisch war weg. Ich konnte es ohne Probleme mit demselben problematischen Namen erstellen und löschen, und ich musste nicht einmal den Server neu starten! Seltsam...