Помилка MySQL 1215: Неможливо додати обмеження зовнішнього ключа

Я намагаюся переслати інженер мою нову схему на мій сервер db, але я не можу зрозуміти, чому я отримую цю помилку. Я намагався шукати відповідь тут, але все, що я знайшов, сказав, щоб або встановити db-движок на Innodb, або переконатися, що ключі, які я намагаюся використовувати як іноземний ключ, є первинними ключами у власних таблицях . Я зробив обидві ці речі, якщо не помиляюся. Будь-яка інша допомога, яку ви могли б запропонувати?

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

Виконання сценарію SQL завершено: заяви: 7 вдалося, 1 не вдалося

Ось SQL для батьківських таблиць.

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

Я здогадуюсь, що Clients.Case_Numberта / або Staff.Emp_IDзовсім не той самий тип даних, як Clients_has_Staff.Clients_Case_Numberі Clients_has_Staff.Staff_Emp_ID.

Можливо, стовпці в батьківських таблицях є INT UNSIGNED?

Вони повинні бути абсолютно однакового типу даних в обох таблицях.

Причини, через які може виникнути помилка обмеження іноземного ключа:

1. Ви не використовуєте InnoDB як двигун для всіх таблиць.
2. Ви намагаєтеся посилатися на неіснуючий ключ на цільовій таблиці. Переконайтеся, що це ключ в іншій таблиці (це може бути первинний або унікальний ключ)
3. Типи стовпців неоднакові (виняток - стовпець у таблиці посилань може бути нульовим).
4. Якщо PK / FK - варшар, переконайтесь, що коефіцієнт порівняння є однаковим для обох.

Оновлення:

5. Однією з причин також може бути те, що стовпець, для якого ви використовуєте ON DELETE SET NULL, не визначено як нульовий. Тому переконайтеся, що для стовпця встановлено значення за замовчуванням

Перевірте це.

Для інших така ж помилка не завжди може бути пов’язана з невідповідністю типу стовпців, ви можете дізнатися більше інформації про помилку клавіш mysql foriegn, видавши команду

SHOW ENGINE INNODB STATUS;

Ви можете виявити помилку вгорі надрукованого повідомлення щось подібне

Неможливо знайти індекс у таблиці, на яку посилаються, де стовпці, на які посилаються, відображаються як перші стовпці, або типи стовпців у таблиці та посилана таблиця не відповідають обмеженням.

Помилка 1215 - це дратує. Відповідь таблетки вибуху охоплює основи. Ви хочете переконатися, що почати звідти. Однак є ще набагато більш тонкі випадки, на які слід звернути увагу:

Наприклад, коли ви намагаєтесь зв’язати ПЕРВИЧНІ КЛЮЧІ з різних таблиць, переконайтесь, що вкажіть правильність ON UPDATEта ON DELETEваріанти. Наприклад:

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

не полетить, тому що ПЕРШИХ КЛЮЧІВ (таких як id) не може бути NULL.

Я впевнений, що при додаванні подібних обмежень виникає ще більше подібних проблем, і саме тому, стикаючись з помилками обмеження, завжди переконайтесь, що обмеження та їх наслідки мають сенс у вашому поточному контексті. Удачі з вашою помилкою 1215!

Перевірте порівняння таблиці, використовуючи SHOW TABLE STATUSви можете перевірити інформацію про таблиці, включаючи порівняння.

Обидві таблиці повинні мати однакове порівняння.

Це сталося зі мною.

У моєму випадку я видалив таблицю за допомогою SET FOREIGN_KEY_CHECKS=0, а потім SET FOREIGN_KEY_CHECKS=1після. Коли я пішов перезавантажувати стіл, я отримав error 1215. Проблема полягала в тому, що в базі даних була ще одна таблиця, яка містила зовнішній ключ до таблиці, яку я видалив і перезавантажував. Частина процесу перезавантаження включала в себе зміну типу даних для одного з полів, що зробило зовнішній ключ з іншої таблиці недійсним, тим самим запустивши error 1215. Я вирішив проблему, скинувши та перезавантаживши іншу таблицю новим типом даних для залученого поля.

Я отримав таку ж помилку під час спроби додати fk. У моєму випадку проблема була викликана ПК ПК таблиці FK, який був позначений як непідписаний.

Під час використання Laravel 4, особливо з генераторами Laravel 4 від JeffreyWay, є помилка, з якою я стикався з "Помилка 1215: Неможливо додати обмеження на зовнішній ключ".

У Laravel 4 можна використовувати генератори JeffreyWay для генерації файлів міграції для створення таблиць одна за одною, а це означає, що кожен файл міграції створює одну таблицю. Ви повинні знати про те, що кожен файл міграції генерується із позначкою часу у назві файлу, яка надає файлам порядок. Порядок генерації - це також порядок операції з міграції, коли ви запускаєте команду Artisan CLI "php artisan migrate". Отже, якщо файл вимагає обмеження зовнішнього ключа, що стосується ключа, який буде, але ще не генерується в останньому файлі, помилка 1215 видаляється. У такому випадку потрібно налаштувати порядок створення файлів міграції. Створюйте нові файли в належному порядку, скопіюйте вміст, а потім видаліть невпорядковані старі файли.

У мене було те саме питання, моє рішення:

Перед:

CREATE TABLE EMPRES
( NoFilm smallint NOT NULL

  PRIMARY KEY (NoFilm)

  FOREIGN KEY (NoFilm) REFERENCES cassettes

);

Рішення:

CREATE TABLE EMPRES
(NoFilm smallint NOT NULL REFERENCES cassettes,

 PRIMARY KEY (NoFilm)

);

Я сподіваюся, що це допоможе;)

У мене була така ж проблема.
Я вирішив це, роблячи це:

Я створив наступний рядок у
primary key: (id int(11) unsigned NOT NULL AUTO_INCREMENT)

Я знайшов це рішення, намагаючись імпортувати таблицю в свій конструктор схем. Якщо це працює для вас, дайте мені знати!

Удачі!

Феліпе Терчо

Я просто хотів додати цю справу і для VARCHAR зовнішньополітичних відносин. Я провів останній тиждень, намагаючись зрозуміти це в MySQL Workbench 8.0 і нарешті зміг виправити помилку.

Короткий відповідь: Набір символів та зіставлення схеми, таблиці, стовпця, референтної таблиці, стовпця референції та будь-яких інших таблиць, які посилаються на батьківську таблицю, повинні відповідати.

Довга відповідь: у мене в таблиці був тип даних ENUM. Я змінив це на VARCHARі можу отримати значення з довідкової таблиці, щоб мені не довелося змінювати батьківську таблицю, щоб додати додаткові параметри. Цей зовнішньополітичний зв’язок здався простим, але я отримав помилку 1215. Відповідь arvind та наступне посилання запропонували використовувати

SHOW ENGINE INNODB STATUS;

Використовуючи цю команду, я отримав наступний багатослівний опис помилки без додаткової корисної інформації

Неможливо знайти індекс у таблиці, на яку посилаються, де стовпці, на які посилаються, відображаються як перші стовпці, або типи стовпців у таблиці та посилана таблиця не відповідають обмеженням. Зауважте, що тип внутрішнього зберігання ENUM і SET змінювався в таблицях, створених за допомогою> = InnoDB-4.1.12, і такі стовпці в старих таблицях не можуть бути посилаються на такі стовпці в нових таблицях. Будь ласка, зверніться до http://dev.mysql.com/doc/refman/8.0/en/innodb-foreign-key-constraints.html для правильного визначення зовнішнього ключа.

Після чого я використав, SET FOREIGN_KEY_CHECKS=0;як запропонував Арвінд Бхарадвай, і посилання тут :

Це дало таке повідомлення про помилку:

Код помилки: 1822. Не вдалося додати обмеження іноземного ключа. Відсутній індекс для обмеження

У цей момент я "інженер-зворотник" змінив схему, і я зміг внести зв'язок із зовнішнім ключем у діаграму EER. Під час "інженерів вперед" я отримав таку помилку:

Помилка 1452: Неможливо додати або оновити дочірню рядок: помилка зовнішнього ключа не вдається

Коли я 'переадресував інженер' діаграму EER на нову схему, сценарій SQL запускався без проблем. Порівнюючи згенерований SQL від спроб переслати інженер, я виявив, що різниця полягала в наборі символів та порівнянні. Батьківська таблиця, дочірня таблиця та два стовпці мали utf8mb4набір символів іutf8mb4_0900_ai_ci зіставлення, однак на інший стовпець у батьківській таблиці посилався за допомогоюCHARACTER SET = utf8 , COLLATE = utf8_bin ; на іншу дочірню таблицю.

Для всієї схеми я змінив набір символів і порівняння для всіх таблиць і всіх стовпців на наступне:

CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci;

Це остаточно вирішило мою проблему з помилкою 1215.

Бічна примітка: Порівняння utf8mb4_general_ciпрацює в MySQL Workbench 5.0 або новішої версії. Збірка utf8mb4_0900_ai_ciпрацює лише для MySQL Workbench 8.0 або новішої версії. Я вважаю, що одна з причин у мене виникли проблеми з набором символів та зіставленням через оновлення MySQL Workbench до рівня 8.0. Ось посилання, яке детальніше розповідає про це порівняння.

Я не можу знайти цю помилку

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
)

Це також відбувається, коли тип стовпців неоднаковий.

наприклад, якщо стовпець, на який ви посилаєтесь, - UNSIGNED INT, а стовпець, на який посилається, INT, то ви отримуєте цю помилку.

Для MySQL (INNODB) ... отримайте визначення для стовпців, які ви хочете пов’язати

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

порівняти та перевірити, чи є обидва визначення стовпців

той самий COLUMN_TYPE (довжина), той самий COLATION

може допомогти грати так

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;

Перевірте сумісність таблиць. Наприклад, якщо одна таблиця є, MyISAMа інша - InnoDB, у вас може виникнути ця проблема.

Ще одна причина: якщо ви використовуєте ON DELETE SET NULL всі стовпці, які використовуються в зовнішньому ключі, повинні містити нульові значення. Хтось ще дізнався це в цьому запитанні .

З мого розуміння, це не буде проблемою щодо цілісності даних, але здається, що MySQL просто не підтримує цю функцію (в 5.7).

Коли ця помилка виникає через те, що у посиланій таблиці використовується механізм MyISAM, ця відповідь забезпечує швидкий спосіб перетворення вашої бази даних, тому всі таблиці моделей Django використовують InnoDB: https://stackoverflow.com/a/15389961/2950621

Це команда управління Django під назвою convert_to_innodb.

Wooo, я щойно це отримав! Це була сукупність безлічі вже опублікованих відповідей (innoDB, непідписані тощо). Одне, що я тут не бачив, це: якщо ваш FK вказує на ПК, переконайтеся, що джерельний стовпець має значення, яке має сенс. Наприклад, якщо ПК є середньою точкою (8), переконайтеся, що стовпець джерела також містить медіант (8). Це було частиною проблеми для мене.

Для мене це були типи стовпців. BigINT! = INT.

Але тоді все одно не вийшло.

Тому я перевірив двигуни. Переконайтеся, що Table1 = InnoDB і Table = InnoDB

Я відчув цю помилку з зовсім іншої причини. Я використовував MySQL Workbench 6.3 для створення своєї моделі даних (дивовижний інструмент). Я помітив, що коли порядок стовпців, визначений у визначенні обмеження іноземного ключа, не відповідає послідовності стовпців таблиці, ця помилка також генерується.

Пробувати у мене було близько 4 годин, але перевірити це.

Зараз все працює добре, і я можу повернутися до кодування. :-)

при спробі зробити зовнішній ключ під час використання міграції laravel

як у цьому прикладі:

таблиця користувача

    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();
    });
}

таблиця кольорів

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

іноді властивості не працювали

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

ця помилка сталася через те, що зовнішній ключ (тип) у [таблиці користувача] відхилений від первинного ключа (типу) у [таблиці кольорів]

Для вирішення цієї проблеми слід змінити первинний ключ у [таблиці кольорів]

$table->tinyIncrements('id');

Коли ви використовуєте первинний ключ $table->Increments('id');

ви повинні використовувати Integerяк зовнішній ключ

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

Коли ви використовуєте первинний ключ $table->tinyIncrements('id');

ви повинні використовувати unsignedTinyIntegerяк зовнішній ключ

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

Коли ви використовуєте первинний ключ $table->smallIncrements('id');

ви повинні використовувати unsignedSmallIntegerяк зовнішній ключ

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

Коли ви використовуєте первинний ключ $table->mediumIncrements('id');

ви повинні використовувати unsignedMediumIntegerяк зовнішній ключ

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

У моєму випадку мені довелося відключити FOREIGN KEYперевірки, оскільки вихідних таблиць не існувало.

SET FOREIGN_KEY_CHECKS=0;

Будьте в курсі використання зворотних цитат. Я мав у сценарії таке твердження

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

але зворотні цитати в кінці були помилковими. Це повинно було бути:

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

MySQL не дає деталей щодо цієї помилки ...

Іншим джерелом цієї помилки є те, що у вас є 2 або більше однакових імен таблиць, які мають однакові імена іноземних ключів. Іноді це трапляється з людьми, які використовують програмне забезпечення для моделювання та дизайну, як, наприклад, Mysql Workbench, а пізніше генерують сценарій із дизайну.

Я знаю, що Я ДУЖЕ запізнююся на вечірку, але я хочу винести її тут, щоб вона була в списку.

Окрім усіх вищезазначених порад щодо впевненості, що поля визначені однаково, а типи таблиць також мають однакове порівняння, переконайтеся, що ви не робите помилку новичка, намагаючись зв’язати поля, де дані в полі ДІТЛІ не є вже в полі РОДИНИ. Якщо у вас є дані, що знаходяться в полі ДИТИНИ, які ви ще не ввели в поле РОДИТИ, це призведе до цієї помилки. Прикро, що повідомлення про помилку не є дещо кориснішим.

Якщо ви не впевнені, створіть резервну копію таблиці, в якій є зовнішній ключ, видаліть усі дані та спробуйте створити зовнішній ключ. Якщо ви успішні, то вам що робити!

Удачі.

Це тонка версія сказаного, але в моєму випадку у мене було 2 бази даних (foo та bar). Я створив foo першим, і не зрозумів, що він посилається на іноземний ключ у bar.baz (який ще не створений). Коли я намагався створити bar.baz (без сторонніх ключів), я постійно отримував цю помилку. Дещо озирнувшись навколо, я знайшов закордонний ключ.

Отже, коротке оповідання: Якщо ви отримаєте цю помилку, у вас може виникнути попередній зовнішній ключ до створеної таблиці.

Для мене помилка 1215 сталася, коли я імпортував створений компанією dumpfile mysqldump, який створює таблиці в алфавітному порядку, що в моєму випадку викликало сторонні ключі до посилальних таблиць, створених пізніше у файлі. (Реквізити до цієї сторінки для її вказівки: https://www.percona.com/blog/2017/04/06/dealing-mysql-error-code-1215-cannot-add-foreign-key-constraint/ )

Оскільки mysqldump впорядковує таблиці в алфавітному порядку, і я не хотів змінювати назви таблиць, я дотримувався вказівок у відповіді JeremyWeir на цій сторінці , в якій зазначено, що потрібно розмістити set FOREIGN_KEY_CHECKS = 0;вгорі дамп-файлу і поставити SET FOREIGN_KEY_CHECKS = 1;внизу файлу дампа .

Це рішення працювало на мене.

Тому я спробував усі виправлення вище, і не пощастило. Можливо, у моїх таблицях відсутня помилка - просто не вдалося знайти причину, і я продовжував отримувати помилку 1215. Тому я використав це виправлення.

У моєму локальному середовищі в phpMyAdmin я експортував дані з відповідної таблиці. Я вибрав формат CSV. Будучи ще в phpMyAdmin із вибраною таблицею, я вибрав "Більше-> Параметри". Тут я прокрутився вниз до "Копіювати таблицю в (database.table). Виберіть" Тільки структура ". Перейменуйте таблицю щось, можливо просто додайте слово" копіювати "поруч із поточною назвою таблиці. Клацніть" Перейти ". Це створить нове Таблиця. Експортуйте нову таблицю та імпортуйте її на новий або інший сервер. Я також тут також використовую phpMyAdmin. Після імпортування змініть ім'я таблиці назад на початкове ім'я. Виберіть нову таблицю, виберіть імпорт. Для формату виберіть CSV Зніміть прапорець "включити перевірку зовнішніх ключів". Виберіть "Перейти". Поки все працює добре.

Я розмістив своє виправлення у своєму блозі .

Навіть у мене була така ж проблема. І виною був маркер "непідписаний" у таблиці ФК ПК

У мене колись була така ж помилка. Я просто перезапустив сервер MySQL і усунув проблему.