MySQL
Codici di errore

Codice errore 1064: errore di sintassi

select LastName, FirstName,
from Person

Restituisce il messaggio:

Codice di errore: 1064. Si è verificato un errore nella sintassi SQL; controlla il manuale che corrisponde alla tua versione del server MySQL per la sintassi corretta da usare vicino a 'da Persona' alla riga 2.

Ottenere un messaggio "1064 error" da MySQL significa che la query non può essere analizzata senza errori di sintassi. In altre parole, non può dare un senso alla query.

La citazione nel messaggio di errore inizia con il primo carattere della query che MySQL non riesce a capire come analizzare. In questo esempio MySQL non ha senso, nel contesto, di from Person . In questo caso, c'è una virgola extra immediatamente prima from Person . La virgola indica a MySQL di aspettarsi un'altra descrizione di colonna nella clausola SELECT

Un errore di sintassi dice sempre ... near '...' . La cosa all'inizio delle virgolette è molto vicina a dove si trova l'errore. Per individuare un errore, guarda il primo token tra virgolette e all'ultimo token prima delle virgolette.

A volte avrai ... near '' ; cioè, niente tra virgolette. Ciò significa che il primo carattere che MySQL non riesce a capire è proprio alla fine o all'inizio della dichiarazione. Ciò suggerisce che la query contiene virgolette non bilanciate ( ' o " ) o parentesi non bilanciate o che non hai terminato correttamente la dichiarazione.

Nel caso di una Stored Routine, potresti aver dimenticato di usare correttamente DELIMITER .

Quindi, quando ottieni l'errore 1064, guarda il testo della query e trova il punto menzionato nel messaggio di errore. Controlla visivamente il testo della query proprio intorno a quel punto.

Se chiedi a qualcuno di aiutarti a risolvere l'errore 1064, è meglio fornire sia il testo dell'intera query sia il testo del messaggio di errore.

Codice errore 1175: Aggiornamento sicuro

Questo errore viene visualizzato durante il tentativo di aggiornare o eliminare i record senza includere la clausola WHERE che utilizza la colonna KEY .

Per eseguire comunque l'eliminazione o l'aggiornamento, digitare:

SET SQL_SAFE_UPDATES = 0;

Per attivare nuovamente la modalità provvisoria, digita:

SET SQL_SAFE_UPDATES = 1;

Codice errore 1215: impossibile aggiungere un vincolo di chiave esterna

Questo errore si verifica quando le tabelle non sono strutturate in modo adeguato per gestire la verifica rapida dei requisiti FK (Foreign Key) richiesti dallo sviluppatore.

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;

Nota 1: un KEY come questo verrà creato automaticamente se necessario a causa della definizione FK nella riga che lo segue. Lo sviluppatore può saltarlo e la KEY (nota anche come indice) verrà aggiunta se necessario. Un esempio di esso che viene saltato dallo sviluppatore è mostrato sotto in someOther .

Fin qui tutto bene, fino alla chiamata di sotto.

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;

Codice errore: 1215. Impossibile aggiungere un vincolo di chiave esterna

In questo caso fallisce a causa della mancanza di un indice nella tabella di riferimento getTogethers per gestire la rapida ricerca di un eventDT . Per essere risolto nella prossima dichiarazione.

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

Table getTogethers è stato modificato e ora la creazione di someOther avrà successo.

Dalla pagina del manuale MySQL usando i vincoli FOREIGN KEY :

MySQL richiede indici su chiavi esterne e chiavi di riferimento in modo che i controlli delle chiavi esterne possano essere veloci e non richiedere una scansione della tabella. Nella tabella di riferimento, deve esistere un indice in cui le colonne chiave esterna sono elencate come prime colonne nello stesso ordine. Tale indice viene creato automaticamente sulla tabella di riferimento se non esiste.

Le colonne corrispondenti nella chiave esterna e la chiave di riferimento devono avere tipi di dati simili. La dimensione e il segno dei tipi interi devono essere uguali. La lunghezza dei tipi di stringa non deve essere la stessa. Per le colonne di stringa non binarie (carattere), il set di caratteri e le regole di confronto devono essere uguali.

InnoDB consente a una chiave esterna di fare riferimento a qualsiasi colonna di indice o gruppo di colonne. Tuttavia, nella tabella di riferimento, deve esistere un indice in cui le colonne di riferimento sono elencate come prime colonne nello stesso ordine.

Si noti che l'ultimo punto sopra riguarda le prime (a sinistra) colonne e la mancanza di un requisito di chiave primaria (sebbene altamente consigliato).

Dopo aver creato correttamente una tabella di riferimento (figlio), tutte le chiavi che sono state create automaticamente per te sono visibili con un comando come il seguente:

SHOW CREATE TABLE someOther;

Altri casi comuni di questo errore includono, come menzionato sopra, ma dovrebbero essere evidenziati:

• Differenze apparentemente banali in INT che è firmata, che punta verso INT UNSIGNED .

• Sviluppatori che hanno difficoltà a comprendere i KEY a più colonne (compositi) e i primi requisiti di ordinazione (a sinistra).

1045 Accesso negato

Vedi le discussioni in "GRANT" e "Recovering root password".

1236 "posizione impossibile" nella replica

Di solito questo significa che il Master è sync_binlog crash e che sync_binlog era OFF. La soluzione è CHANGE MASTER to POS=0 del prossimo file binlog (vedere Master) sullo Slave.

La causa: il Master invia elementi di replica allo Slave prima di eseguire il flushing al suo binlog (quando sync_binlog=OFF ). Se il Master si blocca prima del flush, lo Slave ha già spostato logicamente la fine del file sul binlog. Quando il Master si riavvia, avvia un nuovo binlog, quindi CAMBIARE all'inizio di quel binlog è la migliore soluzione disponibile.

Una soluzione a lungo termine è sync_binlog=ON , se puoi permetterti l'I / O extra che causa.

(Se stai utilizzando GTID, ...?)

2002, 2003 Impossibile connettersi

Verificare la presenza di un problema del firewall che blocca la porta 3306.

Alcune possibili diagnosi e / o soluzioni

• Il server è effettivamente in esecuzione?
• "service firewalld stop" e "systemctl disable firewalld"
• telnet master 3306
• Controlla l' bind-address
• controlla skip-name-resolve
• controlla la presa.

1067, 1292, 1366, 1411 - Valore errato per numero, data, valore predefinito, ecc.

1067 Questo è probabilmente correlato ai valori predefiniti di TIMESTAMP , che sono cambiati nel tempo. Vedi i TIMESTAMP defaults nella pagina Date e orari. (che non esiste ancora)

1292/1366 DOUBLE / Integer Verifica la presenza di lettere o altri errori di sintassi. Verifica che le colonne siano allineate; forse pensi che stai mettendo in un VARCHAR ma è allineato con una colonna numerica.

1292 DATETIME Controlla troppo nel passato o nel futuro. Controlla tra le 2:00 e le 3:00 di mattina quando è stato modificato il risparmio di luce diurna. Verifica la sintassi errata, ad esempio +00 fuso orario.

1292 VARIABLE Verificare i valori consentiti per la VARIABLE si sta tentando di SET .

1292 CARICHI DATI Guarda la linea che è "cattiva". Controlla i simboli di fuga, ecc. Guarda i tipi di dati.

1411 STR_TO_DATE Data di formattazione errata?

126, 127, 134, 144, 145

Quando provi ad accedere ai record dal database MySQL, potresti ricevere questi messaggi di errore. Questi messaggi di errore si sono verificati a causa della corruzione nel database MySQL. Di seguito sono riportati i tipi

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

Bug di MySQL, attacco di virus, crash del server, arresto improprio, tabella danneggiata sono la causa di questa corruzione. Quando viene danneggiato, diventa inaccessibile e non è più possibile accedervi. Per ottenere l'accessibilità, il modo migliore per recuperare i dati da un backup aggiornato. Tuttavia, se non si dispone di un backup aggiornato o di un backup valido, è possibile utilizzare MySQL Repair.

Se il tipo di motore tabella è MyISAM , applicare CHECK TABLE , quindi REPAIR TABLE su di esso.

Quindi pensa seriamente alla conversione in InnoDB, quindi questo errore non si ripeterà più.

Sintassi

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

139

L'errore 139 può significare che il numero e la dimensione dei campi nella definizione della tabella superano alcuni limiti. soluzioni alternative:

• Rifletti lo schema
• Normalizza alcuni campi
• Partizionare verticalmente la tabella

1366

Questo di solito significa che la gestione del set di caratteri non era coerente tra client e server. Vedi ... per ulteriore assistenza.

126, 1054, 1146, 1062, 24

(prendersi una pausa) Con l'inclusione di quei 4 numeri di errore, penso che questa pagina avrà coperto circa il 50% degli errori tipici che gli utenti ottengono.

(Sì, questo 'Esempio' necessita di revisione.)

24 Impossibile aprire il file (Troppi file aperti)

open_files_limit proviene da un'impostazione del sistema operativo. table_open_cache deve essere inferiore a quello.

Questi possono causare quell'errore:

• Mancato DEALLOCATE PREPARE in una stored procedure.

• Tabelle PARTITIONed con un gran numero di partizioni e innodb_file_per_table = ON. Consiglia di non avere più di 50 partizioni in una data tabella (per vari motivi). (Quando "Native Partitions" diventa disponibile, questo consiglio può cambiare).

L'ovvia soluzione è di aumentare il limite del sistema operativo: per consentire più file, modificare ulimit o /etc/security/limits.conf o in sysctl.conf (kern.maxfiles e kern.maxfilesperproc) o qualcos'altro (dipendente dal sistema operativo). Quindi aumenta open_files_limit e table_open_cache .

A partire da 5.6.8, open_files_limit è dimensionato automaticamente in base a max_connections , ma è OK cambiarlo dal valore predefinito.

1062 - Inserimento duplicato

Questo errore si verifica principalmente a causa dei seguenti due motivi

1. Valore duplicato - Error Code: 1062. Duplicate entry '12' for key 'PRIMARY'

   La colonna della chiave primaria è unica e non accetta la voce duplicata. Quindi, quando stai provando ad inserire una nuova riga che è già presente nella tua tabella, produrrà questo errore.

Per risolvere questo, impostare la colonna chiave primaria come AUTO_INCREMENT . E quando stai provando ad inserire una nuova riga, ignora la colonna della chiave primaria o inserisci il valore NULL sulla chiave primaria.

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

   È possibile assegnare una colonna come univoca e provare a inserire una nuova riga con un valore già esistente per quella colonna produrrà questo errore.

Per superare questo errore, usa INSERT IGNORE invece di INSERT normale. Se la nuova riga che stai tentando di inserire non duplica un record esistente, MySQL lo inserisce come al solito. Se il record è un duplicato, la parola chiave IGNORE lo IGNORE senza generare alcun errore.

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