MySQL
Codes d'erreur

Code d'erreur 1064: erreur de syntaxe

select LastName, FirstName,
from Person

Renvoie un message:

Code d'erreur: 1064. Vous avez une erreur dans votre syntaxe SQL; Consultez le manuel correspondant à votre version du serveur MySQL pour connaître la syntaxe appropriée à utiliser près de 'from Person' à la ligne 2.

Obtenir un message d'erreur "1064" de MySQL signifie que la requête ne peut pas être analysée sans erreurs de syntaxe. En d'autres termes, il ne peut pas donner de sens à la requête.

La citation dans le message d'erreur commence par le premier caractère de la requête que MySQL ne peut pas comprendre. Dans cet exemple, MySQL n'a pas de sens, en contexte, from Person . Dans ce cas, il y a une virgule supplémentaire immédiatement avant from Person . La virgule dit à MySQL d'attendre une autre description de colonne dans la clause SELECT

Une erreur de syntaxe dit toujours ... near '...' . La chose au début des guillemets est très proche de l'erreur. Pour localiser une erreur, examinez le premier jeton entre guillemets et le dernier jeton avant les guillemets.

Parfois, vous allez ... near '' c'est-à-dire rien dans les citations. Cela signifie que le premier caractère que MySQL ne comprend pas est à la fin ou au début de l'instruction. Cela suggère que la requête contient des citations non équilibrées ( ' ou " ) ou des parenthèses non équilibrées ou que vous n’avez pas terminé l’instruction correctement avant.

Dans le cas d'une routine stockée, vous avez peut-être oublié d'utiliser DELIMITER .

Ainsi, lorsque vous obtenez l'erreur 1064, examinez le texte de la requête et recherchez le point mentionné dans le message d'erreur. Inspectez visuellement le texte de la requête juste autour de ce point.

Si vous demandez à quelqu'un de vous aider à résoudre l'erreur 1064, il est préférable de fournir à la fois le texte de la requête entière et le texte du message d'erreur.

Code d'erreur 1175: Mise à jour sécurisée

Cette erreur apparaît lors de la tentative de mise à jour ou de suppression des enregistrements sans inclure la clause WHERE qui utilise la colonne KEY .

Pour exécuter la suppression ou la mise à jour de toute façon - tapez:

SET SQL_SAFE_UPDATES = 0;

Pour réactiver le mode sans échec - tapez:

SET SQL_SAFE_UPDATES = 1;

Code d'erreur 1215: Impossible d'ajouter une contrainte de clé étrangère

Cette erreur se produit lorsque les tables ne sont pas structurées de manière adéquate pour gérer la vérification rapide des exigences de clé étrangère ( FK ) que le développeur impose.

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;

Note 1: une KEY comme celle-ci sera créée automatiquement si nécessaire en raison de la définition FK dans la ligne qui la suit. Le développeur peut l'ignorer et le KEY (aka index) sera ajouté si nécessaire. Un exemple d’évitement par le développeur est montré ci-dessous dans une someOther .

Jusqu'ici tout va bien, jusqu'à l'appel ci-dessous.

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;

Code d'erreur: 1215. Impossible d'ajouter une contrainte de clé étrangère

Dans ce cas, il échoue en raison de l'absence d'index dans la table référencée getTogethers pour gérer la recherche rapide d'un eventDT . À résoudre dans la prochaine déclaration.

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

La table getTogethers a été modifiée et maintenant la création de someOther réussira.

À partir de la page du manuel MySQL Utilisation des contraintes FOREIGN KEY :

MySQL nécessite des index sur les clés étrangères et les clés référencées afin que les vérifications de clés étrangères puissent être rapides et ne nécessitent pas d'analyse de table. Dans la table de référence, il doit y avoir un index où les colonnes de la clé étrangère sont répertoriées comme les premières colonnes du même ordre. Un tel index est créé automatiquement sur la table de référence s'il n'existe pas.

Les colonnes correspondantes dans la clé étrangère et la clé référencée doivent avoir des types de données similaires. La taille et le signe des types entiers doivent être identiques. La longueur des types de chaîne ne doit pas nécessairement être la même. Pour les colonnes de chaîne non binaires (caractères), le jeu de caractères et le classement doivent être identiques.

InnoDB permet à une clé étrangère de référencer une colonne d'index ou un groupe de colonnes. Toutefois, dans la table référencée, il doit y avoir un index où les colonnes référencées sont répertoriées comme les premières colonnes du même ordre.

Notez le dernier point ci-dessus concernant les premières colonnes (les plus à gauche) et l’absence de condition de clé primaire (bien que fortement recommandée).

Après la création d'une table de référence (enfant), toutes les clés créées automatiquement pour vous sont visibles avec une commande telle que:

SHOW CREATE TABLE someOther;

Parmi les autres cas courants d’expérience de cette erreur, citons les documents ci-dessus, mais ils doivent être mis en évidence:

• Différences apparemment insignifiantes de l’ INT qui sont signées, pointant vers INT UNSIGNED .

• Les développeurs ont du mal à comprendre les KEYS multi-colonnes (composites) et les premières exigences de commande (les plus à gauche).

1045 Accès refusé

Voir les discussions dans "GRANT" et "Récupérer le mot de passe root".

1236 "position impossible" dans la réplication

Habituellement, cela signifie que le Master est tombé en panne et que sync_binlog était OFF. La solution est de CHANGE MASTER to POS=0 du fichier binlog suivant (voir le fichier maître) sur l’esclave.

La cause: le maître envoie les éléments de réplication à l'esclave avant de vider son binlog (quand sync_binlog=OFF ). Si le Master se bloque avant le flush, l'esclave a déjà logiquement dépassé la fin du fichier sur le binlog. Lorsque le Master redémarre, il lance un nouveau binlog. La meilleure solution est donc de changer au début de ce binlog.

Une solution à plus long terme est sync_binlog=ON , si vous pouvez vous permettre les E / S supplémentaires sync_binlog=ON .

(Si vous utilisez GTID, ...?)

2002, 2003 Impossible de se connecter

Recherchez un problème bloquant le port 3306.

Quelques diagnostics et / ou solutions possibles

• Le serveur est-il en cours d'exécution?
• "service firewalld stop" et "systemctl disable firewalld"
• telnet master 3306
• Vérifiez l' bind-address
• vérifier le skip-name-resolve
• vérifiez la prise.

1067, 1292, 1366, 1411 - Mauvaise valeur pour le nombre, la date, la valeur par défaut, etc.

1067 Ceci est probablement lié aux valeurs par défaut TIMESTAMP , qui ont changé au fil du temps. Voir TIMESTAMP defaults dans la page Dates et heures. (qui n'existe pas encore)

1292/1366 DOUBLE / Integer Recherche les lettres ou autres erreurs de syntaxe. Vérifiez que les colonnes sont alignées. vous pensez peut-être que vous mettez dans un VARCHAR mais il est aligné avec une colonne numérique.

1292 DATETIME Vérifiez trop loin dans le passé ou le futur. Vérifiez entre 2h et 3h du matin lorsque l’heure avancée a changé. Vérifiez la syntaxe incorrecte, telle que +00 éléments de fuseau horaire.

1292 VARIABLE Vérifiez les valeurs autorisées pour la VARIABLE vous essayez de SET .

1292 LOAD DATA Regardez la ligne qui est "mauvaise". Vérifiez les symboles d'échappement, etc. Regardez les types de données.

1411 STR_TO_DATE Date incorrectement formatée?

126, 127, 134, 144, 145

Lorsque vous essayez d'accéder aux enregistrements de la base de données MySQL, vous pouvez obtenir ces messages d'erreur. Ces messages d'erreur sont dus à une corruption de la base de données MySQL. Voici les types

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

Le bogue MySQL, les attaques de virus, les pannes de serveur, les arrêts incorrects, les tables endommagées sont les raisons de cette corruption. Quand il est corrompu, il devient inaccessible et vous ne pouvez plus y accéder. Afin d'obtenir l'accessibilité, le meilleur moyen de récupérer des données à partir d'une sauvegarde mise à jour. Cependant, si vous ne disposez d'aucune sauvegarde valide ou mise à jour, vous pouvez opter pour MySQL Repair.

Si le type de moteur de table est MyISAM , appliquez CHECK TABLE , puis REPAIR TABLE à celui-ci.

Alors réfléchissez sérieusement à la conversion à InnoDB, donc cette erreur ne se reproduira plus.

Syntaxe

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

139

L'erreur 139 peut signifier que le nombre et la taille des champs dans la définition de la table dépasse une certaine limite. Solutions de contournement:

• Repenser le schéma
• Normaliser certains champs
• Partitionner verticalement la table

1366

Cela signifie généralement que la gestion du jeu de caractères n'était pas cohérente entre le client et le serveur. Voir ... pour plus d'assistance.

126, 1054, 1146, 1062, 24

(en prenant une pause) Avec l'inclusion de ces 4 numéros d'erreur, je pense que cette page aura couvert environ 50% des erreurs typiques que les utilisateurs obtiennent.

(Oui, cet exemple doit être révisé.)

24 Impossible d'ouvrir le fichier (Trop de fichiers ouverts)

open_files_limit provient d'un paramètre du système d'exploitation. table_open_cache doit être inférieur à cela.

Celles-ci peuvent provoquer cette erreur:

• Échec de DEALLOCATE PREPARE dans une procédure stockée.

• Table (s) PARTITIONed avec un grand nombre de partitions et innodb_file_per_table = ON. Recommande de ne pas avoir plus de 50 partitions dans une table donnée (pour diverses raisons). (Lorsque "Native Partitions" devient disponible, ce conseil peut changer.)

La solution évidente consiste à définir augmenter la limite du système d'exploitation: Pour permettre à plus de fichiers, modifier ulimit ou /etc/security/limits.conf ou sysctl.conf (kern.maxfiles & kern.maxfilesperproc) ou autre chose (OS à charge). Augmentez ensuite open_files_limit et table_open_cache .

A partir de 5.6.8, open_files_limit est automatiquement dimensionné en fonction de max_connections , mais il est correct de le modifier par défaut.

1062 - Entrée en double

Cette erreur se produit principalement pour les deux raisons suivantes

1. Valeur en double - Error Code: 1062. Duplicate entry '12' for key 'PRIMARY'

   La colonne de clé primaire est unique et n'acceptera pas l'entrée en double. Donc, lorsque vous essayez d'insérer une nouvelle ligne qui est déjà présente dans votre table, cela produira cette erreur.

Pour résoudre ce problème, définissez la colonne de clé primaire comme AUTO_INCREMENT . Et lorsque vous essayez d'insérer une nouvelle ligne, ignorez la colonne de clé primaire ou insérez la valeur NULL dans la clé primaire.

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. Champ de données unique - Error Code: 1062. Duplicate entry 'A' for key 'code'

   Vous pouvez assigner une colonne unique et essayer d'insérer une nouvelle ligne avec une valeur déjà existante pour cette colonne produira cette erreur.

Pour surmonter cette erreur, utilisez INSERT IGNORE au lieu de INSERT normal. Si la nouvelle ligne que vous essayez d'insérer ne duplique pas un enregistrement existant, MySQL l'insère comme d'habitude. Si l'enregistrement est un doublon, le mot clé IGNORE le IGNORE sans générer d'erreur.

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