Mysql cannot add foreign key constraint

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

Как видно, оно запрещает создать связь.
Попробовал:
1 — пересоздать миграции
2 — добавить InnoDB

  • Вопрос задан более двух лет назад
  • 3594 просмотра

Andrey Stark: В целом вам скорее всего логично ставить cascade.

cascade — при удалении юзера его подписки тоже удаляются.

set null — при удалении юзера ключ user_id становится null но подписка остается.

Для set null поле user_id должно быть nullable — то есть иметь возможность принимать значение NULL. У вас в миграции этого нет.

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

выполнение сценария SQL завершено: заявления: 7 удалось, 1 не удалось

вот SQL для родительских таблиц.

27 ответов

Я полагаю, что 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 является varchar, убедитесь параметры сортировки одинаковы для обоих.

обновление:

  1. одной из причин может быть то, что столбец используется для ON DELETE SET NULL не определяется как null. Поэтому убедитесь, что столбец имеет значение null по умолчанию.

для других такая же ошибка не всегда может быть из-за несоответствия типа столбца, вы можете узнать больше информации об ошибке ключа MySQL foriegn, выполнив команду

вы можете найти ошибку в верхней части печатного сообщения что-то вроде

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

ошибка 1215 раздражает. взрыв таблетки ответ охватывает основы. Вы должны быть уверены, что начнете оттуда. Тем не менее, есть более, гораздо более тонкие случаи, чтобы искать:

Читайте также:  Как посмотреть сколько оперативки на компе

например, когда вы пытаетесь связать первичные ключи разных таблиц, обязательно укажите правильный ON UPDATE и ON DELETE параметры. Например:

не будет летать, потому что первичные ключи (например, id ) не может быть NULL .

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

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

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

обе таблицы должны иметь одинаковые параметры сортировки.

Это случилось со мной.

есть ловушка, с которой я столкнулся с "ошибкой 1215: не могу добавить ограничение внешнего ключа" при использовании Laravel 4, особенно с генераторами Laravel 4 Джеффри.

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

Я получил ту же ошибку при попытке добавить fk. В моем случае проблема была вызвана ПК таблицы FK, который был отмечен как неподписанный.

У меня была та же проблема.
Я решил это сделать так:

Я создал следующую строку
primary key: (id int(11) unsigned NOT NULL AUTO_INCREMENT)

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

So I’m trying to add Foreign Key constraints to my database as a project requirement and it worked the first time or two on different tables, but I have two tables on which I get an error when trying to add the Foreign Key Constraints. The error message that I get is:

ERROR 1215 (HY000): Cannot add foreign key constraint

This is the SQL I’m using to create the tables, the two offending tables are Patient and Appointment .

Читайте также:  Что такое без ретуши

21 Answers 21

To find the specific error run this:

And look in the LATEST FOREIGN KEY ERROR section.

The data type for the child column must match the parent column exactly. For example, since medicalhistory.MedicalHistoryID is an INT , Patient.MedicalHistory also needs to be an INT , not a SMALLINT .

Also, you should run the query set foreign_key_checks=0 before running the DDL so you can create the tables in an arbitrary order rather than needing to create all parent tables before the relevant child tables.

I had set one field as "Unsigned" and other one not. Once I set both columns to Unsigned it worked.

  • Engine should be the same e.g. InnoDB
  • Datatype should be the same, and with same length. e.g. VARCHAR(20)
  • Collation Columns charset should be the same. e.g. utf8
    Watchout: Even if your tables have same Collation, columns still could have different one.
  • Unique — Foreign key should refer to field that is unique (usually primary key) in the reference table.

Try to use the same type of your primary keys — int(11) — on the foreign keys — smallint(5) — as well.

Confirm that the character encoding and collation for the two tables is the same.

In my own case, one of the tables was using utf8 and the other was using latin1 .

I had another case where the encoding was the same but the collation different. One utf8_general_ci the other utf8_unicode_ci

You can run this command to set the encoding and collation for a table.

I hope this helps someone.

To set a FOREIGN KEY in Table B you must set a KEY in the table A.

In table A: INDEX id ( id )

And then in the table B,

I had same problem and the solution was very simple. Solution : foreign keys declared in table should not set to be not null.

reference : If you specify a SET NULL action, make sure that you have not declared the columns in the child table as NOT NULL. (ref )

Please ensure that both the tables are in InnoDB format. Even if one is in MyISAM format, then, foreign key constraint wont work.

Читайте также:  Программа для просмотра рефлектограмм trc

Also, another thing is that, both the fields should be of the same type. If one is INT, then the other should also be INT. If one is VARCHAR, the other should also be VARCHAR, etc.

Check following rules :

First checks whether names are given right for table names

Second right data type give to foreign key ?

I faced the issue and was able to resolve it by making sure that the data types were exactly matching .

I was using SequelPro for adding the constraint and it was making the primary key as unsigned by default .

Check the signing on both your table columns. If the referring table column is SIGNED, the referenced table column should be SIGNED too.

NOTE: The following tables were taken from some site when I was doing some R&D on the database. So the naming convention is not proper.

For me, the problem was, my parent table had the different character set than that of the one which I was creating.

Parent Table (PRODUCTS)

Child Table which had a problem (PRICE_LOGS)

MODIFIED TO

I had a similar error in creating foreign key in a Many to Many table where the primary key consisted of 2 foreign keys and another normal column. I fixed the issue by correcting the referenced table name i.e. company, as shown in the corrected code below:

I had similar error with two foreign keys for different tables but with same key names! I have renamed keys and the error had gone)

Had a similar error, but in my case I was missing to declare the pk as auto_increment.

Just in case it could be helpful to anyone

I got the same error. The cause in my case was:

  1. I created a backup of a database via phpmyadmin by copying the whole database.
  2. I created a new db with the same name the old db had und selected it.
  3. I started an SQL script to create updated tables and data.
  4. I got the error. Also when I disabled foreign_key_checks. Altough the database was completely empty.

The cause was: Since i used phpmyadmin to create some foreign keys in the renamed database — the foreign keys where created with a database name prefix but the database name prefix was not updated. So there were still references in the backup-db pointing to the newly created db.