MySQL
Foutcodes

Foutcode 1064: Syntaxisfout

select LastName, FirstName,
from Person

Retourneert bericht:

Foutcode: 1064. Er is een fout opgetreden in uw SQL-syntaxis; raadpleeg de handleiding die overeenkomt met uw MySQL-serverversie voor de juiste syntax om te gebruiken in de buurt van 'from Person' op regel 2.

Als u een "1064-foutmelding" van MySQL ontvangt, kan de query niet worden geparseerd zonder syntaxisfouten. Met andere woorden, het kan de vraag niet begrijpen.

Het citaat in het foutbericht begint met het eerste teken van de query dat MySQL niet kan achterhalen hoe te parseren. In dit voorbeeld kan MySQL in context geen betekenis hebben van from Person . In dit geval is er een extra komma direct vóór from Person . De komma vertelt MySQL om een andere kolombeschrijving in de SELECT clausule te verwachten

Een syntaxisfout zegt altijd ... near '...' . Het ding aan het begin van de aanhalingstekens is heel dichtbij waar de fout is. Om een fout te vinden, kijkt u naar het eerste token in de aanhalingstekens en naar het laatste token vóór de aanhalingstekens.

Soms kom je ... near '' ; dat wil zeggen, niets in de citaten. Dat betekent dat het eerste teken dat MySQL niet kan achterhalen, precies aan het einde of het begin van de verklaring staat. Dit suggereert dat de query onevenwichtige aanhalingstekens ( ' of " ) of onevenwichtige haakjes bevat of dat u de instructie niet eerder correct hebt beëindigd.

In het geval van een opgeslagen routine bent u misschien vergeten DELIMITER correct te gebruiken.

Als u dus Error 1064 krijgt, kijk dan naar de tekst van de query en zoek het punt dat in het foutbericht wordt vermeld. Inspecteer de tekst van de query visueel rond dat punt.

Als u iemand vraagt om u te helpen bij het oplossen van fout 1064, is het het beste om zowel de tekst van de hele query als de tekst van het foutbericht op te geven.

Foutcode 1175: Veilige update

Deze fout verschijnt tijdens het bijwerken of verwijderen van records zonder de WHERE clausule op te nemen die de KEY kolom gebruikt.

Om het verwijderen of toch bijwerken uit te voeren, typt u:

SET SQL_SAFE_UPDATES = 0;

Typ het volgende om de veilige modus weer in te schakelen:

SET SQL_SAFE_UPDATES = 1;

Foutcode 1215: kan geen externe sleutelbeperking toevoegen

Deze fout treedt op wanneer tabellen niet voldoende zijn gestructureerd om de snelle opzoekverificatie van Foreign Key ( FK ) -vereisten af te handelen die de ontwikkelaar verplicht stelt.

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;

Opmerking 1: een SLEUTEL als deze wordt indien nodig automatisch gemaakt vanwege de FK-definitie in de regel die erop volgt. De ontwikkelaar kan het overslaan en de KEY (aka-index) wordt indien nodig toegevoegd. Een voorbeeld dat het wordt overgeslagen door de ontwikkelaar, wordt hieronder in een someOther .

Tot zover goed, tot de onderstaande oproep.

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;

Foutcode: 1215. Kan geen externe sleutelbeperking toevoegen

In dit geval is het niet te wijten aan het ontbreken van een index in de tabel waarnaar wordt verwezen getTogethers aan de snelle lookup van een handvat eventDT . Op te lossen in de volgende verklaring.

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

Tabel getTogethers is aangepast, en nu zal het maken van een aantal someOther slagen.

Van de MySQL Manual-pagina FOREIGN KEY Beperkingen gebruiken :

MySQL vereist indexen op buitenlandse sleutels en sleutels waarnaar wordt verwezen, zodat controles van buitenlandse sleutels snel kunnen zijn en geen tabelscan nodig is. In de referentietabel moet er een index zijn waarin de kolommen met de externe sleutel worden weergegeven als de eerste kolommen in dezelfde volgorde. Een dergelijke index wordt automatisch in de referentietabel gemaakt als deze niet bestaat.

Overeenkomstige kolommen in de externe sleutel en de sleutel waarnaar wordt verwezen, moeten vergelijkbare gegevenstypen hebben. De grootte en het teken van gehele typen moeten hetzelfde zijn. De lengte van snaartypes hoeft niet hetzelfde te zijn. Voor niet-bindende (teken) tekenreekskolommen moeten de tekenset en sortering hetzelfde zijn.

InnoDB staat een externe sleutel toe om naar elke indexkolom of groep kolommen te verwijzen. In de tabel waarnaar wordt verwezen, moet er echter een index zijn waarin de kolommen waarnaar wordt verwezen als de eerste kolommen in dezelfde volgorde worden vermeld.

Merk op dat het laatste punt hierboven over de eerste (meest linkse) kolommen en het ontbreken van een primaire sleutelvereiste (hoewel sterk geadviseerd).

Bij het succesvol maken van een referentietabel (onderliggende), zijn alle sleutels die automatisch voor u zijn gemaakt, zichtbaar met een opdracht als:

SHOW CREATE TABLE someOther;

Andere veel voorkomende gevallen van deze fout zijn, zoals hierboven vermeld in de documentatie, maar moeten worden benadrukt:

• Schijnbaar triviale verschillen in INT die is ondertekend, wijzend naar INT UNSIGNED .

• Ontwikkelaars hebben problemen met het begrijpen van KEYS met meerdere kolommen (samengestelde) en eerste (meest linkse) bestelvereisten.

1045 Toegang geweigerd

Zie discussies in "GRANT" en "Root-wachtwoord herstellen".

1236 "onmogelijke positie" in replicatie

Meestal betekent dit dat de Master is gecrasht en dat sync_binlog UIT was. De oplossing is om CHANGE MASTER to POS=0 te CHANGE MASTER to POS=0 van het volgende binlog-bestand (zie de Master) op de Slave.

De oorzaak: de Master verzendt replicatie-items naar de Slave voordat deze naar zijn binlog wordt gespoeld (wanneer sync_binlog=OFF ). Als de Master crasht vóór de flush, is de Slave logisch al voorbij het einde van het bestand op de binlog gegaan. Wanneer de Master opnieuw opstart, start deze een nieuwe binlog, dus VERANDEREN naar het begin van die binlog is de best beschikbare oplossing.

Een oplossing op langere termijn is sync_binlog=ON , als u de extra I / O kunt betalen die het veroorzaakt.

(Als u met GTID werkt, ...?)

2002, 2003 Kan geen verbinding maken

Controleer op een firewallprobleem dat poort 3306 blokkeert.

Enkele mogelijke diagnoses en / of oplossingen

• Is de server daadwerkelijk actief?
• "service firewalld stop" en "systemctl firewalld uitschakelen"
• telnet-master 3306
• Controleer het bind-address
• vink skip-name-resolve
• controleer het stopcontact.

1067, 1292, 1366, 1411 - Ongeldige waarde voor nummer, datum, standaard, etc.

1067 Dit heeft waarschijnlijk te TIMESTAMP standaardwaarden van TIMESTAMP , die in de loop van de tijd zijn veranderd. Zie TIMESTAMP defaults op de pagina Datums en tijden. (die nog niet bestaat)

1292/1366 DOUBLE / Geheel getal Controleer op letters of andere syntaxisfouten. Controleer of de kolommen zijn uitgelijnd; misschien denk je dat je in een VARCHAR zet, maar het is uitgelijnd met een numerieke kolom.

1292 DATETIME Controleer te ver in het verleden of de toekomst. Controleer op een ochtend tussen 02.00 en 03.00 uur wanneer de zomertijd is gewijzigd. Controleer op slechte syntaxis, zoals dingen van +00 tijdzone.

1292 VARIABLE Controleer de toegestane waarden voor de VARIABLE u probeert te SET .

1292 LAAD GEGEVENS Kijk naar de regel die 'slecht' is. Controleer de escape-symbolen, enz. Kijk naar de gegevenstypen.

1411 STR_TO_DATE Onjuist opgemaakte datum?

126, 127, 134, 144, 145

Wanneer u toegang probeert te krijgen tot de records uit de MySQL-database, kunnen deze foutmeldingen verschijnen. Deze foutmeldingen zijn opgetreden vanwege corruptie in de MySQL-database. Hieronder volgen de 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-bug, virusaanval, servercrash, onjuist afsluiten, beschadigde tafel zijn de reden achter deze corruptie. Wanneer het beschadigd raakt, is het ontoegankelijk en hebt u geen toegang meer tot hen. Om toegankelijkheid te krijgen, de beste manier om gegevens op te halen uit een bijgewerkte back-up. Als u echter geen bijgewerkte of geldige back-up hebt, kunt u terecht voor MySQL-reparatie.

Als het type MyISAM , past u CHECK TABLE en vervolgens REPAIR TABLE erop.

Denk dan serieus na over de conversie naar InnoDB, zodat deze fout niet meer zal voorkomen.

Syntaxis

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

139

Fout 139 kan betekenen dat het aantal en de grootte van de velden in de tabeldefinitie een limiet overschrijdt. oplossingen:

• Denk opnieuw aan het schema
• Normaliseer sommige velden
• Verdeel de tafel verticaal

1366

Dit betekent meestal dat de tekensetverwerking niet consistent was tussen client en server. Zie ... voor meer hulp.

126, 1054, 1146, 1062, 24

(pauze nemen) Met de opname van die 4 foutnummers denk ik dat deze pagina ongeveer 50% van de typische fouten die gebruikers krijgen, heeft behandeld.

(Ja, dit 'Voorbeeld' moet worden herzien.)

24 Kan bestand niet openen (Te veel geopende bestanden)

open_files_limit komt van een OS-instelling. table_open_cache moet kleiner zijn dan dat.

Deze kunnen die fout veroorzaken:

• DEALLOCATE PREPARE niet DEALLOCATE PREPARE in een opgeslagen procedure.

• GEWIJZIGDE tabel (len) met een groot aantal partities en innodb_file_per_table = ON. Aanbevolen om niet meer dan 50 partities in een bepaalde tabel te hebben (om verschillende redenen). (Wanneer "Native Partitions" beschikbaar komen, kan dit advies veranderen.)

De voor de hand liggende oplossing is om de OS-limiet in te stellen: om meer bestanden toe te staan, wijzigt ulimit of /etc/security/limits.conf of in sysctl.conf (kern.maxfiles & kern.maxfilesperproc) of iets anders (afhankelijk van het besturingssysteem). Verhoog vervolgens open_files_limit en table_open_cache .

Met ingang van 5.6.8, open_files_limit wordt automatisch verkleind op basis max_connections , maar het OK is om het te veranderen van de standaard.

1062 - Dubbele invoer

Deze fout treedt voornamelijk op vanwege de volgende twee redenen

1. Dubbele waarde - Error Code: 1062. Duplicate entry '12' for key 'PRIMARY'

   De primaire-sleutelkolom is uniek en accepteert geen dubbele invoer. Dus wanneer u probeert een nieuwe rij in te voegen die al in uw tabel aanwezig is, zal deze fout optreden.

Om dit op te lossen, stelt u de primaire sleutelkolom in op AUTO_INCREMENT . En wanneer u probeert een nieuwe rij in te voegen, negeert u de kolom met de primaire sleutel of voegt u NULL waarde in de primaire sleutel in.

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. Uniek gegevensveld - Error Code: 1062. Duplicate entry 'A' for key 'code'

   U kunt een kolom als uniek toewijzen en proberen een nieuwe rij met een reeds bestaande waarde voor die kolom in te voegen, zal deze fout veroorzaken.

Gebruik INSERT IGNORE plaats van de normale INSERT om deze fout te verhelpen. Als de nieuwe rij die u probeert in te voegen een bestaand record niet dupliceert, voegt MySQL het zoals gewoonlijk in. Als het record een duplicaat is, verwijdert het trefwoord IGNORE het zonder een fout te genereren.

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