Erreur 1022 - Impossible d'écrire; clé en double dans le tableau

218

Je reçois une erreur 1022 concernant les clés en double sur la commande create table. Après avoir examiné la requête, je ne peux pas comprendre où la duplication a lieu. Quelqu'un d'autre peut-il le voir?

SQL query:

-- -----------------------------------------------------
-- Table `apptwo`.`usercircle`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS  `apptwo`.`usercircle` (

 `idUserCircle` MEDIUMINT NOT NULL ,
 `userId` MEDIUMINT NULL ,
 `circleId` MEDIUMINT NULL ,
 `authUser` BINARY NULL ,
 `authOwner` BINARY NULL ,
 `startDate` DATETIME NULL ,
 `endDate` DATETIME NULL ,
PRIMARY KEY (  `idUserCircle` ) ,
INDEX  `iduser_idx` (  `userId` ASC ) ,
INDEX  `idcategory_idx` (  `circleId` ASC ) ,
CONSTRAINT  `iduser` FOREIGN KEY (  `userId` ) REFERENCES  `apptwo`.`user` (
`idUser`
) ON DELETE NO ACTION ON UPDATE NO ACTION ,
CONSTRAINT  `idcategory` FOREIGN KEY (  `circleId` ) REFERENCES  `apptwo`.`circle` (
`idCircle`
) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE = INNODB;

MySQL said: Documentation

#1022 - Can't write; duplicate key in table 'usercircle'

mysql

— Git-able
source

4

Si je me souviens bien, la clé primaire est toujours aussi un INDEX UNIQUE, vous devez donc supprimer l'instruction d'index unique?

— Mr47

1

ON DELETE NO ACTIONserait simplement abandonner l'utilisation complète de la clé étrangère. Sauf si vous avez des raisons très précises de le faire.

— AmazingDreams

4

@AmazingDreams Pourquoi? Il applique toujours l'intégrité référentielle. Vous seul devez supprimer les enfants vous-même. C'est plus sûr qu'une suppression en cascade où vous pourriez accidentellement supprimer de nombreuses données en supprimant un mot clé incorrect.

— GolezTrol

1

stackoverflow.com/a/5810024/1567737 Pourquoi utiliser un alias lors de l'utilisation de l'alias rend le but clair immédiatement?

— AmazingDreams

@AmazingDreams Merci pour l'astuce. J'aime aussi le débat autour de lui - il m'aide à en apprendre davantage sur les avantages et les inconvénients.

— Git-able

534

Il est fort probable que vous ayez déjà une contrainte avec le nom iduserou idcategorydans votre base de données. Renommez simplement les contraintes si c'est le cas.

Les contraintes doivent être uniques pour l'ensemble de la base de données, pas seulement pour la table spécifique que vous créez / modifiez.

Pour savoir où les contraintes sont actuellement utilisées, vous pouvez utiliser la requête suivante:

SELECT `TABLE_SCHEMA`, `TABLE_NAME`
FROM `information_schema`.`KEY_COLUMN_USAGE`
WHERE `CONSTRAINT_NAME` IN ('iduser', 'idcategory');

— Maksym Polshcha
source

15

Exactement comme tu l'as dit. De nombreuses contraintes ont été générées automatiquement avec les mêmes noms idcategory iduser dans le reste de la requête CREATE - merci pour votre aide!

— Git-able

1

Je pensais que MySQL Workbench aurait corrigé cela lors de l'exportation du script de création, mais c'est ce que j'obtiens pour "Ignorer" après l'avertissement de ce genre de chose lorsque j'ai ouvert le projet.

— SnowInferno

Merci, mec :) Cela m'aide beaucoup et maintenant ma convention pour les clés étrangères est différente et je ne peux plus rencontrer ce problème :)

Je peux le confirmer. Mais que puis-je faire si la contrainte nommée existe bien que la table référencée ait déjà été supprimée ?? Puis-je supprimer une contrainte d'une table inexistante? Je suppose que je devrais mettre à jour MySQL 5.6 vers MariaDB actuelle.

— Anse

3

Merci pour cela: les contraintes doivent être uniques pour toute la base de données

— sebasira

31

Modifiez le nom de la clé étrangère dans MySQL. Vous ne pouvez pas avoir les mêmes noms de clé étrangère dans les tables de base de données.

Vérifiez toutes vos tables et toutes vos clés étrangères et évitez d'avoir deux clés étrangères avec le même nom exact.

— Wassim Sabra
source

C'était le problème dans mon cas. Je ne l'aurais jamais deviné et tu m'as sauvé la journée. Utilisation de fk_id_1, fk_id_2 etc, maintenant. Merci.

— JackLeEmmerdeur

15

À partir des deux liens Résolu avec succès et Convention de dénomination , j'ai facilement résolu ce même problème que j'ai rencontré. c'est-à-dire, pour le nom de la clé étrangère, donnez comme fk _colName_ TableName . Cette convention de dénomination n'est pas ambiguë et rend également chaque ForeignKey de votre modèle de base de données unique et vous n'obtiendrez jamais cette erreur.

Erreur 1022: impossible d'écrire; clé en double dans le tableau

— Chandz
source

6

Comme d'autres l'ont mentionné, il est possible que le nom de votre contrainte soit déjà utilisé par une autre table de votre base de données . Ils doivent être uniques dans la base de données.

Une bonne convention pour nommer les contraintes de clé étrangère est la suivante:

fk_TableName_ColumnName

Pour rechercher s'il y a un conflit possible, vous pouvez répertorier toutes les contraintes utilisées par votre base de données avec cette requête:

SELECT * FROM information_schema.table_constraints WHERE constraint_schema = 'YOUR_DB';

Lorsque j'ai exécuté cette requête, j'ai découvert que j'avais précédemment effectué une copie temporaire d'une table et que cette copie utilisait déjà le nom de contrainte que j'essayais d'utiliser.

— Simon East
source

4

Je viens de passer les 4 dernières heures avec le même problème. Ce que j'ai fait, c'était simplement de m'assurer que les contraintes avaient des noms uniques.

Vous pouvez renommer les contraintes. J'ai ajouté un numéro au mien afin que je puisse facilement retracer le nombre d'occurrences.

Exemple

Si une contrainte dans une table est nommée boy avec une clé étrangère X La contrainte suivante avec la clé étrangère X peut être appelée boy1

Je suis sûr que tu trouverais de meilleurs noms que moi. 🙂

— Script inconnu
source

3

Cela peut également survenir en rapport avec un bogue dans certaines versions de l'outil de changement de schéma en ligne de Percona Toolkit. Pour muter une grande table, pt-osc crée d'abord une table en double et y copie tous les enregistrements. Dans certaines circonstances, certaines versions de pt-osc 2.2.x tenteront de donner aux contraintes de la nouvelle table les mêmes noms que les contraintes de l'ancienne table.

Un correctif a été publié en 2.3.0.

Voir https://bugs.launchpad.net/percona-toolkit/+bug/1498128 pour plus de détails.

— MJD
source

1

J'ai également rencontré ce problème.Vérifiez si le nom de la base de données existe déjà dans Mysql et renommez l'ancien.

1

J'ai eu ce problème lors de la création d'une nouvelle table. Il s'avère que le nom de clé étrangère que j'ai donné était déjà utilisé. Renommer la clé l'a corrigé.

— user3076750
source