MySQL> Tabelle existiert nicht. Aber es tut (oder sollte)

Ich habe den Datenverzeichnis einer MySQL-Installation geändert und alle Basen bis auf eine wurden korrekt verschoben. Ich kann mich verbinden und USEdie Datenbank. SHOW TABLESAußerdem werden mir alle Tabellen korrekt zurückgegeben, und die Dateien jeder Tabelle befinden sich im MySQL-Datenverzeichnis.

Wenn ich jedoch versuche, SELECTetwas aus der Tabelle zu entfernen, wird die Fehlermeldung angezeigt, dass die Tabelle nicht vorhanden ist. Dies ist jedoch nicht sinnvoll, da ich dieselbe Tabelle durch SHOW TABLESAussage anzeigen konnte.

Ich vermute, dass SHOW TABLESdie Existenz von Dateien aufgelistet wird, aber nicht überprüft wird, ob eine Datei beschädigt ist oder nicht. Folglich kann ich diese Dateien auflisten, aber nicht darauf zugreifen.

Trotzdem ist es nur eine Vermutung. Ich habe das noch nie gesehen. Jetzt kann ich die Datenbank nicht zum Testen neu starten, aber jede andere Anwendung, die sie verwendet, läuft einwandfrei. Aber das ist nur eine Vermutung, das habe ich noch nie gesehen.

Weiß jemand, warum das passiert?

Beispiel:

mysql> SHOW TABLES;
+-----------------------+
| Tables_in_database    |
+-----------------------+
| TABLE_ONE             |
| TABLE_TWO             |
| TABLE_THREE           |
+-----------------------+
mysql> SELECT * FROM TABLE_ONE;
ERROR 1146 (42S02): Table 'database.TABLE_ONE' doesn't exist

Nur für den Fall, dass sich noch jemand darum kümmert:

Ich hatte das gleiche Problem, nachdem ich ein Datenbankverzeichnis direkt mit dem Befehl kopiert hatte

cp -r /path/to/my/database /var/lib/mysql/new_database

Wenn Sie dies mit einer Datenbank tun, die InnoDBTabellen verwendet, wird der oben erwähnte verrückte Fehler "Tabelle existiert nicht" angezeigt.

Das Problem ist , dass Sie die Notwendigkeit , ib*Dateien in der Wurzel des MySQL datadir (zB ibdata1, ib_logfile0und ib_logfile1).

Als ich diese kopierte, funktionierte es für mich.

Unter Mac OS (MySQL DMG-Installation) löste ein einfacher Neustart des MySQL-Servers das Problem. Ich vermute, der Winterschlaf hat ihn verursacht.

Ich erhalte dieses Problem, wenn der Fall für den von mir verwendeten Tabellennamen deaktiviert ist. Die Tabelle heißt also 'db', aber ich habe 'DB' in der select-Anweisung verwendet. Stellen Sie sicher, dass der Fall der gleiche ist.

Dieser Fehler kann auftreten , auch bei der Einstellung lower_case_table_nameszu 1, und dann den Zugriff auf Tabellen versuchen , die für diese Variable mit dem Standardwert erstellt wurden. In diesem Fall können Sie den vorherigen Wert wiederherstellen und die Tabelle lesen.

1. hör auf mysqld
2. Backup-MySQL-Ordner: cp -a /var/lib/mysql /var/lib/mysql-backup
3. Kopieren Sie den Datenbankordner vom alten Computer auf /var/lib/mysql
4. Überschreiben Sie ib * (ib_logfile *, ibdata) aus der alten Datenbank
5. starte mysqld
6. Dump-Datenbank
7. mysqldump >dbase.mysql
8. Stoppen Sie den MySQL-Dienst
9. entfernen /var/lib/mysql
10. umbenennen /var/lib/mysql-backupin/var/lib/mysql
11. starte mysqld
12. Erstellen Sie die Datenbank
13. mysqldump < dbase.mysql

Bitte führen Sie die Abfrage aus:

SELECT 
    i.TABLE_NAME AS table_name, 
    LENGTH(i.TABLE_NAME) AS table_name_length,
    IF(i.TABLE_NAME RLIKE '^[A-Za-z0-9_]+$','YES','NO') AS table_name_is_ascii
FROM
    information_schema.`TABLES` i
WHERE
    i.TABLE_SCHEMA = 'database'

Leider erlaubt MySQL die Verwendung von Unicode- und nicht druckbaren Zeichen im Tabellennamen. Wenn Sie Ihre Tabellen durch Kopieren von Erstellungscode aus einem Dokument / einer Website erstellt haben, besteht die Möglichkeit, dass irgendwo ein Platz mit einer Breite von Null vorhanden ist.

Ich habe gerade drei Tage mit diesem Albtraum verbracht. Idealerweise sollten Sie ein Backup haben, das Sie wiederherstellen können, und dann einfach die beschädigte Tabelle löschen. Diese Art von Fehler kann dazu führen , dass ibdata1 wachsen riesigen (für bescheidene Tabellen 100GB + groß)

Wenn Sie keine aktuelle Sicherung haben, z. B. wenn Sie sich auf mySqlDump verlassen haben, sind Ihre Sicherungen wahrscheinlich irgendwann in der Vergangenheit stillschweigend unterbrochen worden. Sie müssen die Datenbanken exportieren, was Sie natürlich nicht tun können, da beim Ausführen von mySqlDump Sperrfehler auftreten.

/var/log/mysql/database_name/Um dieses Problem zu umgehen , gehen Sie zu und entfernen Sie den Tabellennamen. *

Versuchen Sie dann sofort, den Tisch zu entleeren. Dies sollte jetzt funktionieren. Stellen Sie nun die Datenbank in einer neuen Datenbank wieder her und erstellen Sie die fehlenden Tabellen neu. Dann sichern Sie die kaputte Datenbank.

In unserem Fall erhielten wir auch ständig mysql has gone awayNachrichten in zufälligen Intervallen in allen Datenbanken; Sobald die beschädigte Datenbank entfernt wurde, wurde alles wieder normal.

Ich kenne den Grund nicht, aber in meinem Fall habe ich nur das Deaktivieren und Aktivieren der Fremdschlüsselprüfung gelöst

SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;

Ich hatte das gleiche Problem und suchte 2-3 Tage, aber die Lösung für mich war wirklich dumm.

Starten Sie die MySQL neu

$ sudo service mysql restart

Jetzt werden Tabellen zugänglich.

Ok, das wird ziemlich absurd klingen, aber humor mich.
Für mich wurde das Problem gelöst, als ich meine Aussage in folgende änderte:

SELECT * FROM `table`

Ich habe zwei Änderungen vorgenommen
1.) Den Tabellennamen in Kleinbuchstaben geschrieben - ich weiß !!
2.) Verwendete das spezifische Anführungszeichen = ` : Es ist der Schlüssel über Ihrer TAB

Die Lösung klingt absurd, aber es hat funktioniert und es ist Samstagabend und ich arbeite seit 9 Uhr morgens - also nehme ich es :)

Viel Glück.

Ich hatte dieses Problem nach dem Upgrade von WAMP, hatte aber keine Datenbanksicherung.

Das hat bei mir funktioniert:

1. Stoppen Sie den neuen WAMP

2. Kopieren Sie die benötigten Datenbankverzeichnisse und die Datei ibdata1 aus der alten WAMP-Installation

3. Löschen ib_logfile0undib_logfile1

4. Starten Sie WAMP

Sie sollten jetzt in der Lage sein, Backups Ihrer Datenbanken zu erstellen. Nach dem Neustart Ihres Servers treten jedoch weiterhin Probleme auf. Installieren Sie nun WAMP neu und importieren Sie Ihre Datenbanken.

Versuchen Sie, eine SQL-Abfrage auszuführen, um den Tablespace zu verwerfen, bevor Sie die IDB-Datei kopieren:

ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

IDB-Datei kopieren

ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

Starten Sie MySql neu

Nach der Neuinstallation von MySQL hatte ich das gleiche Problem. Es scheint, dass während der Installation einige Konfigurationsdateien, in denen Daten zu den InnoDB-Protokolldateien gespeichert sind, diese Dateien ib_logfile * (es handelt sich um Protokolldateien, oder?) Überschrieben werden. Um dieses Problem zu lösen, habe ich gerade die Dateien ib_logfile * gelöscht.

Was für mich funktionierte, war nur den Tisch fallen zu lassen, obwohl er nicht existierte. Dann habe ich die Tabelle neu erstellt und aus einem zuvor erstellten SQL-Dump neu gefüllt.

Es muss eine Metabasis von Tabellennamen geben, und sie war höchstwahrscheinlich noch vorhanden, bis ich sie fallen ließ.

Hatte ein ähnliches Problem mit einem Geistertisch. Zum Glück hatte ein SQL-Dump vor dem Fehler.

In meinem Fall musste ich:

1. Stoppen Sie mySQL
2. Verschieben Sie ib * -Dateien von /var/mysql off in ein Backup
3. Löschen /var/mysql/{dbname}
4. Starten Sie mySQL neu
5. Leere Datenbank neu erstellen
6. Dump-Datei wiederherstellen

HINWEIS: Erfordert eine Dump-Datei.

1. Mache mysqldump zur Datenbank:

   mysqldump -u user -ppass dbname > D:\Back-ups\dbname.sql

2. Datenbank wiederherstellen

   mysql -u user -ppass dbname < D:\Back-ups\dbname.sql

Jetzt wurden alle Tabellen in der Datenbank vollständig wiederhergestellt. Versuchen..

SELECT * FROM dbname.tablename;

Ich habe MariaDB auf einem neuen Computer installiert und den umbenannten Mysql-Dienst in Datenordner gestoppt. Ich habe mein Problem gelöst, indem ich nur Mysql \ data \ table_folders und ibdata1 kopiert habe aus dem abgestürzten HD MySql-Datenordner in den neu installierten kopiert habe.

Ich habe ib_logfile0 und ib_logfile1 übersprungen (andernfalls hat der Server den Dienst nicht gestartet).

MySQL-Dienst gestartet.

Dann läuft der Server.

Es scheint, dass das Problem (zumindest in meinen und einigen anderen) mit ungültigen (beschädigten?) Innodb-Protokolldateien zu tun hat. Im Allgemeinen müssen sie einfach neu erstellt werden.

Hier sind Lösungen, von denen die meisten einen Neustart von MySQL erfordern.

• Erstellen Sie Ihre Protokolldateien neu (löschen Sie MySQL und starten Sie es neu )
• Ändern Sie die Größe Ihrer Protokolldateien (MySql 5.6+ generiert die Datei für Sie neu).
• Wenn Sie eine Art Datenmigration durchführen, stellen Sie sicher, dass Sie die richtige Datei korrekt migriert und ihr Berechtigungen erteilt haben, wie andere bereits angegeben haben
• Überprüfen Sie die Berechtigungen Ihrer Daten und Protokolldateien, die MySQL für beide besitzt
• Wenn alles andere fehlschlägt, müssen Sie wahrscheinlich die Datenbank neu erstellen

Hier ist ein anderes Szenario (Versions-Upgrade) :

Ich habe mein Betriebssystem (Mac OS El Captain) neu installiert und eine neue Version von MySQL (mit Homebrew) installiert. Die installierte Version (5.7) war neuer als meine vorherige. Dann habe ich die Tabellen einschließlich der ib * -Dateien kopiert und den Server neu gestartet. Ich konnte die Tabellen in der MySQL-Workbench sehen, aber als ich versuchte, etwas auszuwählen, bekam ich "Tabelle existiert nicht".

Lösung:

1. Stoppen Sie den MySQL-Server zB mysql.server stopoderbrew services stop mysql
2. Starten Sie den Server mit mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/(Pfad nach Bedarf ändern)
3. ausführen mysql_upgrade -u root -p password(in einem anderen Terminalfenster)
4. Fahren Sie den laufenden Server herunter mysqladmin -u root -p password shutdown
5. Starten Sie den Server im normalen Modus neu mysql.server startoderbrew services start mysql

Relevante Dokumente finden Sie hier .

In meinem Fall hatte ich einen Trigger für die Tabelle definiert und versuchte dann, die Zeile in die Tabelle einzufügen. Es scheint, als ob der Auslöser irgendwie fehlerhaft war und daher beim Einfügen ein Fehler aufgetreten ist. Die Tabelle existiert nicht.

Möglicherweise haben Sie ein verstecktes Zeichen in Ihrem Tabellennamen. Diese werden nicht angezeigt, wenn Sie Showtabellen erstellen. Können Sie eine "SHOW CREATE TABLE TABLE_ONE" ausführen und auf der Registerkarte "TABLE_ONE" ausfüllen und prüfen, ob versteckte Zeichen eingefügt sind? Haben Sie auch versucht, die Tabellen zu löschen und neu zu erstellen? Nur um sicherzustellen, dass nichts mit den Berechtigungen falsch ist und dass es keine versteckten Zeichen gibt.

Gleiches genaues Problem nach dem Import der TimeMachine-Sicherung. Meine Lösung bestand darin, den MySQL-Server zu stoppen und die Lese- / Schreibberechtigungen für die ib * -Dateien zu korrigieren.

Eine andere Antwort, die ich für wert halte, hier angesprochen zu werden (weil ich mit demselben Problem hierher gekommen bin und dies sich als Antwort für mich herausstellte):

Stellen Sie sicher, dass der Tabellenname in Ihrer Abfrage genau gleich geschrieben ist so geschrieben ist wie in der Datenbank.

Eine offensichtliche Sache für Neulinge, aber Dinge wie "Benutzer" gegen "Benutzer" können die Leute stolpern lassen, und ich dachte, es wäre eine hilfreiche Antwort, sie hier in der Liste zu haben. :) :)

In meinem Fall wurde beim Importieren der exportierten SQL-Datei die Fehlermeldung angezeigt, dass für die Abfrage zum Erstellen einer Tabelle keine Tabelle vorhanden ist.

Ich stellte fest, dass mein Datenbankname einen Unterstrich enthielt und mysql kurz davor ein Escapezeichen setzte.

Also habe ich diesen Unterstrich im Datenbanknamen entfernt, alles hat geklappt.

Hoffe, es hilft auch jemand anderem.

Mein Tisch war irgendwie umbenannt worden, ' Customers'dh mit einem führenden Leerzeichen

Das bedeutete

a) Anfragen sind gebrochen

b) Die Tabelle wurde nicht in der alphabetischen Reihenfolge meiner Tabellen angezeigt, was in meiner Panik bedeutete, dass ich sie nicht sehen konnte!

RENAME TABLE ` Customer` TO `Customer`;

In meinem Fall war es SQLCA.DBParm Parameter.

ich benutzte

SQLCA.DBParm = "Databse = "sle_database.text""

aber es muss sein

SQLCA.DBParm = "Database='" +sle_database.text+ "'"

Erklärung:

Sie werden drei Zeichenfolgen kombinieren:

 1. Database='              -  "Database='"

 2. (name of the database)  - +sle_database.text+

 3. '                       - "'" (means " ' "  without space)

Verwenden Sie keine Leerzeichen in Quatermarks. Vielen Dank an meinen Kollegen Jan.

Gehen Sie zu: xampp\mysql\data\dbname
Innerhalb von Datenbankname haben Sie die Dateien tablename.frm und tablename.ibd.
entferne es und starte mysql neu und versuche es erneut.

Kopieren Sie nur ibdata1Dateien aus Ihrem alten Datenverzeichnis. Nicht kopieren ib_logfile1oder ib_logfile0Dateien. Dadurch wird MySQL nicht mehr gestartet.

Kam heute das gleiche Problem überqueren. Dies ist ein MySQL-Problem "Identifier Case Sensitivity".

Bitte überprüfen Sie die entsprechende Datei. Es ist sehr wahrscheinlich, dass der Dateiname im Dateisystem in Kleinbuchstaben angegeben ist, der im Befehl "Tabellen anzeigen" aufgeführte Tabellenname jedoch in Großbuchstaben. Wenn die Systemvariable " lower_case_table_names" 0 ist, gibt die Abfrage "Tabelle nicht vorhanden" zurück, da bei Namensvergleichen zwischen Groß- und Kleinschreibung unterschieden wird, wenn " lower_case_table_names" 0 ist.

Ich hatte das gleiche Problem in Windows. Zusätzlich zum Kopieren der ib * -Dateien und des mysql-Verzeichnisses unter das Datenverzeichnis musste ich auch die my.ini-Datei abgleichen.

Die Datei my.ini aus meiner vorherigen Installation enthielt nicht die folgende Zeile:

innodb-page-size=65536

Aber meine neue Installation hat es getan. Möglicherweise, weil ich diese Option im älteren Installationsprogramm nicht hatte. Ich entfernte dies und startete den Dienst neu und die Tabellen funktionierten wie erwartet. Kurz gesagt, stellen Sie sicher, dass die neue my.ini-Datei eine Replik der alten ist, mit der einzigen Ausnahme, dass das Datenverzeichnis, das Plugin-Verzeichnis und die Port-Nr. Abhängig von Ihrer neuen Installation sind.