Ошибка внешнего ключа MySQL 1005 errno 150
https://stackoverflow.com/questions/4063141
-
27-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я создаю небольшую базу данных с помощью 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:
Не удается найти индекс в таблице, на которую даны ссылки, где столбцы, на которые даны ссылки, отображаются в качестве первых столбцов, или столбцы, указанные в таблице, и таблица, на которую даны ссылки, не соответствуют ограничению.Обратите внимание, что тип внутреннего хранилища ENUM и SET изменился в таблицах, созданных с помощью >= InnoDB-4.1.12, и на такие столбцы в старых таблицах не могут ссылаться такие столбцы в новых таблицах.
Что я делаю не так?
Решение
При создании ограничения внешнего ключа 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)
Это часто не является проблемой в большинстве ситуаций, поскольку ссылочное поле часто является первичным ключом ссылочной таблицы, и первичный ключ проиндексирован автоматически.
Другие советы
Дважды убедитесь, что внешние клавиши имеют точно такой же тип, что и поле, которое вы попали в эту таблицу. Например, оба должны быть целыми (10), либо varchar (8), даже количество символов.
Я понимаю, что это старый пост, но он ранжирует высоко в Google, поэтому я добавляю то, что я понял для моей проблемы. Если у вас есть сочетание типов таблиц (например, myisam и innodb), вы также получите эту ошибку. В этом случае InnoDB - это тип таблицы по умолчанию, но одна таблица нуждалась в FullText Searching, поэтому он был мигрирован в MyISAM. В этой ситуации вы не можете создать внешний ключ в таблице InnoDB, который ссылается на таблицу MyIsam.
Если ваш ключ является Char / Varchar или что-то в этом типе, другая возможная проблема - это другое сопоставление. Проверьте, является ли Charset одинаково.
У меня была эта ошибка и нашла причину ошибки в моем случае. Я все еще отвечаю на этот старый пост, потому что он занимает довольно высоко на Google.
Переменные обоих колонн, которые я хотел связать, были целыми числами, но один из INTS «не знал». Просто не проверяя, которая исправила мою ошибку.
Я получал ту же ошибку.Я нашел решение, заключающееся в том, что я создал первичный ключ в основной таблице как BIGINT БЕЗ ЗНАКА и объявлял его как внешний ключ во второй таблице только как BIGINT.
Когда я объявил свой внешний ключ как BIGINT БЕЗ подписи во второй таблице, все работало нормально, даже не требовалось создавать никаких индексов.
Итак, это было несоответствие типа данных между первичным ключом и внешним ключом :)
У меня была точно такая же проблема, но решение моей проблемы было совершенно другим. У меня было где-то еще в базе данных, внешний ключ с тем же именем. Это вызвало ошибку 1005.
Переименование моего внешнего ключа к чему-то более конкретному для этой ситуации решена проблема.
- Убедитесь, что обе таблицы используют один и тот же тип двигателя.
- Убедитесь, что поля, которые вы являетесь индексацией, имеют тот же тип и длина.
В моем случае ошибка была связана с referencing Таблица MyISAM в то время как referring Таблица была InnoDB.
Converted табличный двигатель от MyISAM to InnoDB решает проблему для меня.
ALTER TABLE table_name ENGINE=InnoDB;
У меня еще нет репутации до голосования Предложению Стива, но это решило мою проблему.
В моем случае я получил эту ошибку, потому что две таблицы, где созданы с использованием разных базы данных, - один был innoDB и другой myisam.
Вы можете изменить тип базы данных, используя: ALTER TABLE T Engine = MyISAM;
@видеть http://dev.mysql.com/doc/refman/5.1/en/storage-engine-setting.html.
Обратить внимание Каприз а также Сопоставлять Параметры при создании таблицы. С точки зрения иностранного ключа Проблемы что-то в этом роде:
CREATE TABLE yourTableName (
....
....
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
В моем случае я не мог создать таблицу с иностранными ключевыми ссылками. Сначала я получил код ошибки 1005, который почти ничего не говорит. потом Я добавил сопоставление И, наконец, сообщение об ошибке жалуется на Charset.
Error Code: 1253. COLLATION 'utf8_unicode_ci' is not valid for CHARACTER SET 'latin1'
После этого коррекция была решена моя проблема.
Это не ваш конкретный случай, но стоит отметить, что эта ошибка может возникнуть, если вы попытаетесь ссылаться на некоторые поля в таблице, которые не являются всеми первичными ключами этой таблицы. Очевидно, это не допускается.
Если у кого-то есть эта ошибка с, казалось бы, хорошо сформированными отношениями FK / PK, и вы использовали визуальный инструмент, попробуйте удалить оскорбительные колонны FK и повторно добавлять их в инструмент. Я постоянно получал эту ошибку, пока я не успокоил соединения, которые очистили проблемы.
Когда a есть 2 столбца для первичных ключей, они составляют композитный первичный ключ, поэтому вы должны убедиться, что в таблице, который ссылается, существует также 2 столбца одного типа данных.
Для меня я пытался сопоставить регулярное индексированное поле в детской таблице, к первичному ключу в родительской таблице, и по умолчанию некоторые MySQL Trestend Guis, как Sequel Pro Установите первичный ключ как unsigned, поэтому вы должны убедиться, что То, что поле для детского стола тоже не соответствует (если эти поля не могут содержать отрицательный INT, то убедитесь, что они оба подписаны).
MySQL является застенчивым капризным, особенно в отношении зарубежных ключей и триггеров. Сейчас я сейчас в процессе тонкой настройки одной такой базы данных и столкнулся с этой проблемой. Это не самоочевидно или интуитивно понятно, поэтому здесь он идет:
Помимо проверки Если два столбца, которые вы хотите ссылаться в отношения, имеют тот же тип данных, вы также должны убедиться, что столбец на таблице вы ссылаетесь, является индексом. Если вы используете Workbench MySQL, выберите вкладку «Индексы» прямо рядом с «столбцами» и убедитесь, что столбец, на который ссылается на внешний ключ, является индексом. Если нет, создайте один, назовите его что-то значимое и дайте ему тип «индекс».
Хорошая практика состоит в том, чтобы убрать таблицы, участвующие в отношениях, чтобы убедиться, что предыдущие попытки не создавали индексов, которые вы не хотите или не нужны.
Я надеюсь, что это помогло, некоторые ошибки MySQL смягчают на отслеживание.
Первый вопрос: Могу ли я сделать первичный ключ, который также является внешним ключом?
да. Фактически для MySQL Workbench я получил привычку использовать только первичные ключи для иностранных ключей. Действительно сокращается на случайных ошибках, подобных ошибкам: 150, указанный в этом вопросе.
# Ошибка: ошибка 1005: не может создать таблицу 'dbimmobili.condoni' (errno: 150)
У этого есть что-то с указателями или конкретно, как Workbench MySQL интерпретирует и работает с ними. Это действительно запутается, если вы много измените в модели (например, зарубежные ключевые ключи, индексы, соль заказы) все в той же форвардной инженерной работе, особенно если уже есть база данных на другом конце. Отказ Например, я не думаю, что автоматически создал индексы, где автоматически удаляется после удаления внешнего ключа.
Вот что я сделал, чтобы исправить ошибку вашего получения. Примечание, кажется громоздким, но по сравнению с количеством времени, которое я потратил с использованием других методов, это не так.
1. Составьте все основные ключи внешних клавиш в таблице поиска (1 в 1 до многих).
В моем случае это связано с изменением идентификатора в качестве PK для имени пользователя в TBL_USERS, для имени пользователя и компании в TBL_Companies и имени пользователя и компании и контакта в TBL_Company_Contacts. Это приложение для нескольких пользователей для ввода нескольких контактов компании, позволяя перекрывать и скрывать контакты других пользователей.
2. Удалите все отношения диаграммы и все индекс таблицы, которые не являются первичными ключами.
Это исправляет большую часть вопросов индекса, которые действительно вызваны баггим MySQL Workbench.
3. Если вы выполняете это от начала до конца, опустите схему на сервере, поэтому Workbench MySQL не путают в существующих индексах и отсутствуют там в модели (выпуск вызван индекс BBY и внешние отношения, а не один индекс ).
Это уменьшает много решений, которые DB, Server и MySQL Workbench должны иметь многое. Эти решения о том, как переслать инженер-что-то сложное и умно, но несовершенны.
4. Теперь я считаю это обратно на квадратную (как правило, после того, как проектирует слишком быстро без шагового процесса). У меня все еще есть все столы, но они чистые на этом этапе. Теперь вы только что:
Первый, передний инженер, чтобы убедиться, что таблицы (без отношений) работают как ожидалось.
Следуйте в цепочке отношений вниз по первичным ключам, начиная с максимального уровня, начиная с максимальной работы (я мое дело tbl_users to tbl_companies). После каждой связи всегда постоянный инженер, чтобы убедиться, что это пробеги, затем сохранить модель и закрыть, затем обратный инженер модели, чтобы убедиться, что она занимает. Отказ Это позволяет быстро изолировать проблемы, когда они возникают, в моем случае, оставленный индекс, используемым старым удаленным внешним ключами (произошло 2-3 раза).
И Тадда, назад, где вам нужно было.
