Otrzymuję błąd 1022 dotyczący duplikatów kluczy podczas tworzenia polecenia table. Po przejrzeniu zapytania nie mogę zrozumieć, gdzie odbywa się duplikacja. Czy ktoś może to zobaczyć?
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'
ON DELETE NO ACTION
po prostu porzuciłby całe użycie klucza obcego. Chyba że masz bardzo konkretne powody, aby to zrobić.Odpowiedzi:
Najprawdopodobniej masz już ograniczenie do nazwy
iduser
lubidcategory
w bazie danych. Po prostu zmień nazwę ograniczeń, jeśli tak.Ograniczenia muszą być unikalne dla całej bazy danych, a nie tylko dla konkretnej tabeli, którą tworzysz / modyfikujesz.
Aby dowiedzieć się, gdzie są obecnie stosowane ograniczenia, możesz użyć następującego zapytania:
źródło
Zmień nazwę klucza obcego w MySQL. Nie można mieć takich samych nazw kluczy obcych w tabelach bazy danych.
Sprawdź wszystkie tabele i wszystkie klucze obce i unikaj posiadania dwóch kluczy obcych o tej samej dokładnej nazwie.
źródło
Z dwóch linków Pomyślnie rozwiązanych i konwencji nazewnictwa z łatwością rozwiązałem ten sam problem, z którym się spotkałem. czyli o nazwę klucza obcego, jak dać fk _colName_ NazwaTabeli . Ta konwencja nazewnictwa jest niejednoznaczna i sprawia, że każdy klucz zagraniczny w modelu DB jest unikalny i nigdy nie wystąpi ten błąd.
źródło
Jak wspomnieli inni, możliwe jest, że nazwa twojego ograniczenia jest już używana przez inną tabelę w twojej bazie danych . Muszą być unikalne w całej bazie danych.
Dobrą konwencją nazywania ograniczeń klucza obcego jest:
Aby sprawdzić, czy możliwe jest zderzenie, możesz wyświetlić listę wszystkich ograniczeń używanych przez bazę danych za pomocą tego zapytania:
Kiedy uruchomiłem to zapytanie, odkryłem, że wcześniej utworzyłem tymczasową kopię tabeli i ta kopia już używała nazwy ograniczenia, którego próbowałem użyć.
źródło
Właśnie spędziłem ostatnie 4 godziny z tym samym problemem. Po prostu upewniłem się, że ograniczenia mają unikalne nazwy.
Możesz zmienić nazwę ograniczeń. Dołączyłem numer do mojego, aby móc łatwo prześledzić liczbę wystąpień.
Przykład
Jeśli ograniczenie w tabeli nosi nazwę boy z kluczem obcym X, następne ograniczenie z kluczem obcym X można nazwać boy1
Jestem pewien, że wymyślisz lepsze nazwiska niż ja. 🙂
źródło
Może się to również pojawić w związku z błędem w niektórych wersjach narzędzia do zmiany schematu online Percona Toolkit. Aby zmutować dużą tabelę, pt-osc najpierw tworzy duplikat tabeli i kopiuje do niej wszystkie rekordy. W niektórych okolicznościach niektóre wersje pt-osc 2.2.x spróbują nadać ograniczeniom w nowej tabeli takie same nazwy, jak ograniczenia w starej tabeli.
Poprawka została wydana w 2.3.0.
Zobacz https://bugs.launchpad.net/percona-toolkit/+bug/1498128 więcej szczegółów.
źródło
Zetknąłem się również z tym problemem. Sprawdź, czy nazwa bazy danych już istnieje w Mysql, i zmień nazwę starej.
źródło
Miałem ten problem podczas tworzenia nowego stołu. Okazuje się, że nazwa klucza obcego, którą podałem, była już w użyciu. Naprawiono zmianę nazwy klucza.
źródło