Gründe und Lösungen für das Fehlschlagen der Erstellung von Fremdschlüsseln durch MySQL

Beim Verknüpfen zweier Tabellen konnte kein Fremdschlüssel erstellt werden. In diesem Blog habe ich gesehen, dass das Problem die Konsistenz der Charset- und Collate-Optionen in Punkt 6 auf Tabellen- und Feldebene war. Die Zeichensatz- und Sortierungskodierung meiner beiden Tabellen ist inkonsistent. Beide Tabellen führen die SQL-Anweisung aus:

Tabelle ändern, Tabellenname in Zeichensatz UTF8 konvertieren;

Perfekte Lösung des Problems;

ps: Mal sehen, dass MySQL keine Fremdschlüssel erstellen und Fremdschlüsseleigenschaften abfragen kann

MyISAM und InnoDB erklärt

InnoDB und MyISAM sind die beiden von vielen Benutzern bei der Verwendung von MySQL am häufigsten verwendeten Tabellentypen. Diese beiden Tabellentypen haben je nach spezifischer Anwendung ihre eigenen Vor- und Nachteile. Der grundlegende Unterschied besteht darin, dass der MyISAM-Typ keine erweiterte Verarbeitung wie etwa die Transaktionsverarbeitung unterstützt, während der InnoDB-Typ dies tut. Bei Tabellen vom Typ MyISAM liegt der Schwerpunkt auf der Leistung. Ihre Ausführungszeiten sind schneller als bei Tabellen vom Typ InnoDB, sie bieten jedoch keine Transaktionsunterstützung. InnoDB bietet Transaktionsunterstützung und erweiterte Datenbankfunktionen wie externe Schlüssel.

Hier sind einige Details und Implementierungsunterschiede:

◆1. InnoDB unterstützt keine Indizes vom Typ FULLTEXT.

◆2. InnoDB speichert nicht die genaue Anzahl der Zeilen in der Tabelle. Das heißt, wenn select count(*) from table ausgeführt wird, muss InnoDB die gesamte Tabelle durchsuchen, um die Anzahl der Zeilen zu berechnen, während MyISAM einfach die gespeicherte Anzahl der Zeilen liest. Beachten Sie, dass der Vorgang für beide Tabellen gleich ist, wenn die count(*)-Anweisung eine Where-Bedingung enthält.

◆ 3. Für Felder vom Typ AUTO_INCREMENT muss InnoDB einen Index enthalten, der nur dieses Feld hat, aber in einer MyISAM-Tabelle kann ein gemeinsamer Index mit anderen Feldern erstellt werden.

◆4. Beim DELETE FROM-Tabelle erstellt InnoDB die Tabelle nicht neu, sondern löscht die Zeilen einzeln.

◆5. Die Operation LOAD TABLE FROM MASTER funktioniert nicht für InnoDB. Die Lösung besteht darin, die InnoDB-Tabelle zunächst in eine MyISAM-Tabelle umzuwandeln und sie nach dem Importieren der Daten wieder in eine InnoDB-Tabelle umzuwandeln. Dies gilt jedoch nicht für Tabellen, die zusätzliche InnoDB-Funktionen verwenden (z. B. Fremdschlüssel).

Darüber hinaus ist die Zeilensperre der InnoDB-Tabelle nicht absolut. Wenn MySQL beim Ausführen einer SQL-Anweisung den zu scannenden Bereich nicht bestimmen kann, sperrt die InnoDB-Tabelle auch die gesamte Tabelle. Beispielsweise lautet der Update-Tabellensatz num = 1, wobei der Name wie "%aaa%" lautet.

Der Hauptunterschied zwischen den beiden Typen besteht darin, dass Innodb Transaktionen sowie Fremdschlüssel- und Zeilensperren unterstützt. MyISAM unterstützt dies nicht. Daher wird MyISAM oft als nur für den Einsatz in kleinen Projekten geeignet angesehen.

Aus Sicht von MySQL-Benutzern sind sowohl Innodb als auch MyISAM vorzuziehen. Wenn die Datenbankplattform die Anforderungen erfüllen soll: 99,9 % Stabilität, bequeme Skalierbarkeit und hohe Verfügbarkeit, ist MyISAM definitiv die erste Wahl.

Hier sind die Gründe:

1. Die meisten auf der Plattform ausgeführten Projekte sind Projekte mit mehr Lese- und weniger Schreibzugriff, und die Leseleistung von MyISAM ist viel besser als die von Innodb.

2. Der Index und die Daten von MyISAM sind getrennt und der Index wird komprimiert, sodass die Speichernutzungsrate erheblich verbessert wird. Es können mehr Indizes geladen werden, während die Indizes und Daten von Innodb eng gebündelt sind und keine Komprimierung verwendet wird, was Innodb viel größer als MyISAM macht.

3. Es kommt häufig vor, dass Anwendungsentwickler alle ein oder zwei Monate versehentlich eine Tabelle aktualisieren, deren Bereich falsch ist, wodurch die Tabelle unbrauchbar wird. In diesem Fall zeigt sich die Überlegenheit von MyISAM. Nehmen Sie einfach die Datei der entsprechenden Tabelle aus dem an diesem Tag kopierten komprimierten Paket, legen Sie sie in ein Datenbankverzeichnis, kopieren Sie sie in SQL, importieren Sie sie wieder in die Hauptdatenbank und füllen Sie das entsprechende Binärprotokoll aus. Wenn es Innodb ist, kann es leider nicht so schnell sein. Sagen Sie mir nicht, dass Innodb regelmäßig den Exportmechanismus xxx.sql zum Sichern verwenden soll, da das Datenvolumen der kleinsten Datenbankinstanz im Grunde mehrere zehn GB beträgt.

4. In Bezug auf die Anwendungslogik sind select count(*) und order by die häufigsten Operationen und machen mehr als 60 % aller SQL-Anweisungen aus. Innodb sperrt die Tabelle tatsächlich für diese Operation. Viele Leute denken, dass Innodb eine Sperre auf Zeilenebene ist, die nur für den Primärschlüssel gültig ist. Nicht-Primärschlüssel sperren die gesamte Tabelle.

5. Außerdem gibt es oft viele Anwendungsabteilungen, die regelmäßig Daten bestimmter Tabellen von mir benötigen. MyISAM ist sehr praktisch. Ich muss ihnen nur die frm.MYD- und MYI-Dateien senden, die der Tabelle entsprechen, und sie können die Datenbank in der entsprechenden Version starten. Innodb erfordert den Export von xxx.sql, denn wenn ich nur die Datei anderen gebe, kann die andere Partei sie aufgrund des Einflusses der Wörterbuchdatendatei nicht verwenden.

6. Im Vergleich zu MyISAM kann Innodb bei Einfüge- und Schreibvorgängen nicht die Schreibleistung von MyISAM erreichen. Bei indexbasierten Aktualisierungsvorgängen ist MyISAM zwar möglicherweise schlechter als Innodb, aber es besteht auch das Problem, ob die Slave-Datenbank mit derart vielen gleichzeitigen Schreibvorgängen Schritt halten kann. Dieses Problem lässt sich besser durch eine Sharding-Architektur mit mehreren Instanzen lösen.

7. Wenn MyISAM verwendet wird, kann die Merge-Engine die Entwicklung der Anwendungsabteilung erheblich beschleunigen. Sie müssen nur einige Select-Count(*)-Operationen an der Merge-Tabelle durchführen. Dies eignet sich sehr gut für Geschäftstabellen eines bestimmten Typs (wie Protokolle, Umfragestatistiken) mit insgesamt etwa Hunderten Millionen Zeilen in großen Projekten.

Natürlich ist Innodb absolut nicht zu verwenden. Für Projekte, die Transaktionen verwenden, sollte Innodb verwendet werden. Darüber hinaus sagen manche Leute möglicherweise, dass MyISAM zu viele Schreibvorgänge nicht aushält, aber dies kann durch die Architektur ausgeglichen werden.

SELECT * FROM information_schema.key_column_usage WHERE table_name='Tabellenname';
Tabelle mit Tabellennamen erstellen anzeigen;

Zusammenfassen

Oben habe ich Ihnen den Grund und die Lösung für die Unfähigkeit von MySQL vorgestellt, Fremdschlüssel zu erstellen. Ich hoffe, es wird Ihnen helfen!