MySQL
Fehlercodes

Fehlercode 1064: Syntaxfehler

select LastName, FirstName,
from Person

Nachricht zurücksenden:

Fehlercode: 1064. Sie haben einen Fehler in Ihrer SQL-Syntax. Überprüfen Sie das Handbuch, das Ihrer MySQL-Server-Version entspricht, auf die richtige Syntax, die in der Nähe von 'von Person' in Zeile 2 verwendet werden soll.

Wenn Sie eine Meldung "1064 error" von MySQL erhalten, kann die Abfrage nicht ohne Syntaxfehler analysiert werden. Mit anderen Worten kann die Abfrage keinen Sinn ergeben.

Das Zitat in der Fehlermeldung beginnt mit dem ersten Zeichen der Abfrage, das MySQL nicht ermitteln kann, wie es zu analysieren ist. In diesem Beispiel kann MySQL im Kontext from Person keinen Sinn ergeben. In diesem Fall gibt es unmittelbar vor from Person ein zusätzliches Komma. Das Komma weist MySQL an, eine andere Spaltenbeschreibung in der SELECT Klausel zu erwarten

Ein Syntaxfehler sagt immer ... near '...' . Die Sache am Anfang der Anführungszeichen ist sehr nahe dort, wo der Fehler liegt. Um einen Fehler zu finden, sehen Sie sich das erste Token in den Anführungszeichen und das letzte Token vor den Anführungszeichen an.

Manchmal kommt man in die ... near '' ; das heißt, nichts in den Zitaten. Das erste Zeichen, das MySQL nicht herausfinden kann, steht am Ende oder am Anfang der Anweisung. Dies deutet darauf hin, dass die Abfrage unausgeglichene Anführungszeichen ( ' oder " ) oder unausgeglichene Klammern enthält oder dass Sie die Anweisung zuvor nicht korrekt beendet haben.

Bei einer gespeicherten Routine haben Sie möglicherweise vergessen, DELIMITER ordnungsgemäß zu verwenden.

Wenn Sie also den Fehler 1064 erhalten, schauen Sie sich den Text der Abfrage an und suchen Sie den in der Fehlermeldung genannten Punkt. Untersuchen Sie den Text der Abfrage visuell an diesem Punkt.

Wenn Sie jemanden um Hilfe bei der Behebung von Fehler 1064 bitten, geben Sie am besten sowohl den Text der gesamten Abfrage als auch den Text der Fehlermeldung an.

Fehlercode 1175: Sicheres Update

Dieser Fehler tritt auf, wenn Sie versuchen, Datensätze zu aktualisieren oder zu löschen, ohne die WHERE Klausel zu verwenden, die die KEY Spalte verwendet.

Um das Löschen oder Aktualisieren trotzdem auszuführen, geben Sie Folgendes ein:

SET SQL_SAFE_UPDATES = 0;

Um den abgesicherten Modus wieder zu aktivieren, geben Sie Folgendes ein:

SET SQL_SAFE_UPDATES = 1;

Fehlercode 1215: Fremdschlüsseleinschränkung kann nicht hinzugefügt werden

Dieser Fehler tritt auf, wenn Tabellen nicht ausreichend strukturiert sind, um die vom Entwickler geforderte Überprüfung der fremden Schlüssel (Foreign Key, FK ) zu prüfen.

CREATE TABLE `gtType` (
  `type` char(2) NOT NULL,
  `description` varchar(1000) NOT NULL,
  PRIMARY KEY (`type`)
) ENGINE=InnoDB;

CREATE TABLE `getTogethers` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `type` char(2) NOT NULL,
  `eventDT` datetime NOT NULL,
  `location` varchar(1000) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_gt2type` (`type`), -- see Note1 below 
  CONSTRAINT `gettogethers_ibfk_1` FOREIGN KEY (`type`) REFERENCES `gtType` (`type`)
) ENGINE=InnoDB;

Hinweis 1: Ein derartiger SCHLÜSSEL wird automatisch erstellt, wenn dies aufgrund der FK-Definition in der folgenden Zeile erforderlich ist. Der Entwickler kann es überspringen und der KEY (aka index) wird bei Bedarf hinzugefügt. Ein Beispiel dafür, wie es vom Entwickler übersprungen wird, ist unten in someOther .

So weit so gut, bis zum unten genannten Aufruf.

CREATE TABLE `someOther` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `someDT` datetime NOT NULL,
  PRIMARY KEY (`id`),
  CONSTRAINT `someOther_dt` FOREIGN KEY (`someDT`) REFERENCES `getTogethers` (`eventDT`)
) ENGINE=InnoDB;

Fehlercode: 1215. Fremdschlüsseleinschränkung kann nicht hinzugefügt werden

In diesem Fall schlägt der Vorgang fehl, da in der referenzierten Tabelle getTogethers kein Index getTogethers , um die schnelle Suche nach einem eventDT getTogethers zu behandeln. In der nächsten Aussage zu lösen.

CREATE INDEX `gt_eventdt` ON getTogethers (`eventDT`);

Die Tabelle getTogethers wurde geändert, und nun wird die Erstellung von someOther erfolgreich sein.

Auf der MySQL-Handbuchseite mit FOREIGN KEY-Einschränkungen :

MySQL erfordert Indizes für Fremdschlüssel und referenzierte Schlüssel, damit Fremdschlüsselüberprüfungen schnell durchgeführt werden können und keine Tabellensuche erforderlich ist. In der referenzierenden Tabelle muss ein Index vorhanden sein, in dem die Fremdschlüsselspalten als erste Spalten in derselben Reihenfolge aufgeführt sind. Ein solcher Index wird automatisch für die referenzierende Tabelle erstellt, wenn er nicht vorhanden ist.

Entsprechende Spalten im Fremdschlüssel und der referenzierte Schlüssel müssen ähnliche Datentypen haben. Die Größe und das Vorzeichen von Integer-Typen müssen gleich sein. Die Länge der Zeichenfolgentypen muss nicht gleich sein. Für nicht-binäre (Zeichen-) Zeichenfolgenspalten müssen der Zeichensatz und die Sortierung identisch sein.

InnoDB erlaubt einem Fremdschlüssel, auf Indexspalten oder Spaltengruppen zu verweisen. In der referenzierten Tabelle muss jedoch ein Index vorhanden sein, in dem die referenzierten Spalten als erste Spalten in derselben Reihenfolge aufgeführt sind.

Beachten Sie, dass der letzte Punkt oben über die erste (ganz linke) Spalte und das Fehlen einer Primärschlüssel-Anforderung (obwohl dringend empfohlen).

Bei erfolgreicher Erstellung einer referenzierten (untergeordneten) Tabelle sind alle automatisch für Sie erstellten Schlüssel mit einem Befehl wie dem folgenden sichtbar:

SHOW CREATE TABLE someOther;

Andere häufige Fälle, in denen dieser Fehler auftritt, sind, wie oben in den Dokumenten erwähnt, jedoch hervorzuheben:

• Scheinbar triviale Unterschiede in INT die signiert sind und auf INT UNSIGNED .

• Entwickler, die Probleme mit dem Verständnis von mehrspaltigen (zusammengesetzten) Schlüsseln und den ersten (am weitesten links liegenden) Bestellanforderungen haben.

1045 Zugriff verweigert

Siehe die Diskussionen unter "GRANT" und "Wiederherstellen des Root-Passworts".

1236 "unmögliche Position" in der Replikation

Normalerweise bedeutet dies, dass der Master abgestürzt ist und dass sync_binlog war. Die Lösung ist, CHANGE MASTER to POS=0 der nächsten Binlog-Datei (siehe Master) auf dem Slave zu ändern.

Die Ursache: Der Master sendet Replikationselemente an den Slave, bevor er in sein Binlog gespült wird (wenn sync_binlog=OFF ). Wenn der Master vor dem Flush abstürzt, ist der Slave bereits logisch am Ende der Datei im Binlog vorbeigefahren. Wenn der Master erneut startet, startet er ein neues Binlog. Daher ist das Wechseln an den Anfang des Binlog die beste verfügbare Lösung.

Eine längerfristige Lösung ist sync_binlog=ON , wenn Sie sich die zusätzlichen E / A leisten können, die dadurch verursacht werden.

(Wenn Sie mit GTID laufen, ...?)

2002, 2003 Verbindung kann nicht hergestellt werden

Prüfen Sie, ob ein Firewall-Problem den Port 3306 blockiert.

Einige mögliche Diagnosen und / oder Lösungen

• Läuft der Server tatsächlich?
• "service firewalld stop" und "systemctl disable firewalld"
• Telnet-Master 3306
• Überprüfen Sie die bind-address
• Überprüfen Sie das skip-name-resolve
• Überprüfen Sie die Steckdose.

1067, 1292, 1366, 1411 - Ungültiger Wert für Anzahl, Datum, Standard usw.

1067 Dies hängt wahrscheinlich mit den TIMESTAMP , die sich im Laufe der Zeit geändert haben. Siehe TIMESTAMP defaults auf der Seite Datum & TIMESTAMP defaults . (was es noch nicht gibt)

1292/1366 DOUBLE / Integer Auf Buchstaben oder andere Syntaxfehler prüfen . Stellen Sie sicher, dass die Spalten ausgerichtet sind. Vielleicht denken Sie, Sie stecken in einem VARCHAR aber es ist an einer numerischen Spalte ausgerichtet.

1292 DATETIME In der Vergangenheit oder in der Zukunft zu weit geprüft . Überprüfen Sie zwischen 2 Uhr morgens und 3 Uhr morgens an einem Morgen, wenn sich die Sommerzeit geändert hat. Überprüfen Sie, +00 Syntax fehlerhaft ist, z. B. +00 Zeitzonen.

1292 VARIABLE Überprüfen Sie die zulässigen Werte für die VARIABLE Sie VARIABLE SET .

1292 LOAD DATA Schauen Sie sich die Zeile an, die 'bad' ist. Überprüfen Sie die Escape-Symbole usw. Schauen Sie sich die Datentypen an.

1411 STR_TO_DATE Datum falsch formatiert?

126, 127, 134, 144, 145

Wenn Sie versuchen, auf die Datensätze aus der MySQL-Datenbank zuzugreifen, erhalten Sie möglicherweise diese Fehlermeldungen. Diese Fehlermeldungen sind auf eine Beschädigung der MySQL-Datenbank zurückzuführen. Es folgen die Typen

MySQL error code 126 = Index file is crashed
MySQL error code 127 = Record-file is crashed
MySQL error code 134 = Record was already deleted (or record file crashed)
MySQL error code 144 = Table is crashed and last repair failed
MySQL error code 145 = Table was marked as crashed and should be repaired

MySQL-Fehler, Virenbefall, Serverabsturz, fehlerhaftes Herunterfahren, beschädigte Tabelle sind der Grund für diese Beschädigung. Wenn es beschädigt wird, ist es nicht mehr zugänglich und Sie können nicht mehr darauf zugreifen. Um Zugang zu erhalten, ist der beste Weg, um Daten aus einer aktualisierten Sicherung abzurufen. Wenn Sie jedoch keine aktualisierte oder gültige Sicherung haben, können Sie sich für MySQL Repair entscheiden.

Wenn der Tabellen-Engine-Typ MyISAM , wenden Sie CHECK TABLE und dann REPAIR TABLE an.

Denken Sie dann ernsthaft über die Umstellung auf InnoDB nach, damit dieser Fehler nicht mehr auftritt.

Syntax

CHECK TABLE <table name> ////To check the extent of database corruption
REPAIR TABLE <table name> ////To repair table

139

Fehler 139 kann bedeuten, dass die Anzahl und Größe der Felder in der Tabellendefinition einen gewissen Grenzwert überschreitet. Problemumgehungen:

• Überdenken Sie das Schema erneut
• Normalisieren Sie einige Felder
• Partitionieren Sie die Tabelle vertikal

1366

Dies bedeutet normalerweise, dass die Behandlung von Zeichensätzen zwischen Client und Server nicht konsistent war. Siehe ... für weitere Unterstützung.

126, 1054, 1146, 1062, 24

(Pause) Mit der Einbeziehung dieser 4 Fehlernummern denke ich, dass diese Seite ungefähr 50% der typischen Fehler abgedeckt hat, die Benutzer erhalten.

(Ja, dieses 'Beispiel' muss überarbeitet werden.)

24 Datei kann nicht geöffnet werden (zu viele geöffnete Dateien)

open_files_limit kommt von einer Betriebssystemeinstellung. table_open_cache muss kleiner sein.

Diese können diesen Fehler verursachen:

• Fehler beim DEALLOCATE PREPARE in einer gespeicherten Prozedur.

• PARTITIONed-Tabelle (n) mit einer großen Anzahl von Partitionen und innodb_file_per_table = ON. Es sollte empfohlen werden, nicht mehr als 50 Partitionen in einer Tabelle zu haben (aus verschiedenen Gründen). (Wenn "native Partitionen" verfügbar werden, kann sich dieser Hinweis ändern.)

Die offensichtliche Problemumgehung besteht darin, das Betriebssystem-Limit zu erhöhen: Um mehr Dateien zuzulassen, ändern Sie ulimit oder /etc/security/limits.conf oder in sysctl.conf (kern.maxfiles & kern.maxfilesperproc) oder etwas anderes (vom Betriebssystem abhängig). Erhöhen open_files_limit dann open_files_limit und table_open_cache .

Seit 5.6.8 hat open_files_limit basierend auf max_connections automatische max_connections , es ist jedoch in Ordnung, die Standardeinstellung zu ändern.

1062 - Doppelter Eintrag

Dieser Fehler tritt hauptsächlich aus den folgenden zwei Gründen auf

1. Doppelter Wert - Error Code: 1062. Duplicate entry '12' for key 'PRIMARY'

   Die Primärschlüsselspalte ist eindeutig und akzeptiert den doppelten Eintrag nicht. Wenn Sie also versuchen, eine neue Zeile einzufügen, die bereits in Ihrer Tabelle vorhanden ist, wird dieser Fehler ausgegeben.

Um dieses AUTO_INCREMENT zu lösen, legen Sie die Primärschlüsselspalte als AUTO_INCREMENT . Wenn Sie versuchen, eine neue Zeile einzufügen, ignorieren Sie die Primärschlüsselspalte oder fügen Sie einen NULL Wert in den Primärschlüssel ein.

CREATE TABLE userDetails(
  userId INT(10) NOT NULL AUTO_INCREMENT,
  firstName VARCHAR(50),
  lastName VARCHAR(50),
  isActive INT(1) DEFAULT 0,
  PRIMARY KEY (userId) );

--->and now while inserting 
INSERT INTO userDetails VALUES (NULL ,'John', 'Doe', 1);

2. Eindeutiges Datenfeld - Error Code: 1062. Duplicate entry 'A' for key 'code'

   Sie können eine Spalte als eindeutig zuweisen. Wenn Sie versuchen, eine neue Zeile mit bereits vorhandenem Wert für diese Spalte einzufügen, wird dieser Fehler ausgegeben.

Um diesen Fehler zu INSERT IGNORE , verwenden Sie INSERT IGNORE anstelle des normalen INSERT . Wenn die neue Zeile, die Sie einzufügen versuchen, einen vorhandenen Datensatz nicht dupliziert, fügt MySQL diesen wie gewohnt ein. Wenn der Datensatz ein Duplikat ist, wird er vom IGNORE Schlüsselwort IGNORE , ohne dass ein Fehler generiert wird.

INSERT IGNORE INTO userDetails VALUES (NULL ,'John', 'Doe', 1);