Ошибка 1022 - Не могу написать; дубликат ключа в таблице

Я получаю сообщение об ошибке 1022 относительно дубликатов ключей в команде создания таблицы. Посмотрев на запрос, я не могу понять, где происходит дублирование. Кто-нибудь еще может это увидеть?

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' 

Скорее всего, у вас уже есть ограничение с именем iduserили idcategoryв вашей базе данных. Просто переименуйте ограничения, если так.

Ограничения должны быть уникальными для всей базы данных, а не только для конкретной таблицы, которую вы создаете / изменяете.

Чтобы узнать, где в настоящее время используются ограничения, вы можете использовать следующий запрос:

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

Измените имя внешнего ключа в MySQL. Вы не можете иметь одинаковые имена внешних ключей в таблицах базы данных.

Проверьте все свои таблицы и все ваши внешние ключи и избегайте использования двух внешних ключей с одинаковым точным именем.

Из двух ссылок « Решено успешно» и « Соглашение об именах» я легко решил ту же проблему, с которой столкнулся. т. е. для имени внешнего ключа укажите как fk _colName_ TableName . Это соглашение об именах не является двусмысленным и также делает каждый ForeignKey в вашей модели БД уникальным, и вы никогда не получите эту ошибку.

Ошибка 1022: не могу написать; дубликат ключа в таблице

Как уже упоминали другие, возможно, что имя для вашего ограничения уже используется другой таблицей в вашей БД . Они должны быть уникальными по всей базе данных.

Хорошее соглашение для именования ограничений внешнего ключа:

fk_TableName_ColumnName

Чтобы выяснить, возможно ли столкновение, вы можете перечислить все ограничения, используемые вашей базой данных, с помощью этого запроса:

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

Запустив этот запрос, я обнаружил, что ранее создал временную копию таблицы, и эта копия уже использовала имя ограничения, которое я пытался использовать.

Я просто провел последние 4 часа с той же проблемой. Я просто убедился, что ограничения имеют уникальные имена.

Вы можете переименовать ограничения. Я добавил номер к своему, чтобы я мог легко отследить количество случаев.

пример

Если ограничение в таблице называется boy с внешним ключом X Следующее ограничение с внешним ключом X может называться boy1

Я уверен, что ты найдешь лучшие имена, чем я. 🙂

Это также может возникнуть в связи с ошибкой в ​​некоторых версиях онлайн-инструмента изменения схемы Percona Toolkit. Чтобы изменить большую таблицу, pt-osc сначала создает дублирующую таблицу и копирует в нее все записи. При некоторых обстоятельствах некоторые версии pt-osc 2.2.x будут пытаться присвоить ограничениям для новой таблицы те же имена, что и ограничениям для старой таблицы.

Исправление было выпущено в 2.3.0.

См. Https://bugs.launchpad.net/percona-toolkit/+bug/1498128 для получения дополнительной информации.

Я также столкнулся с этой проблемой. Проверьте, если имя базы данных уже существует в Mysql, и переименуйте старое.

У меня была эта проблема при создании новой таблицы. Оказывается, имя внешнего ключа, которое я дал, уже использовалось. Переименование ключа исправило это.