Ошибка 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. Типы столбцов не одинаковы (за исключением того, что столбец в ссылочной таблице может иметь значение NULL).
4. Если PK / FK является varchar, убедитесь, что сопоставление одинаково для обоих.

Обновить:

5. Одной из причин может быть также то, что используемый вами столбец ON DELETE SET NULLне определен как нулевой. Поэтому убедитесь, что для столбца установлено значение по умолчанию 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. В моем случае проблема была вызвана PK таблицы FK, который был помечен как неподписанный.

Я столкнулся с ловушкой «Ошибка 1215: невозможно добавить ограничение внешнего ключа» при использовании Laravel 4, особенно с JeffreyWay's Laravel 4 Generators.

В Laravel 4 вы можете использовать Генераторы JeffreyWay для генерации файлов миграции для создания таблиц по одной, что означает, что каждый файл миграции генерирует одну таблицу. Вы должны знать о том факте, что каждый файл миграции генерируется с отметкой времени в имени файла, которая дает файлам порядок. Порядок генерации также является порядком операции миграции при запуске команды CLI Artisan «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. Ответ Арвинда и следующая ссылка предложили использовать

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 или более поздней версии. Collation 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, unsigned и т. Д.). Однако здесь я не увидел одну вещь: если ваш FK указывает на PK, убедитесь, что в исходном столбце есть значение, которое имеет смысл. Например, если PK представляет собой mediumint (8), убедитесь, что в исходном столбце также есть mediumint (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, и позже генерируют сценарий из проекта.

Я знаю, что я ОЧЕНЬ опоздал на вечеринку, но я хочу выложить это здесь, чтобы это было в списке.

Так же как и все вышеприведенные советы, чтобы убедиться, что поля определены одинаково, а типы таблиц также имеют одинаковое сопоставление, убедитесь, что вы не допустили ошибку новичка, пытаясь связать поля, где данные в поле CHILD не совпадают. уже в поле РОДИТЕЛЯ. Если у вас есть данные, которые находятся в поле CHILD, которые вы еще не ввели в поле PARENT, то это вызовет эту ошибку. Обидно, что сообщение об ошибке не более полезно.

Если вы не уверены, сделайте резервную копию таблицы с внешним ключом, удалите все данные и попробуйте создать внешний ключ. Если успешно, то вам, что делать!

Удачи.

Это тонкая версия того, что уже было сказано, но в моем случае у меня было 2 базы данных (foo и bar). Сначала я создал foo и не понял, что он ссылается на внешний ключ в bar.baz (который еще не был создан). Когда я пытался создать bar.baz (без каких-либо внешних ключей), я продолжал получать эту ошибку. Посмотрев некоторое время, я нашел внешний ключ в foo.

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

Для меня ошибка 1215 произошла, когда я импортировал созданный файл дампа 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 с выбранной таблицей я выбрал «More-> Options». Здесь я прокрутил вниз до «Скопировать таблицу в (database.table). Выберите« Только структура ». Переименуйте таблицу как-нибудь, возможно, просто добавьте слово« копия »рядом с именем текущей таблицы. Нажмите« Перейти ». Это создаст новый Таблица. Экспортируйте новую таблицу и импортируйте ее на новый или другой сервер. Я также использую здесь phpMyAdmin. После импорта измените имя таблицы обратно на ее первоначальное имя. Выберите новую таблицу, выберите импорт. Для формата выберите CSV Снимите флажок «включить проверку внешнего ключа». Выберите «Перейти». Пока все работает хорошо.

Я разместил свое исправление в своем блоге .

Даже у меня была такая же проблема. И вина была с «беззнаковым» маркером в таблице ФК ПК

У меня была одна и та же ошибка один раз. Я просто перезапустил сервер MySQL и исправил проблему.