MySQL
Felkoder

Felkod 1064: Syntaxfel

select LastName, FirstName,
from Person

Returnerar meddelande:

Felkod: 1064. Du har ett fel i din SQL-syntax; kolla manualen som motsvarar din MySQL-serverversion för rätt syntax för att använda nära 'från Person' på rad 2.

Att få ett "1064-fel" -meddelande från MySQL betyder att frågan inte kan analyseras utan syntaxfel. Med andra ord kan det inte vara vettigt om frågan.

Citatet i felmeddelandet börjar med det första tecknet i frågan som MySQL inte kan ta reda på hur man ska analysera. I det här exemplet kan MySQL inte vara vettigt, i sammanhang, from Person . I det här fallet finns det en extra komma direkt from Person . Komman berättar för MySQL att förvänta sig en annan kolumnbeskrivning i SELECT klausulen

Ett syntaxfel säger alltid ... near '...' . Saken i början av citat är mycket nära var felet är. För att hitta ett fel, titta på det första tokenet i offerten och på det sista tokenet före citaten.

Ibland kommer du ... near '' ; det vill säga ingenting i citaten. Det betyder att det första tecknet som MySQL inte kan räkna ut är rätt i slutet eller i början av uttalandet. Detta antyder att frågan innehåller obalanserade citat ( ' eller " ) eller obalanserade parenteser eller att du inte avslutade uttalandet förr.

När det gäller en lagrad rutin kan du ha glömt att använda DELIMITER på rätt DELIMITER .

Så när du får fel 1064, titta på frågan och hitta den punkt som nämns i felmeddelandet. Inspektera visuellt texten på frågan precis runt den punkten.

Om du ber någon att hjälpa dig felsöka fel 1064 är det bäst att ange både texten för hela frågan och texten i felmeddelandet.

Felkod 1175: Säker uppdatering

Det här felet visas när man försöker uppdatera eller radera poster utan att inkludera WHERE klausulen som använder KEY kolumnen.

Om du vill utföra radering eller uppdatering ändå - skriv:

SET SQL_SAFE_UPDATES = 0;

För att aktivera säkert läge igen - skriv:

SET SQL_SAFE_UPDATES = 1;

Felkod 1215: Det går inte att lägga till främmande nyckelbegränsningar

Det här felet uppstår när tabeller inte är tillräckligt strukturerade för att hantera den snabba kontrollen av utländska nycklar ( FK ) som utvecklaren kräver.

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;

Obs 1: en nyckel som denna skapas automatiskt om det behövs på grund av FK-definitionen i raden som följer den. Utvecklaren kan hoppa över det och KEY (aka index) läggs till vid behov. Ett exempel på att det hoppas över av utvecklaren visas nedan i someOther .

Hittills så bra, tills nedan ringer.

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;

Felkod: 1215. Kan inte lägga till främmande nyckelbegränsningar

I detta fall misslyckas det på grund av bristen på ett index i den refererade tabellen getTogethers att hantera den snabba uppslagningen av en eventDT . Löses i nästa uttalande.

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

Tabell getTogethers har ändrats och nu kommer skapandet av someOther att lyckas.

Från MySQL Manuell sida Använda utländska nyckelbegränsningar :

MySQL kräver index på utländska nycklar och referensnycklar så att utländska nyckelkontroller kan vara snabba och inte kräva en tabellscanning. I referenstabellen måste det finnas ett index där de utländska nyckelkolumnerna listas som de första kolumnerna i samma ordning. Ett sådant index skapas automatiskt på referenstabellen om det inte finns.

Motsvarande kolumner i den främmande nyckeln och den referensnyckeln måste ha liknande datatyper. Storleken och tecknet för heltalstyper måste vara desamma. Längden på strängtyper behöver inte vara densamma. För icke-binära (tecken) strängkolumner måste teckenuppsättningen och sammanställningen vara desamma.

InnoDB tillåter en utländsk nyckel att referera till någon indexkolumn eller grupp av kolumner. I den refererade tabellen måste det dock finnas ett index där de refererade kolumnerna listas som de första kolumnerna i samma ordning.

Observera att den sista punkten ovan om de första (vänster-mest) kolumnerna och bristen på ett primärnyckelkrav (även om det är mycket rekommenderat).

Vid framgångsrik skapande av en referenstabell (underordnad) visas alla nycklar som automatiskt skapades för dig med ett kommando som följande:

SHOW CREATE TABLE someOther;

Andra vanliga fall av att uppleva detta fel inkluderar, som nämnts ovan från dokumenten, men bör markeras:

• Till synes triviala skillnader i INT som är undertecknade, pekande mot INT UNSIGNED .

• Utvecklare som har problem med att förstå flerkolumns (sammansatta) nycklar och första (vänster-mest) beställningskrav.

1045 Åtkomst nekad

Se diskussioner i "GRANT" och "Återställa root-lösenord".

1236 "omöjlig position" i replikering

Vanligtvis betyder detta att mästaren kraschade och att sync_binlog var AV. Lösningen är att CHANGE MASTER to POS=0 i nästa binlog-fil (se Master) på slaven.

Orsaken: Mästaren skickar replikeringsobjekt till slaven innan han spolar till sin binlog (när sync_binlog=OFF ). Om befälhavaren kraschar före flushen, har slaven redan logiskt flyttat förbi slutet på filen på binlog. När Mästaren startar igen startar den en ny binlog, så ÄNDRA till början av binlog är den bästa tillgängliga lösningen.

En lösning på längre sikt är sync_binlog=ON , om du har råd med den extra I / O som den orsakar.

(Om du kör med GTID, ...?)

2002, 2003 Kan inte ansluta

Kontrollera om det finns en brandväggsproblem som blockerar port 3306.

Några möjliga diagnoser och / eller lösningar

• Kör servern faktiskt?
• "service firewalld stop" och "systemctl inaktivera firewalld"
• telnet master 3306
• Kontrollera bind-address
• kontrollera skip-name-resolve
• kontrollera uttaget.

1067, 1292, 1366, 1411 - Dåligt värde för antal, datum, standard osv.

1067 Detta är förmodligen relaterat till TIMESTAMP standardvärden som har förändrats över tid. Se TIMESTAMP defaults på sidan Datum och tider. (som inte finns ännu)

1292/1366 DUBBEL / heltal Kontrollera om det finns bokstäver eller andra syntaxfel. Kontrollera att kolumnerna är i linje; kanske tror du att du lägger in en VARCHAR men den är i linje med en numerisk kolumn.

1292 DATETID Kontrollera om det är för långt i tidigare eller framtida. Kontrollera mellan 02.00 och 03.00 på morgonen när sommartid sparades. Kontrollera om det är dåligt syntax, till exempel +00 tidszon.

1292 RÖRLIG Kontrollera de tillåtna värdena för VARIABLE du försöker SET .

1292 LADDA DATA Titta på linjen som är 'dålig'. Kontrollera flygsymbolerna osv. Titta på datatyperna.

1411 STR_TO_DATE Felaktigt formaterat datum?

126, 127, 134, 144, 145

När du försöker få åtkomst till posten från MySQL-databasen kan du få dessa felmeddelanden. Dessa felmeddelanden inträffade på grund av korruption i MySQL-databasen. Följande är typerna

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-bugg, virusattack, serverkrasch, felaktig avstängning, skadad tabell är orsaken till denna korruption. När det skadas blir det oåtkomligt och du kan inte komma åt dem längre. För att få tillgänglighet är det bästa sättet att hämta data från en uppdaterad säkerhetskopia. Men om du inte har uppdaterat eller någon giltig säkerhetskopia kan du gå till MySQL Repair.

Om MyISAM är MyISAM , applicera CHECK TABLE och sedan REPAIR TABLE på den.

Tänk sedan på allvar om att konvertera till InnoDB, så detta fel kommer inte att hända igen.

Syntax

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

139

Fel 139 kan innebära att antalet och storleken på fälten i tabelldefinitionen överskrider en viss gräns. lösningar:

• Tänk om schemat
• Normalisera vissa fält
• Partitionera vertikalt bordet

1366

Detta innebär vanligtvis att hantering av teckenuppsättningar inte var konsekvent mellan klient och server. Se ... för ytterligare hjälp.

126, 1054, 1146, 1062, 24

(tar en paus) Med införandet av de fyra felnumren tror jag att den här sidan kommer att ha täckt cirka 50% av de typiska fel som användarna får.

(Ja, det här exemplet behöver revideras.)

24 Kan inte öppna filen (för många öppna filer)

open_files_limit kommer från en OS-inställning. table_open_cache måste vara mindre än så.

Dessa kan orsaka felet:

• Underlåtenhet att DEALLOCATE PREPARE i en lagrad procedur.

• PARTITIONerad tabell (er) med ett stort antal partitioner och innodb_file_per_table = ON. Rekommenderar att inte ha mer än 50 partitioner i en given tabell (av olika skäl). (När "infödda partitioner" blir tillgängliga kan det här rådet ändras.)

Den uppenbara lösningen är att ställa in öka OS-gränsen: För att tillåta fler filer, ändra ulimit eller /etc/security/limits.conf eller i sysctl.conf (kern.maxfiles & kern.maxfilesperproc) eller något annat (OS-beroende). open_files_limit och table_open_cache .

Från 5.6.8 är open_files_limit baserat på max_connections , men det är OK att ändra det från standard.

1062 - Duplicerad post

Detta fel uppstår främst på grund av följande två orsaker

1. Duplicatvärde - Error Code: 1062. Duplicate entry '12' for key 'PRIMARY'

   Den primära nyckelkolumnen är unik och den accepterar inte duplikatposten. Så när du försöker infoga en ny rad som redan finns i din tabell kommer detta fel att uppstå.

För att lösa detta, ställ in den primära nyckelskolumnen som AUTO_INCREMENT . Och när du försöker infoga en ny rad, ignorera kolumnen för primärnyckel eller infoga NULL värde i primärnyckeln.

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. Unikt datafält - Error Code: 1062. Duplicate entry 'A' for key 'code'

   Du kan tilldela en kolumn som unik och försöker infoga en ny rad med redan befintligt värde för den kolumnen kommer att skapa detta fel.

För att övervinna detta fel använder du INSERT IGNORE istället för normalt INSERT . Om den nya raden som du försöker infoga inte duplicerar en befintlig post, sätter MySQL in som vanligt. Om posten är en duplikat kommer IGNORE nyckelordet att kassera det utan att generera något fel.

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