Błąd MySQL 1215: Nie można dodać ograniczenia klucza obcego

Próbuję przekazać mój nowy schemat do mojego serwera db, ale nie mogę zrozumieć, dlaczego pojawia się ten błąd. Próbowałem tutaj znaleźć odpowiedź, ale wszystko, co znalazłem, powiedziało, aby ustawić silnik db na Innodb lub upewnić się, że klucze, których próbuję użyć jako klucza obcego, są kluczami głównymi we własnych tabelach . Zrobiłem obie te rzeczy, jeśli się nie mylę. Jakaś inna pomoc, którą możecie zaoferować?

Executing SQL script in server

ERROR: Error 1215: Cannot add foreign key constraint

-- -----------------------------------------------------
-- Table `Alternative_Pathways`.`Clients_has_Staff`
-- -----------------------------------------------------

CREATE  TABLE IF NOT EXISTS `Alternative_Pathways`.`Clients_has_Staff` (
  `Clients_Case_Number` INT NOT NULL ,
  `Staff_Emp_ID` INT NOT NULL ,
  PRIMARY KEY (`Clients_Case_Number`, `Staff_Emp_ID`) ,
  INDEX `fk_Clients_has_Staff_Staff1_idx` (`Staff_Emp_ID` ASC) ,
  INDEX `fk_Clients_has_Staff_Clients_idx` (`Clients_Case_Number` ASC) ,
  CONSTRAINT `fk_Clients_has_Staff_Clients`
    FOREIGN KEY (`Clients_Case_Number` )
    REFERENCES `Alternative_Pathways`.`Clients` (`Case_Number` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_Clients_has_Staff_Staff1`
    FOREIGN KEY (`Staff_Emp_ID` )
    REFERENCES `Alternative_Pathways`.`Staff` (`Emp_ID` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB

Wykonanie skryptu SQL zakończone: instrukcje: 7 powiodło się, 1 nie powiodło się

Oto SQL dla tabel nadrzędnych.

CREATE  TABLE IF NOT EXISTS `Alternative_Pathways`.`Clients` (
  `Case_Number` INT NOT NULL ,
  `First_Name` CHAR(10) NULL ,
  `Middle_Name` CHAR(10) NULL ,
  `Last_Name` CHAR(10) NULL ,
  `Address` CHAR(50) NULL ,
  `Phone_Number` INT(10) NULL ,
  PRIMARY KEY (`Case_Number`) )
ENGINE = InnoDB

CREATE  TABLE IF NOT EXISTS `Alternative_Pathways`.`Staff` (
  `Emp_ID` INT NOT NULL ,
  `First_Name` CHAR(10) NULL ,
  `Middle_Name` CHAR(10) NULL ,
  `Last_Name` CHAR(10) NULL ,
  PRIMARY KEY (`Emp_ID`) )
ENGINE = InnoDB

Zgaduję, że Clients.Case_Numberi / lub Staff.Emp_IDnie są dokładnie tego samego typu danych co Clients_has_Staff.Clients_Case_Numberi Clients_has_Staff.Staff_Emp_ID.

Być może kolumny w tabelach nadrzędnych są INT UNSIGNED?

Muszą być dokładnie tym samym typem danych w obu tabelach.

Powody, dla których może pojawić się błąd ograniczenia klucza obcego:

1. Nie używasz InnoDB jako silnika we wszystkich tabelach.
2. Próbujesz odwołać się do nieistniejącego klucza w tabeli docelowej. Upewnij się, że jest to klucz na drugim stole (może to być klucz podstawowy lub unikalny)
3. Typy kolumn nie są takie same (wyjątek jest taki, że kolumna w tabeli odwołań może mieć wartość null).
4. Jeśli PK / FK jest varcharem, upewnij się, że sortowanie jest takie samo dla obu.

Aktualizacja:

5. Jednym z powodów może być również to, że kolumna, której używasz, ON DELETE SET NULLnie jest zdefiniowana jako pusta. Upewnij się więc, że kolumna ma domyślną wartość null.

Sprawdź te.

W przypadku innych ten sam błąd może nie zawsze wynikać z niedopasowania typu kolumny. Więcej informacji na temat błędu klucza foriegn mysql można uzyskać, wydając polecenie

SHOW ENGINE INNODB STATUS;

możesz znaleźć błąd w górnej części drukowanej wiadomości

Nie można znaleźć indeksu w tabeli, do której istnieją odniesienia, w której kolumny pojawiają się jako pierwsze kolumny, lub typy kolumn w tabeli, a tabela, do której istnieje odwołanie, nie pasuje do ograniczenia.

Błąd 1215 jest denerwujący. Odpowiedź pigułki przeciw eksplozji obejmuje podstawy. Chcesz zacząć od tego miejsca. Istnieje jednak wiele, znacznie bardziej subtelnych przypadków, na które należy zwrócić uwagę:

Na przykład, gdy próbujesz połączyć PODSTAWOWE KLUCZY różnych tabel, upewnij się, że podałeś odpowiednie ON UPDATEi ON DELETEopcje. Na przykład:

...
PRIMARY KEY (`id`),
FOREIGN KEY (`id`) REFERENCES `t` (`other_id`) ON DELETE SET NULL
....

nie będzie latać, ponieważ KLUCZY PODSTAWOWE (takie jak id) nie mogą być NULL.

Jestem pewien, że przy dodawaniu tego rodzaju ograniczeń są jeszcze inne, podobnie subtelne problemy, dlatego napotykając błędy wiązań, zawsze upewnij się, że ograniczenia i ich implikacje mają sens w twoim obecnym kontekście. Powodzenia z błędem 1215!

Sprawdź zestawienie tabeli, używając SHOW TABLE STATUSmożesz sprawdzić informacje o tabelach, w tym zestawienie.

Obie tabele muszą mieć to samo zestawienie.

Zdarzyło mi się.

W moim przypadku usunąłem tabelę za pomocą SET FOREIGN_KEY_CHECKS=0, a następnie SET FOREIGN_KEY_CHECKS=1po. Kiedy poszedłem przeładować stół, dostałem error 1215. Problem polegał na tym, że w bazie danych znajdowała się kolejna tabela, która miała obcy klucz do tabeli, którą usunąłem i ładowałem ponownie. Część procesu przeładowywania polegała na zmianie typu danych dla jednego z pól, co spowodowało, że klucz obcy z drugiej tabeli był nieprawidłowy, co spowodowało uruchomienie error 1215. Rozwiązałem problem, upuszczając, a następnie ponownie ładując drugą tabelę z nowym typem danych dla zaangażowanego pola.

Wystąpił ten sam błąd podczas próby dodania fk. W moim przypadku problem został spowodowany przez PK tabeli FK, który został oznaczony jako niepodpisany.

Podczas korzystania z Laravel 4 wystąpił problem z błędem „Błąd 1215: Nie można dodać ograniczenia klucza obcego”, zwłaszcza w przypadku generatorów Laravel 4 JeffreyWay.

W Laravel 4 można używać generatorów JeffreyWay do generowania plików migracji w celu tworzenia tabel jeden po drugim, co oznacza, że ​​każdy plik migracji generuje jedną tabelę. Musisz być świadomy faktu, że każdy plik migracji jest generowany ze znacznikiem czasu w nazwie pliku, co nadaje plikom kolejność. Kolejność generowania jest również kolejnością operacji migracji podczas uruchamiania polecenia CLI rzemieślnika „php artisan migrate”. Tak więc, jeśli plik prosi o ograniczenie klucza obcego odnoszące się do klucza, który zostanie wygenerowany, ale nie został jeszcze wygenerowany w drugim pliku, zostanie uruchomiony błąd 1215. W takim przypadku musisz dostosować kolejność generowania plików migracji. Wygeneruj nowe pliki w odpowiedniej kolejności, skopiuj zawartość, a następnie usuń nieuporządkowane stare pliki.

miałem ten sam problem, moje rozwiązanie:

Przed:

CREATE TABLE EMPRES
( NoFilm smallint NOT NULL

  PRIMARY KEY (NoFilm)

  FOREIGN KEY (NoFilm) REFERENCES cassettes

);

Rozwiązanie:

CREATE TABLE EMPRES
(NoFilm smallint NOT NULL REFERENCES cassettes,

 PRIMARY KEY (NoFilm)

);

Mam nadzieję, że to pomoże;)

Miałem ten sam problem.
Rozwiązałem to w ten sposób:

Utworzyłem następujący wiersz w
primary key: (id int(11) unsigned NOT NULL AUTO_INCREMENT)

Znalazłem to rozwiązanie po próbie zaimportowania tabeli w moim kreatorze schematów. Jeśli to działa, daj mi znać!

Powodzenia!

Felipe Tércio

Chciałem tylko dodać ten przypadek do VARCHARrelacji klucza obcego. Spędziłem ostatni tydzień próbując to rozgryźć w MySQL Workbench 8.0 i w końcu mogłem naprawić błąd.

Krótka odpowiedź: zestaw znaków i zestawienie schematu, tabeli, kolumny, tabeli odniesienia, kolumny odniesienia i wszelkich innych tabel, które odnoszą się do tabeli nadrzędnej, muszą być zgodne.

Długa odpowiedź: miałem w tabeli typ ENUM. Zmieniłem to na VARCHARi mogę pobrać wartości z tabeli referencyjnej, aby nie musiałem modyfikować tabeli nadrzędnej, aby dodać dodatkowe opcje. Ta relacja klucza obcego wydawała się prosta, ale dostałem błąd 1215. odpowiedź arvind i poniższy link sugerują użycie

SHOW ENGINE INNODB STATUS;

Korzystając z tego polecenia, otrzymałem następujący pełny opis błędu bez dodatkowych pomocnych informacji

Nie można znaleźć indeksu w tabeli, do której istnieją odniesienia, w której kolumny pojawiają się jako pierwsze kolumny, lub typy kolumn w tabeli, a tabela, do której istnieje odwołanie, nie pasuje do ograniczenia. Zauważ, że typ pamięci wewnętrznej ENUM i SET zmienił się w tabelach utworzonych za pomocą> = InnoDB-4.1.12, a do takich kolumn w starych tabelach nie można odwoływać się przez takie kolumny w nowych tabelach. Prawidłową definicję klucza obcego można znaleźć na stronie http://dev.mysql.com/doc/refman/8.0/en/innodb-foreign-key-constraints.html .

Następnie wykorzystałem SET FOREIGN_KEY_CHECKS=0;zgodnie z sugestią Arvind Bharadwaj i link tutaj :

To dało następujący komunikat o błędzie:

Kod błędu: 1822. Nie można dodać ograniczenia klucza obcego. Brak indeksu ograniczenia

W tym momencie „odwróciłem inżynierię” schematu i udało mi się stworzyć relację klucza obcego na schemacie EER. Podczas „inżynierii naprzód” otrzymałem następujący błąd:

Błąd 1452: Nie można dodać lub zaktualizować wiersza podrzędnego: ograniczenie klucza obcego kończy się niepowodzeniem

Kiedy „przekazałem” schemat EER do nowego schematu, skrypt SQL działał bez problemów. Porównując wygenerowany SQL z prób przekazania inżyniera, stwierdziłem, że różnicą był zestaw znaków i zestawianie. Tabela nadrzędna, tabela podrzędna i dwie kolumny miały utf8mb4zestaw znaków i utf8mb4_0900_ai_ciukładanie, jednak do innej kolumny w tabeli nadrzędnej odwołano się przy użyciu CHARACTER SET = utf8 , COLLATE = utf8_bin ;innej tabeli podrzędnej.

Dla całego schematu zmieniłem zestaw znaków i układanie dla wszystkich tabel i wszystkich kolumn na następujące:

CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci;

To ostatecznie rozwiązało mój problem z błędem 1215.

Uwaga dodatkowa: Sortowanie utf8mb4_general_cidziała w MySQL Workbench 5.0 lub nowszym. Sortowanie utf8mb4_0900_ai_cidziała tylko dla MySQL Workbench 8.0 lub nowszego. Myślę, że jeden z powodów, dla których miałem problemy z zestawem znaków i zestawieniem, wynika z aktualizacji MySQL Workbench do wersji 8.0 pomiędzy nimi. Oto link, który mówi więcej o tym zestawieniu.

Nie mogę znaleźć tego błędu

CREATE TABLE RATING (

Riv_Id INT(5),
Mov_Id INT(10) DEFAULT 0,
Stars INT(5),
Rating_date DATE, 

PRIMARY KEY (Riv_Id, Mov_Id),

FOREIGN KEY (Riv_Id) REFERENCES REVIEWER(Reviewer_ID)
ON DELETE SET NULL ON UPDATE CASCADE,

FOREIGN KEY (Mov_Id) REFERENCES MOVIE(Movie_ID)
ON DELETE SET DEFAULT ON UPDATE CASCADE
)

Dzieje się tak również wtedy, gdy typ kolumn nie jest taki sam.

np. jeśli kolumna, do której się odwołujesz, to INTELIGENTNIA, a kolumna, której dotyczy odwołanie, to INT, pojawi się ten błąd.

Dla MySQL (INNODB) ... pobierz definicje kolumn, które chcesz połączyć

SELECT * FROM information_schema.columns WHERE 
TABLE_NAME IN (tb_name','referenced_table_name') AND 
COLUMN_NAME  IN ('col_name','referenced_col_name')\G

porównaj i sprawdź, czy obie definicje kolumn

to samo COLUMN_TYPE (długość), to samo COLATION

może być przydatna do gry

set foreign_key_checks=0;
ALTER TABLE tb_name ADD FOREIGN KEY(col_name) REFERENCES ref_table(ref_column) ON DELETE ...
set foreign_key_checks=1;

Sprawdź zgodność tabeli. Na przykład, jeśli jedna tabela jest, MyISAMa druga jest InnoDB, możesz mieć ten problem.

Kolejny powód: jeśli użyjesz ON DELETE SET NULL wszystkich kolumn używanych w kluczu obcym, musisz zezwolić na wartości null. Ktoś inny odkrył to w tym pytaniu .

Z mojego zrozumienia nie będzie problemu z integralnością danych, ale wydaje się, że MySQL po prostu nie obsługuje tej funkcji (w 5.7).

Gdy ten błąd występuje, ponieważ tabela, do której się odwołujemy, korzysta z silnika MyISAM, ta odpowiedź zapewnia szybki sposób konwersji bazy danych, dzięki czemu wszystkie tabele modeli Django korzystają z InnoDB: https://stackoverflow.com/a/15389961/2950621

Jest to polecenie zarządzania Django o nazwie convert_to_innodb.

Wooo, właśnie to dostałem! Było to połączenie wielu już opublikowanych odpowiedzi (innoDB, niepodpisane itp.). Jednej rzeczy nie widziałem tutaj: jeśli twój FK wskazuje na PK, upewnij się, że kolumna źródłowa ma wartość, która ma sens. Na przykład, jeśli PK jest mediumintem (8), upewnij się, że kolumna źródłowa zawiera również mediumint (8). To było dla mnie częścią problemu.

Dla mnie były to typy kolumn. BigINT! = INT.

Ale nadal nie działało.

Więc sprawdziłem silniki. Upewnij się, że Tabela1 = InnoDB i Tabela = InnoDB

Wystąpił ten błąd z zupełnie innego powodu. Użyłem MySQL Workbench 6.3 do stworzenia mojego modelu danych (niesamowite narzędzie). Zauważyłem, że gdy kolejność kolumn zdefiniowana w definicji ograniczenia klucza obcego nie pasuje do sekwencji kolumn tabeli, ten błąd również jest generowany.

Zajęło mi około 4 godzin próbowanie wszystkiego innego, ale sprawdzanie tego.

Teraz wszystko działa dobrze i mogę wrócić do kodowania. :-)

podczas próby utworzenia klucza obcego podczas korzystania z migracji laravel

jak ten przykład:

tabela użytkowników

    public function up()
{
    Schema::create('flights', function (Blueprint $table) {
        $table->increments('id');
        $table->string('name');
        $table->TinyInteger('color_id')->unsigned();
        $table->foreign('color_id')->references('id')->on('colors');
        $table->timestamps();
    });
}

tabela kolorów

    public function up()
{
    Schema::create('flights', function (Blueprint $table) {
        $table->increments('id');
        $table->string('color');
        $table->timestamps();
    });
}

czasami właściwości nie działały

[PDOException]
SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint

ten błąd wystąpił, ponieważ klucz obcy (typ) w [tabela użytkownika] różni się od klucza podstawowego (typ) w [tabela kolorów]

Aby rozwiązać ten problem, należy zmienić klucz główny w [tabeli kolorów]

$table->tinyIncrements('id');

Gdy używasz klucza podstawowego $table->Increments('id');

powinieneś użyć Integerjako klucza obcego

    $table-> unsignedInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

Gdy używasz klucza podstawowego $table->tinyIncrements('id');

powinieneś użyć unsignedTinyIntegerjako klucza obcego

    $table-> unsignedTinyInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

Gdy używasz klucza podstawowego $table->smallIncrements('id');

powinieneś użyć unsignedSmallIntegerjako klucza obcego

    $table-> unsignedSmallInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

Gdy używasz klucza podstawowego $table->mediumIncrements('id');

powinieneś użyć unsignedMediumIntegerjako klucza obcego

    $table-> unsignedMediumInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

W moim przypadku musiałem wyłączyć FOREIGN KEYkontrole, ponieważ tabele źródłowe nie istniały.

SET FOREIGN_KEY_CHECKS=0;

Pamiętaj także o stosowaniu cudzysłowów. Miałem w skrypcie następujące oświadczenie

ALTER TABLE service ADD FOREIGN KEY (create_by) REFERENCES `system_user(id)`;

ale cytaty na końcu były fałszywe. To powinno być:

ALTER TABLE service ADD FOREIGN KEY (create_by) REFERENCES `system_user`(`id`);

MySQL nie podaje żadnych szczegółów dotyczących tego błędu ...

Innym źródłem tego błędu jest to, że masz 2 lub więcej takich samych nazw tabel, które mają takie same nazwy kluczy obcych. Zdarza się to czasami ludziom, którzy używają oprogramowania do modelowania i projektowania, takiego jak Mysql Workbench, a później generują skrypt na podstawie projektu.

Wiem, że jestem BARDZO spóźniony na imprezę, ale chcę go tutaj umieścić, aby znalazł się na liście.

Oprócz wszystkich powyższych porad, aby upewnić się, że pola są identycznie zdefiniowane, a typy tabel mają również to samo sortowanie, upewnij się, że nie popełnisz błędu w próbie połączenia pól, w których dane w polu CHILD nie są już w polu PARENT. Jeśli masz dane znajdujące się w polu DZIECKO, które nie zostały jeszcze wprowadzone w polu RODZICA, spowoduje to ten błąd. Szkoda, że ​​komunikat o błędzie nie jest bardziej pomocny.

Jeśli nie masz pewności, wykonaj kopię zapasową tabeli zawierającej klucz obcy, usuń wszystkie dane, a następnie spróbuj utworzyć klucz obcy. Jeśli się powiedzie, to co robić!

Powodzenia.

Jest to subtelna wersja tego, co zostało już powiedziane, ale w moim przypadku miałem 2 bazy danych (foo i bar). Najpierw stworzyłem foo i nie zdawałem sobie sprawy, że odnosi się do klucza obcego w bar.baz (który jeszcze nie został stworzony). Kiedy próbowałem utworzyć bar.baz (bez żadnych kluczy obcych), ciągle pojawiał się ten błąd. Po dłuższym rozglądaniu się znalazłem klucz obcy w foo.

Krótko mówiąc, jeśli pojawi się ten błąd, być może masz już istniejący klucz obcy do tworzonej tabeli.

Dla mnie błąd 1215 wystąpił, gdy importowałem plik zrzutu utworzony przez mysqldump, który tworzy tabele alfabetycznie, co w moim przypadku spowodowało, że klucze obce odwoływały się do tabel utworzonych później w pliku. (Propozycje na tej stronie za wskazanie: https://www.percona.com/blog/2017/04/06/dealing-mysql-error-code-1215-cannot-add-foreign-key-constraint/ )

Ponieważ mysqldump porządkuje tabele alfabetycznie i nie chciałem zmieniać nazw tabel, postępowałem zgodnie z instrukcjami zawartymi w odpowiedzi JeremyWeir na tej stronie , która stanowi umieszczenie set FOREIGN_KEY_CHECKS = 0;na górze pliku zrzutu i umieszczenie SET FOREIGN_KEY_CHECKS = 1;na dole pliku zrzutu .

To rozwiązanie działało dla mnie.

Wypróbowałem więc wszystkie powyższe poprawki i bez powodzenia. Być może brakuje mi błędu w moich tabelach - po prostu nie mogłem znaleźć przyczyny i ciągle pojawiał się błąd 1215. Więc skorzystałem z tej poprawki.

W moim lokalnym środowisku w phpMyAdmin wyeksportowałem dane z omawianej tabeli. Wybrałem format CSV. Będąc nadal w phpMyAdmin przy wybranej tabeli, wybrałem „Więcej-> Opcje”. Przewinąłem w dół do „Kopiuj tabelę do (database.table). Wybierz„ Tylko struktura ”. Zmień nazwę tabeli na coś, może po prostu dodaj słowo„ kopiuj ”obok bieżącej nazwy tabeli. Kliknij„ Idź ”To utworzy nowe tabela. Wyeksportuj nową tabelę i zaimportuj ją na nowy lub inny serwer. Używam również phpMyAdmina. Po zaimportowaniu zmień nazwę tabeli z powrotem na pierwotną nazwę. Wybierz nową tabelę, wybierz import. Aby wybrać format, wybierz CSV Usuń zaznaczenie „włącz sprawdzanie klucza obcego”. Wybierz „Idź”. Do tej pory wszystko działa dobrze.

Zamieściłem swoją poprawkę na swoim blogu .

Nawet ja miałem ten sam problem. A błąd polegał na tym, że znacznik „niepodpisany” w tabeli FK PK

Raz miałem ten sam błąd. Właśnie zrestartowałem serwer MySQL i naprawiłem problem.