it-swarm.com.ru

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

Я делаю небольшую базу данных с MySQL Workbench. У меня есть главная таблица, которая называется «Immobili» и имеет первичный ключ, состоящий из четырех столбцов: (Comune, Via, Civico, Immobile).

Теперь у меня также есть три другие таблицы, которые имеют одинаковый первичный ключ (Comune, Via, Civico, Immobile), но эти поля также ссылаются на таблицу Immobili.

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

Второй вопрос: когда я пытаюсь экспортировать изменения, он говорит: Выполнение сценария SQL на сервере

# ERROR: Error 1005: Can't create table 'dbimmobili.condoni' (errno: 150)

CREATE  TABLE IF NOT EXISTS `dbimmobili`.`Condoni` (

  `ComuneImmobile` VARCHAR(50) NOT NULL ,
  `ViaImmobile` VARCHAR(50) NOT NULL ,
  `CivicoImmobile` VARCHAR(5) NOT NULL ,
  `InternoImmobile` VARCHAR(3) NOT NULL ,
  `ProtocolloNumero` VARCHAR(15) NULL ,
  `DataRichiestaSanatoria` DATE NULL ,
  `DataSanatoria` DATE NULL ,
  `SullePartiEsclusive` TINYINT(1) NULL ,
  `SullePartiComuni` TINYINT(1) NULL ,
  `OblazioneInEuro` DOUBLE NULL ,
  `TecnicoOblazione` VARCHAR(45) NULL ,
  `TelefonoTecnico` VARCHAR(15) NULL ,
  INDEX `ComuneImmobile` (`ComuneImmobile` ASC) ,
  INDEX `ViaImmobile` (`ViaImmobile` ASC) ,
  INDEX `CivicoImmobile` (`CivicoImmobile` ASC) ,
  INDEX `InternoImmobile` (`InternoImmobile` ASC) ,

  PRIMARY KEY (`ComuneImmobile`, `ViaImmobile`, `CivicoImmobile`, `InternoImmobile`) ,

  CONSTRAINT `ComuneImmobile`
    FOREIGN KEY (`ComuneImmobile` )
    REFERENCES `dbimmobili`.`Immobile` (`ComuneImmobile` )
    ON DELETE CASCADE
    ON UPDATE CASCADE,

  CONSTRAINT `ViaImmobile`
    FOREIGN KEY (`ViaImmobile` )
    REFERENCES `dbimmobili`.`Immobile` (`ViaImmobile` )
    ON DELETE CASCADE
    ON UPDATE CASCADE,

  CONSTRAINT `CivicoImmobile`
    FOREIGN KEY (`CivicoImmobile` )
    REFERENCES `dbimmobili`.`Immobile` (`CivicoImmobile` )
    ON DELETE CASCADE
    ON UPDATE CASCADE,

  CONSTRAINT `InternoImmobile`
    FOREIGN KEY (`InternoImmobile` )
    REFERENCES `dbimmobili`.`Immobile` (`InternoImmobile` )
    ON DELETE CASCADE
    ON UPDATE CASCADE
) ENGINE = InnoDB

Отображение статуса двигателя:

Ошибка в ограничении внешнего ключа таблицы dbimmobili/valutazionimercato:

Не удается найти индекс в ссылочной таблице, в которой указанные столбцы отображаются как первые столбцы, или столбцы typese в таблице и ссылочной таблице не соответствуют ограничениям. Обратите внимание, что тип внутренней памяти ENUM и SET изменился в таблицах, созданных с помощью> = InnoDB-4.1.12, и на такие столбцы в старых таблицах нельзя ссылаться такими столбцами в новых таблицах.

Где я делаю не так?

36
IssamTP

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

Прецедент:

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)

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

49
Daniel Vassallo

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

29
dmp

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

15
Steve

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

9
Alon Diamant

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

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

6
Wafje

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

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

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

5
iltaf khalid

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

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

4
Sherlock
  1. Убедитесь, что в обеих таблицах используется один и тот же тип Engine.
  2. Убедитесь, что поля, которые вы индексируете, имеют одинаковый тип и длину.
3
Jason Rundell

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

Табличный движок Converted от MyISAM to InnoDB решает проблему для меня.

ALTER TABLE table_name ENGINE=InnoDB;
3
Rizwan Mumtaz

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

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

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

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

1
Fermentation

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

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

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

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

0
Théo T. Carranza

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

0
smo0f

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

0
bluish

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

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

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

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

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

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

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

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

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

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

Это уменьшает множество решений, которые БД, сервер и Mysql Workbench должны принимать. Эти решения о том, как направить инженера, сложны и разумны, но несовершенны.

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

Во-первых, форвард инженер, чтобы убедиться, что таблицы (без связей) работают как положено.

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

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

0
gunslingor

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

0
anesumushate

Обратите внимание на параметрыCHARSETиCOLLATEпри создании таблицы. С точки зрения ИНОСТРАННОГО КЛЮЧА проблемы что-то вроде этого:

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'

После этого исправления моя проблема была решена.

0
sba

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

0
munch1324