Fehler: Tablespace für Tabelle xxx existiert. Bitte verwerfen Sie den Tablespace vor IMPORT

134

Ich bin ziemlich neu in MySQL und erhalte einen ziemlich interessanten Fehler, bei dem ich über Google und die Stackoverflow-Suche keine Hilfe finden kann.

Ich verwende einen lokalen Server von MySQL 5.6.10 unter MacOS 10.8.3 und verwalte meine Datenbank über Navicat Essentials für MySQL.

Der Fehler, den ich bekomme, ist, dass nach dem Ausführen und Verwalten meiner Datenbank für ein paar Tage / Wochen etwas ausgelöst wird, um einige der Tabellen, die ich mithilfe von Abfragen in Navicat erstellt habe, zu löschen (es scheint unvollständig zu sein).

Wenn ich versuche, Abfragen mit diesen Tabellen auszuführen, warnt mich Navicat, dass die jeweilige Tabelle nicht vorhanden ist. So weit so gut - hier kommt der gute Teil:

Wenn ich versuche, die zuvor vorhandene Tabelle mit dem Namen "temp" zu erstellen, wird die folgende Fehlermeldung angezeigt:

Error : Tablespace for table '`database`.`temp`' exists. Please DISCARD the tablespace before IMPORT.

Wenn ich jedoch versuche, die Tabelle zu löschen oder den Tabellenbereich für diese Tabelle zu verwerfen, verwenden Sie

DROP TABLE temp;
ALTER TABLE temp DISCARD TABLESPACE;

Ich erhalte folgende Fehlermeldungen:

Error : Unknown table 'database.temp'
Error : Table 'database.temp' doesn't exist

Das bedeutet, dass mir empfohlen wird, den Tabellenbereich zu verwerfen, aber wenn ich dies versuche, existiert die Tabelle nicht. Ist es möglich, dass sich eine Art Rest dieser Tabelle an einer anderen Stelle befindet, an der die DISCARD-Abfrage nicht überprüft wird? Und hat jemand eine Idee, was all das auslösen könnte - völlig zufällig, wie es scheint?

Wie gesagt, ich bin neu in diesem Thema und ziemlich ahnungslos. Ich vermute, dass ein Neustart meines Laptops, dh ein Zurücksetzen meines lokalen MySQL-Servers oder möglicherweise Benutzerberechtigungen damit zu tun haben, aber ich gehe hier nur von einer Hypothese aus.

MattMirabilis
quelle
Sie können einige Lösungen für diese Art von Fehler überprüfen. codespeaker.com/laravel-framework/…
smzapp

Antworten:

123

Ein bisschen spät hier, aber im Allgemeinen ist dieses Problem aufgetreten, wenn beim Ausführen im Modus "innodb_file_per_table" der Fehler "Tablespace full" angezeigt wird. Ohne zu sehr ins Detail zu gehen (mehr hier ), wird der Tabellenbereich des Datenbankservers durch die Einstellung innodb_data_file_path definiert und ist standardmäßig eher klein. Selbst wenn der Tablespace voll ist, kann er bei größeren Abfragen und dergleichen immer noch auftreten (viele Nicht-Tabellen-Inhalte werden dort gespeichert, Protokolle, Caches usw. werden rückgängig gemacht).

Wie auch immer, ich habe festgestellt, dass, wenn Sie in das Betriebssystemverzeichnis schauen, in dem die Dateien pro Tabelle gespeichert sind, / var / lib / mysql standardmäßig unter OSX, / usr / local / var / mysql mit homebrew iirc, eine finden verwaiste Datei tablename.ibd ohne die normale Begleitdatei tablename.frm. Wenn Sie diese .ibd-Datei an einen sicheren temporären Speicherort verschieben (nur um sicher zu gehen), sollte dies das Problem beheben.

$ ls /var/lib/mysql

table1.frm
table1.idb
table2.frm
table2.ibd
table3.idb <- problem table, no table3.frm
table4.frm
table4.idb

$ mkdir /tmp/mysql_orphans
$ mv /var/lib/mysql/table3.ibd /tmp/mysql_orphans/

Eine Einschränkung: Stellen Sie sicher, dass alles, was das Problem ursprünglich verursacht hat, z. B. eine Abfrage mit langer Laufzeit, eine gesperrte Tabelle usw., gelöscht wurde. Andernfalls erhalten Sie beim zweiten Versuch nur eine andere verwaiste .ibd-Datei.

DangerDave
quelle
5
Mein MySQL-Datenverzeichnis war unter OS X Yosemite wurde in /usr/local/mysql/datastatt gespeichert /var/lib/mysql/. Ansonsten das Problem perfekt gelöst.
Alex Hoppen
13
In meinem Fall hat es nicht funktioniert ... Ich habe die verwaiste IDB-Datei gelöscht ... und als ich die Tabelle mit genau demselben Namen neu erstellte, erhielt ich die Meldung, dass die Tabelle bereits vorhanden ist (für die ich die IDB gelöscht habe) Datei) ... nach der obigen Aktion wurde eine neue verwaiste .idb-Datei im Verzeichnis erstellt ... sehr seltsam ... Ich weiß wirklich nicht, was ich annehmen soll.
Dimitris Papageorgiou
4
Ich habe das gleiche Problem wie Dimitris - ich musste einen Speicherauszug aus der Datenbank erstellen, die Datenbank löschen und aus dem Speicherauszug wiederherstellen.
Gerfried
1
@Gerfried Das hat bei mir funktioniert, solange ich den MySQL-Prozess nach dem Löschen der Datei gestoppt und gestartet habe.
MER
2
@DimitrisPapageorgiou Dies funktionierte für mich, solange ich den MySQL-Prozess nach dem Löschen der Datei stoppte und startete.
MER
76

Xampp- und Mamp-Benutzer

Hatte den gleichen Fehler beim Importieren einer Datenbank (nach dem Leeren) über MySQL. Ich stellte fest, dass ich eine tablename.ibdDatei übrig hatte, während alle anderen gelöscht wurden. Ich habe es manuell gelöscht mysql/data/database_nameund der Fehler war verschwunden.

Technotronic
quelle
Hat diese Antwort Menschen geholfen, die XAMPP nicht verwenden?
Technotronic
3
Daumen hoch von mir! gut gearbeitet. Erlauben
Fenix ​​Aoras
unter Verwendung dieser entwickelte sich ein 168-Fehler von der Speicher-Engine in Linux Mint, ohne Xampp oder Mamp (keine Kritik, nur Information)
Steven
1
funktioniert! Ich habe eine defekte .ibd-Datei gelöscht und dann kann die Tabelle erneut erstellt werden. Ubuntu 16, Mariadb
Waza123
Gleiches gilt für Docker (wenn Docker abstürzt oder der Host neu startet, befindet sich möglicherweise ein Dead Date in Ihrem Synchronisierungsordner, der diesen Fehler verursacht)
Sliq
23

Für WAMP-Benutzer [Windows 7 Ultimate x64-bit]:

Ich stimme dem zu, was DangerDave gesagt hat, und stelle daher eine Antwort für WAMP-Benutzer zur Verfügung .

Hinweis: Zunächst müssen Sie in den Ordner .. \ WAMP \ Bin \ MySQL \ MySQL [Ihre MySQL-Version] \ Data wechseln.

Jetzt sehen Sie Ordner aller Ihrer Datenbanken

  • Doppelklicken Sie auf den Ordner der Datenbank, in dem sich die betreffende Tabelle befindet, um sie zu öffnen
  • Es sollte keine Datei geben [Your offending MySQL table name].frm, stattdessen sollte es eine Datei geben[Your offending MySQL table name].ibd
  • Löschen Sie die [Your offending MySQL table name].ibd
  • Löschen Sie es dann auch aus dem Papierkorb
  • Führen Sie dann Ihre MySQL-Abfrage in der Datenbank aus und Sie sind fertig
Harshul Vijay
quelle
22

Wenn Sie die .idbDatei nach dem Löschen erneut erstellen, lesen Sie diese Antwort.

So hat es bei mir funktioniert. Ich hatte die .idbDatei ohne entsprechende .frmund wenn ich die .idbDatei lösche , erstellt die Datenbank sie erneut. und ich fand die Lösung in einer Zeile in der MySQL- Dokumentation ( Tablespace existiert nicht Teil)

1- Erstellen Sie eine passende .frm-Datei in einem anderen Datenbankverzeichnis und kopieren Sie sie in das Datenbankverzeichnis, in dem sich die verwaiste Tabelle befindet.

2- Geben Sie DROP TABLE für die Originaltabelle aus. Das sollte die Tabelle erfolgreich löschen und InnoDB sollte eine Warnung in das Fehlerprotokoll drucken, dass die .ibd-Datei fehlte.

Ich habe eine andere Tabellendatei kopiert .frmund sie wie meine fehlende Tabelle benannt, dann eine normale Drop-Table-Abfrage durchgeführt und voila, es hat funktioniert und die Tabelle wird normal gelöscht!

Mein System ist XAMPP unter Windows MariaDB 10.1.8

Buchhalter م
quelle
3
Falls dies für andere nicht offensichtlich war: Wenn Sie die .frm-Datei erstellt und die Tabelle gelöscht haben, muss die .idb-Datei gelöscht werden.
Narretz
6
Kann bestätigen, die Schritte sollten sein: 1. mysql / path / table_name.idb löschen 2. table_name.frm hinzufügen 3. DROP table_name
Jeremy Dennen
Das hat bei mir funktioniert. Vielen Dank. Ich habe diesen Fehler beim Löschen eines FK erhalten und sofort danach MySQL gestoppt. Ich denke, dies ist meine Tabelle def Daten beschädigt.
Rodolfo Velasco
Denken Sie daran, MySQL neu zu starten, nachdem Sie die Datei abgelegt haben, und versuchen Sie dann, sie zu löschen
Seyed Ali Roshan
Unter mysql> data> mysql befindet sich eine von mir benötigte .frm-Datei. Kann ich diesen kopieren?
Timo
8

In meinem Fall war die einzige Arbeitslösung:

  1. CREATE TABLE bad_tableENGINE = MyISAM ...
  2. rm bad_table.ibd
  3. TROPFENTABELLE bad_table
Andrey Radomanov
quelle
Hat für mich gearbeitet! [FEHLER] InnoDB: Die Datei './dbname/tabellenname.ibd' ist bereits vorhanden, obwohl die entsprechende Tabelle im InnoDB-Datenwörterbuch nicht vorhanden war. Haben Sie InnoDB .ibd-Dateien verschoben, ohne die SQL-Befehle DISCARD TABLESPACE und IMPORT TABLESPACE zu verwenden, oder ist mysqld mitten in CREATE TABLE abgestürzt? Sie können das Problem beheben, indem Sie die Datei './dbname/tabellenname.ibd' unter dem 'Datenverzeichnis' von MySQL entfernen.
PAdrian
1
Tabelle kann nicht erstellt werden, da Tablespace vorhanden ist.
Liam Mitchell
Es ist keine Arbeit für mich. Die ibd-Datei erscheint weiter, nachdem ich die Tabelle mit derselben Engine neu erstellen möchte.
Fajar Rukmo
8

Dies ist genau das, was ich in Mariadb 10.2.16 auf Fedora getan habe, als ich eine Tabelle hatte, die genau die gleichen Fehler in der Protokolldatei zeigte, nehme ich an ...

2018-07-11  9:43:58 140323764213504 [Note] InnoDB: The file './database_name/innodb_table.ibd' already exists though the corresponding table did not exist in the InnoDB data dictionary. You can resolve the problem by removing the file.
2018-07-11  9:44:29 140323764213504 [Warning] InnoDB: Tablespace 'database_name/innodb_table' exists in the cache with id 2836 != 2918

Ihr Kilometerstand und Ihre Fehler können variieren, aber der wichtigste, den ich annehme, ist

...already exists though the corresponding table did not exist in the InnoDB data dictionary...

mit Drop-Tabelle funktioniert nicht so gut wie Tabelle ändern ...

MariaDB [database_name]> drop table innodb_table;
ERROR 1051 (42S02): Unknown table 'database_name.innodb_table'

MariaDB [database_name]> alter table innodb_table discard tablespace;
ERROR 1146 (42S02): Table 'database_name.innodb_table' doesn't exist

Das Erstellen einer Tabelle schlägt ebenfalls folgendermaßen fehl:

MariaDB [database_name]> create table  innodb_table(`id` int(10) unsigned NOT NULL);
ERROR 1813 (HY000): Tablespace for table '`database_name`.`innodb_table`' exists. Please DISCARD the tablespace before IMPORT

Um dies zu beheben, habe ich zuerst getan

create table  innodb_table2(`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.07 sec)

dann habe ich im Verzeichnis / var / lib / mysql / database_name Folgendes als root ausgeführt, um das Überschreiben von innodb_table.ibd zu bestätigen, was zu Problemen geführt hat

cp -a innodb_table2.frm innodb_table.frm
cp -a innodb_table2.ibd innodb_table.ibd
systemctl restart mariadb

Dann gab ich in der MySQL-Konsole einen erfolgreichen Drop-Befehl für beide Tabellen aus

MariaDB [database_name]> drop table innodb_table;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    8
Current database: database_name

Query OK, 0 rows affected (0.08 sec)

MariaDB [database_name]> drop table innodb_table2;
Query OK, 0 rows affected (0.25 sec)

und jetzt ist alles quadratisch und ich kann die eine einzige Tabelle neu erstellen ...

MariaDB [database_name]> create table  innodb_table (`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.08 sec)

EDIT: Ich wollte in ein hinzufügen

restorecon -Rv /var/lib/mysql/database_name 

Befehl nach dem Kopieren der Datenbank, um alle Selinux-Kontexte so zu erhalten, wie sie sein sollten, obwohl wir sie fast sofort aus der Datenbank löschen. Alternativ können Sie einfach die Option --archive oder -a zu den beiden cp hinzufügen Befehle, also ja, tatsächlich verkürzt die Archivierungsoption Folgendes:

cp innodb_table2.frm innodb_table.frm
cp innodb_table2.ibd innodb_table.ibd
chown mysql:mysql innodb_table.frm innodb_table.ibd
chmod 660 innodb_table.frm innodb_table.ibd
restorecon -Rv /var/lib/mysql/database_name
systemctl restart mariadb

auf nur das Folgende, was ich für besser halte und das den Selinux-Kontext beibehält, der für die bereits erstellte Tabelle festgelegt ist.

cp -a innodb_table2.frm innodb_table.frm
cp -a innodb_table2.ibd innodb_table.ibd
systemctl restart mariadb

Ich habe die obige längere Liste von Befehlen durch die kürzere Liste ersetzt, die noch durch ein * gekürzt werden könnte

Chris
quelle
Dies hat bei CentOS MariaDB 10.2.31 gut funktioniert. Ich suchte nach einer Lösung, die keinen Neustart des MySQL-Dienstes erforderte, und das war es. Der Schlüssel besteht darin, den Satz sauberer innodb_table2-Dateien (innodb_table2.frm und innodb_table2.ibd) zu erstellen und beide über den innodb_table-Dateien zu platzieren.
Justin
6

In meinem Fall:

Entfernen Sie zuerst tableName.ibdin Ihrem Datenbankverzeichnis von MySQL und führen Sie dann Folgendes aus:

ALTER TABLE tableName DISCARD TABLESPACE;
DROP TABLE tableName;
jcarlosweb
quelle
Danke, in meinem Fall habe ich 1) den Datenbankserver gestoppt (Dienst MySQL stoppen) 2) IDB-Datei entfernt 3) Datenbankserver gestartet (Dienst MySQL starten) Keine Abfragen zum Ändern und
Löschen ausgeführt
Ihr Datenbankverzeichnis in Windows befindet sich standardmäßig in C: \ ProgramData \ MySQL
Rodin10
4

Ich habe den gleichen Fehler beim Ausführen auf wampserver erhalten, als ich versucht habe, eine Benutzertabelle zu erstellen. Ich habe eine Datei users.ibd gefunden und nachdem ich diese Datei gelöscht habe, habe ich den Befehl migrate erneut ausgeführt und es hat funktioniert. Die Datei auf meinem Windows-Computer befand sich in wamp / bin / mysql / mysql5.6.12 / data / myproject.

Morgan
quelle
4

Lösung

Die einfachere Option ist jedoch folgende: Starten Sie MySQL neu und führen Sie dann die folgenden vier Schritte aus:

1) created a dummy table in the database;
2) discarded its tablespace;
3) moved the .ibd file into the database folder on the system;
4) attached the tablespace back to the table

Auf diese Weise stimmten die Tablespace-ID im Datenwörterbuch und die Datei überein. Damit war der Import des Tablespace erfolgreich.

Dies kann Ihnen mehr Vertrauen in den Umgang mit einigen der InnoDB- "Gotchas" während des Wiederherstellungsprozesses oder sogar der Dateiübertragung geben.

ref

Bhavin Rana
quelle
7
Dies ist keine eigenständige Antwort.
Nathaniel Ford
3

Hier sind die Lösungsschritte:

  1. Sichern Sie Ihre Datenbank (Struktur mit Drop-Option und Daten)
  2. Stoppen Sie den MySQL-Engine-Service
  3. Entfernen Sie das Datenbankverzeichnis manuell aus mysql / data
  4. Starten Sie den MySQL-Motor
  5. Erstellen Sie eine neue Datenbank mit einem anderen Namen als Ihrer beschädigten Datenbank
  6. Erstellen Sie eine einzelne Tabelle mit dem Namen der beschädigten Tabelle in der neuen Datenbank (dies ist das Geheimnis). und es ist besser, die Tabelle mit genau der gleichen Struktur zu erstellen.
  7. Benennen Sie die Datenbank in die alte beschädigte Datenbank um
  8. Stellen Sie Ihr Backup wieder her und Ihre Tabelle funktioniert einwandfrei.
Mahmoud Rabea
quelle
2

Hatte dieses Problem mehrmals. Wenn Sie eine große Datenbank haben und versuchen möchten, Sicherung / Wiederherstellung (mit hinzugefügter fehlender Tabelle) zu vermeiden, versuchen Sie es einige Male hin und her:

DROP TABLE my_table;

ALTER TABLE my_table DISCARD TABLESPACE;

-und-

rm my_table.ibd (verwaist ohne entsprechende my_table.frm) befindet sich im Verzeichnis / var / lib / mysql / my_db /

-und dann-

TABELLE ERSTELLEN, WENN NICHT EXISTIERT my_table(...)

Nerko
quelle
2

Das Löschen / Verschieben von tablename.ibd hat bei mir sicher nicht funktioniert.

Wie ich es gelöst habe

Da ich die beschädigte und nicht vorhandene Tabelle löschen wollte, habe ich eine Sicherungskopie der anderen Tabellen erstellt, indem ich zu phpmyadmin-> Datenbank-> Export-> Ausgewählte Tabellen zum Sichern-> Exportieren (als .sql) gegangen bin.

Danach habe ich das Datenbanksymbol neben dem Datenbanknamen ausgewählt und dann gelöscht. Neue Datenbank erstellt. Wählen Sie Ihre neue Datenbank aus-> Importieren-> Wählen Sie die zuvor heruntergeladene Datei aus-> Klicken Sie auf Importieren. Jetzt habe ich meine alten Arbeitstabellen und habe die beschädigte Tabelle gelöscht. Jetzt erstelle ich einfach die Tabelle, die den Fehler ausgelöst hat.

Wahrscheinlich hatte ich eine frühere Sicherung der beschädigten Tabelle.

Rost
quelle
2

Dieser Fehler tritt auf, wenn Sie einige Funktionen anhalten. Als würde man die folgende Abfrage mit einem falschen Fremdschlüssel ausführen.

set foreign_key_checks=0
Zeddarn
quelle
2

Hatte genau das gleiche Problem; Ich hatte hinzugefügt [email protected](nachdem ich zuvor 5.5 hatte).

Die Standardeinstellungen für 5.6 sind, innodb_file_per_table=1während sie in 5.5 sind innodb_file_per_table=0.

Ihre vorhandene ibdata1Datei (die kombinierten Innodb-Daten) enthält weiterhin Verweise auf die Tabellen, die Sie erstellen / löschen möchten. Wechseln Sie entweder innodb_file_per_tablezurück zu 0 oder löschen Sie die ibdata1-Datendatei ( dadurch gehen alle Ihre Daten verloren. Stellen Sie daher sicher, dass Sie sie zuerst mysqldumpen oder bereits einen .sql-Speicherauszug haben ).

Die andere [email protected]Standardeinstellung, die mich gebissen hat, war das Fehlen eines Ports. Daher wurden im Netzwerk standardmäßig Unix-Sockets verwendet, und der MySQL-Client meldete weiterhin:

ERROR 2013 (HY000): Lost connection to MySQL server at 'sending authentication information', system error: 32

Ich <string>--port=3306</string>habe dem .plistArray hinzugefügt , aber Sie können auch port=3306in Ihrem angebenmy.cnf

Führen brew services stop [email protected]Sie dann Ihre Änderungen ausbrew services start [email protected]

jaygooby
quelle
1

Der Versuch, den Tablespace zu löschen, kann zu anderen Fehlern führen. Für mich habe ich folgenden Fehler erhalten:

DROP TABLESPACE `tablename`

Error Code: 1478. Table storage engine 'InnoDB' does not support the create option 'TABLESPACE or LOGFILE GROUP' 

Meine Lösung bestand darin, die Datenbank zu löschen. Dadurch werden alle damit verbundenen Tabellenbereiche entfernt und Sie können die Tabellen erneut erstellen.

Aris
quelle
19
Leider ist das so, als würde man sagen: "Ich habe eine Schraube, und die Verwendung eines Hammers gibt diesen Fehler zurück. Meine Lösung bestand also darin, einen Stein darauf fallen zu lassen." Der wahre Wert wäre herauszufinden, wie diese eine Tabelle repariert werden kann, ohne die gesamte Datenbank zu zerstören.
Jason
Doh! Ich hatte gehofft, dass dies eine alternative Lösung für meine Frage sein würde (und ich habe sie als Antwort veröffentlicht), aber ich bin bereits in der Mitte des Prozesses des Umbenennens von Tabellen / Löschen der Datenbank. Ich hasse InnoDB jetzt irgendwie.
NobleUplift
Aber ich habe die Datenbank zerstört, neu erstellt und habe immer noch dieses Problem!
TRiG
@TRiG hast du den Server neu gestartet?
Aris
1
Ich denke, ich werde eine separate Frage stellen, @Aris. In meinem Fall befindet es sich auf einem Ubuntu-Desktop. Ich habe nicht nur MySQL, sondern die gesamte Maschine mehrmals neu gestartet. Löschte auch den Datenbankordner von Hand mit einem rm -r. Es ist irritierend, aber auch nicht auffällig.
TRiG
1

Wenn Sie einen anderen Server mit einer guten Version derselben Tabelle haben, können Sie eine Kopie (table_copy) erstellen und die table_copy auf den Problemserver übertragen. Löschen Sie dann die Problemtabelle und benennen Sie table_copy in table um.

user3524152
quelle
1

Für mich hat es geholfen, einfach in das MYSQL DATA-Verzeichnis unter / var / lib / mysql / {Datenbankname} (Linux) zu wechseln und die .ibd- Datei {Tabellenname} zu löschen , die mit dem Ordnernamen identisch war.

Yura Galavay
quelle
0

Ich lösche nur meine alte Datenbank in meinem lokalen Host direkt aus wamp, stoppe alle Dienste, gehe zu wamp / bin / mysql / mysql [version] / data und habe die Datenbank mit Problemen gefunden. Ich lösche sie und starte erneut alle Dienste. Erstellen Sie erneut Ihre Datenbank und es ist fertig. Jetzt können Sie Ihre Tabellen importieren.

XMaster
quelle
0

Die Art und Weise, wie ich dieses Problem "lösen" konnte, ist ziemlich ärgerlich, aber es gibt ein Skript, das es behandelt.

Im Wesentlichen müssen Sie die ibdata1und ib_logfile*Dateien (sie die Zuordnungen von Fremdschlüssel enthalten, unter anderem) gehen weg. Der einzig sichere Weg, dies zu tun, besteht darin, alle Ihre Datenbanken zu exportieren, MySQL zu stoppen, die Dateien zu entfernen, MySQL zu starten und dann die Dateien zu importieren.

Das Skript , das dieses Problem lösen hilft ist https://github.com/uberhacker/shrink-ibdata1 , obwohl das erklärte Ziel dieses Skripts ist anders, es tut das Problem lösen.

Glen Solsberry
quelle
0

Der einzige Weg, wie es für mich funktionierte, war:

  1. Erstellen Sie eine ähnliche Tabelle
  2. Kopieren Sie die .frm- und .idb-Dateien der neuen ähnlichen Tabelle in den Namen der beschädigten Tabelle.
  3. Festgelegte Berechtigungen
  4. Starten Sie MariaDB neu
  5. Löschen Sie die beschädigte Tabelle
Avibrazil
quelle
-1

Wenn Sie dieses Problem haben und keine andere Option haben, ändern Sie die Engine in eine andere Engine wie 'myisam', und versuchen Sie, die Tabelle zu erstellen.

Haftungsausschluss: Dies ist keine gültige Antwort, da Sie möglicherweise Fremdschlüsseleinschränkungen haben, die von einer anderen Speicher-Engine nicht unterstützt werden. Jede Speicher-Engine hat ihre eigene Spezialität zum Speichern und Zugreifen auf Daten. Diese Punkte müssen ebenfalls berücksichtigt werden.

Ankit Vishwakarma
quelle
-1

Bitte verwerfen Sie den Tablespace vor IMPORT

Ich habe die gleiche Problemlösung unten

  1. Zuerst müssen Sie Ihren Datenbanknamen löschen. Wenn Ihre Datenbank nicht gelöscht wird, haben Sie mich fließen lassen. Für Windows-Systeme lautet Ihr Verzeichnis C: / xampp / mysql / data / yourdabasefolder. Entfernen Sie "yourdabasefolder".

  2. Wieder müssen Sie eine neue Datenbank erstellen und Ihre alte SQL-Datei importieren. Es wird Arbeit sein

Vielen Dank

F5 Buddy
quelle
-1

Ich musste mein MySQL-Datenverzeichnis finden:

VARIABLEN ANZEIGEN, WO Variablenname WIE "% dir"

Dann erzwinge das Entfernen dieser Datenbank:

sudo rm -rf

GarethReid
quelle
-1

Sie können die folgende Abfrage als MySQL-Root-Benutzer ausführen

drop tablespace `tableName`
Saroj
quelle
-1

Hey Entwickler verschwenden keine Zeit. Löschen Sie einfach die Datenbank mit den Tabellen und importieren Sie ganze Tabellen erneut. Zeit sparen = Zeit ist Geld. Prost.

Rohit Saini
quelle