Ошибка внешнего ключа MySQL 1005 errno 150

Ответ 1

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

Тестовый пример:

CREATE TABLE tbl_a (
    id int PRIMARY KEY,
    some_other_id int,
    value int
) ENGINE=INNODB;
Query OK, 0 rows affected (0.10 sec)

CREATE TABLE tbl_b (
    id int PRIMARY KEY,
    a_id int,
    FOREIGN KEY (a_id) REFERENCES tbl_a (some_other_id)
) ENGINE=INNODB;
ERROR 1005 (HY000): Can't create table 'e.tbl_b' (errno: 150)

Но если мы добавим индекс на some_other_id:

CREATE INDEX ix_some_id ON tbl_a (some_other_id);
Query OK, 0 rows affected (0.11 sec)
Records: 0  Duplicates: 0  Warnings: 0

CREATE TABLE tbl_b (
    id int PRIMARY KEY,
    a_id int,
    FOREIGN KEY (a_id) REFERENCES tbl_a (some_other_id)
) ENGINE=INNODB;
Query OK, 0 rows affected (0.06 sec)

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

Ответ 2

Дважды проверьте, что внешние ключи имеют тот же тип, что и поле, которое вы получили в этой таблице. Например, оба должны быть Integer (10) или Varchar (8), даже количество символов.

Ответ 3

Я понимаю, что это старый пост, но он занимает высокое место в Google, поэтому я добавляю то, что я понял для моей проблемы. Если у вас есть сочетание типов таблиц (например, MyISAM и InnoDB), вы также получите эту ошибку. В этом случае InnoDB является типом таблицы по умолчанию, но для одной таблицы необходим полнотекстовый поиск, поэтому она была перенесена в MyISAM. В этой ситуации вы не можете создать внешний ключ в таблице InnoDB, который ссылается на таблицу MyISAM.

Ответ 4

Если ваш ключ является CHAR/VARCHAR или что-то в этом роде, другой возможной проблемой является различная сортировка. Проверьте, не является ли кодировка одинаковой.

Ответ 5

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

Переменные для обоих столбцов, которые я хотел связать, были целыми числами, но один из индексов имел "unsigned". Просто не проверяя, что исправила мою ошибку.

Ответ 6

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

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

Таким образом, это было несоответствие типа данных между первичным ключом и внешним ключом:)

Ответ 7

У меня была такая же проблема, но решение моей проблемы было совершенно иным. У меня было где-то еще в базе данных внешний ключ с тем же именем. Это вызвало ошибку 1005.

Переименование моего внешнего ключа на нечто более специфичное для этой ситуации разрешило проблему.

Ответ 8

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

Ответ 9

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

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

Вы можете изменить тип базы данных, используя: ALTER TABLE t ENGINE = MYISAM;

@see http://dev.mysql.com/doc/refman/5.1/en/storage-engine-setting.html

Ответ 10

В моем случае ошибка произошла из-за таблицы referencing MyISAM, где в качестве таблицы referring была InnoDB.

Converted механизм таблицы из MyISAM to InnoDB решает проблему для меня.

ALTER TABLE table_name ENGINE=InnoDB;

Ответ 11

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

Ответ 12

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

Ответ 13

Если у кого-то есть эта ошибка с кажущимися хорошо сформированными отношениями FK/PK, и вы использовали визуальный инструмент, попробуйте удалить оскорбительные столбцы fk и повторно добавить их в инструмент. Я постоянно получал эту ошибку, пока не переработал связи, которые устраняли проблемы.

Ответ 14

Для меня я пытался сопоставить регулярное индексированное поле в дочерней таблице с первичным ключом в родительской таблице, и по умолчанию некоторые интерфейсы GUI для интерфейсов MySQL, такие как Sequel Pro, устанавливают первичный ключ как unsigned, поэтому у вас есть чтобы поля дочернего стола тоже были неподписанными (если только эти поля не содержат отрицательных целых чисел, тогда убедитесь, что они оба подписаны).

Ответ 15

MySQL, как известно, расстроен, особенно в отношении внешних ключей и триггеров. Я сейчас в процессе тонкой настройки одной такой базы данных и столкнулся с этой проблемой. Это не самоочевидно или интуитивно понятно, поэтому вот оно:

Кроме того, проверяя, имеют ли два столбца, которые вы хотите ссылаться в отношении, иметь одинаковый тип данных, вы также должны убедиться, что столбец в таблице, на которую вы ссылаетесь, является индексом. Если вы используете MySQL Workbench, выберите вкладку "Индексы" рядом с "Столбцы" и убедитесь, что столбец, на который ссылается внешний ключ, является индексом. Если нет, создайте его, назовите его чем-то значимым и дайте ему тип "INDEX".

Хорошей практикой является очистка таблиц, связанных с отношениями, чтобы предыдущие попытки не создавали индексы, которые вам не нужны или нужны.

Я надеюсь, что это помогло, некоторые ошибки MySQL безумно отслеживают.

Ответ 16

При создании таблицы обратите внимание на параметры CHARSET и COLLATE. С точки зрения FOREIGN KEY проблемы примерно такие:

CREATE TABLE yourTableName (
....
....
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

В моем случае я не мог создать таблицу с ссылками FOREIGN KEY. Сначала я получил код ошибки 1005, который почти ничего не говорит. Затем я добавил COLLATE и, наконец, сообщение об ошибке, жалующееся на CHARSET.

Error Code: 1253. COLLATION 'utf8_unicode_ci' is not valid for CHARACTER SET 'latin1'

После этой коррекции моя проблема была решена.

Ответ 17

Первый вопрос: могу ли я создать первичный ключ, который также является внешним ключом?

Да. Фактически для workbench MySQL я привык использовать только первичные ключи для внешних ключей. Фактически сокращается случайные ошибки, полученные, например, err: 150, заданные в вопросе.

# ОШИБКА: Ошибка 1005: невозможно создать таблицу dbimmobili.condoni(errno: 150)

У этого есть что-то с индексами, или, более конкретно, как MySQL workbench интерпретирует и работает с ними. Это действительно запутывается, если вы меняете многое в модели (например, внешние ключи, индексы, заказы col), все в одной и той же операции форвардного проектирования, , особенно если база данных находится на другом конце. Например, я не думаю, что автоматически создавал индексы, которые автоматически удаляются после удаления внешнего ключа.

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

1. Сделайте все первичные ключи внешних ключей в таблице поиска (1 в 1 для многих).

В моем случае это связано с изменением идентификатора как pk на имя пользователя в tbl_users, на имя пользователя и компанию в tbl_companies, а также на имя пользователя AND и контакт с пользователем в tbl_company_contacts. Это приложение для нескольких пользователей, чтобы вводить несколько контактов компании, что позволяет перекрывать и удалять контакты других пользователей.

2. Удалите все отношения диаграмм и весь индекс таблицы, которые не являются первичными.

Это устраняет большинство проблем с индексами, которые действительно вызваны баггистым рабочим местом MySQL.

3. Если вы делаете это от начала до конца, отбросьте схему на сервере, так что workbench mysql не путается с существующими индексами и не хватает в модели (проблема вызвана bby index и отношением внешнего ключа, а не только индексом).

Это уменьшает множество решений, которые должны иметь дело с рабочими станциями DB, server и Mysql. Эти решения о том, как переводить инженера, сложны и умны, но несовершенны.

4. Теперь я считаю это обратно квадратным (обычно после проектирования слишком быстро, без ступенчатого процесса). У меня все же есть все столы, но они чисты на этом этапе. Теперь вы просто:

Сначала перейдите инженер, чтобы убедиться, что таблицы (без отношений) работают так, как ожидалось.

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

И тадда, где ты должен был быть.