MySQL: невозможно создать таблицу (errno: 150)

Я пытаюсь импортировать файл .sql и его отказ при создании таблиц.

Здесь запрос, который не выполняется:

CREATE TABLE `data` (
`id` int(10) unsigned NOT NULL,
`name` varchar(100) NOT NULL,
`value` varchar(15) NOT NULL,
UNIQUE KEY `id` (`id`,`name`),
CONSTRAINT `data_ibfk_1` FOREIGN KEY (`id`) REFERENCES `keywords` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;    

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

MySQL: невозможно создать таблицу. /dbname/data.frm '(errno: 150)

Ответ 1

Из MySQL - FOREIGN KEY Документация по ограничениям:

Если вы воссоздали таблицу, которая была удалена, она должна иметь определение, соответствующее ограничениям внешнего ключа, ссылающимся на него. Он должен иметь правильные имена и типы столбцов, и он должен иметь индексы на ссылочных ключах, как указано ранее. Если они не выполняются, MySQL возвращает Error 1005 и ссылается на Error 150 в сообщении об ошибке, что означает, что ограничение внешнего ключа было неправильно сформировано. Аналогично, если ALTER TABLE не работает из-за ошибки 150, это означает, что определение внешнего ключа будет неправильно сформировано для измененной таблицы.

Ответ 2

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

Ответ 4

Типы данных должны точно соответствовать. Если вы имеете дело с типами varchar, таблицы должны использовать одну и ту же сортировку.

Ответ 5

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

Фактический ответ - это прежде, чем вы начнете восстановление, если вы восстанавливаете файл дампа с помощью внешних ключей:

SET FOREIGN_KEY_CHECKS=0;

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

Ответ 6

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

Ответ 7

Ошибка №. 150 означает сбой ограничения внешнего ключа. Вероятно, вы создаете эту таблицу перед таблицей, за которой зависит внешний ключ (таблица keywords). Сначала создайте эту таблицу, и она будет работать нормально.

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

Ответ 8

Существует немало вещей, которые могут вызвать errno 150, поэтому для людей, которые ищут эту тему, вот что я считаю близким к исчерпывающему списку (источник Причины Errno 150):

Для errno 150 или errno 121, просто набрав SHOW ENGINE INNODB STATUS, появится раздел "ПОСЛЕДНИЙ ИНОСТРАННЫЙ КЛЮЧ КЛЮЧА". В соответствии с этим он даст вам очень полезное сообщение об ошибке, которое, как правило, сразу скажет вам, в чем дело. Вам нужны привилегии SUPER для его запуска, поэтому, если у вас этого нет, вам просто нужно проверить следующие сценарии.

1) Типы данных не совпадают: типы столбцов должны быть одинаковыми

2) Родительские колонки не индексируются (или индексируются в неправильном порядке)

3) Колонки не совпадают

4) Использование SET NULL в столбце NOT NULL

5) Табличные сопоставления не совпадают: даже если сопоставления столбцов совпадают, в некоторых версиях MySQL это может быть проблемой.

6) Родительская колонка на самом деле не существует в родительской таблице. Проверьте орфографию (и, возможно, пробел в начале или конце столбца)

7) Один из индексов на одном из столбцов является неполным, или столбец слишком длинный для полного индекса. Обратите внимание, что MySQL (если вы не настраиваете его) имеет максимальную длину ключа для одного столбца 767 байтов (это соответствует столбцу UTF (varchar) 255)

Если вы получите errno 121, вот несколько причин:

1) Выбранное имя ограничения уже выполнено

2) В некоторых системах, если в ваших операторах и таблицах есть разность случаев. Это может вас укусить, если вы перейдете с одного сервера на другой, который имеет разные правила обработки дел.

Ответ 9

Иногда MySQL просто супер глупый - я могу понять причину возникновения внешних ключей.. но в моем случае я просто сбросил всю базу данных, и я все еще получаю ошибку... почему? я имею в виду, что базы данных больше нет... и я использую sql-user, у меня нет доступа к любому другому db на сервере... я имею в виду, что сервер "пуст" для текущего пользователя, и я все еще получаю эта ошибка? Извините, но я думаю, что MySQL лжет мне... но я могу справиться с этим:) Просто добавьте эти две строки SQL вокруг своего гребаного заявления:

SET FOREIGN_KEY_CHECKS = 0;
# some code that gives you errno: 150
SET FOREIGN_KEY_CHECKS = 1;

Теперь sql должен быть выполнен... Если у вас действительно есть проблема с внешним ключом, это будет отображаться вам по строке, в которой вы снова включите проверки - тогда это не удастся. Но мой сервер просто quiet:)

Ответ 10

150 обычно является ошибкой внешнего ключа. Вы уверены, что таблица ключевых слов существует?

Ответ 11

После прохождения вышеуказанных ответов и экспериментирования это эффективный способ решения ошибок внешнего ключа в MySQL (1005 - ошибка 150).

Чтобы внешний ключ был правильно создан, все запросы MySQL запрашиваются:

  • Все ссылочные ключи ДОЛЖНЫ иметь индекс PRIMARY или UNIQUE.
  • Ссылка на колонку снова ДОЛЖНА иметь идентичный тип данных в столбце "Ссылка".

Удовлетворите эти требования, и все будет хорошо.

Ответ 12

Я испытал эту ошибку, когда портировал приложение Windows в Linux. В Windows имена таблиц базы данных не чувствительны к регистру, а в Linux они чувствительны к регистру, вероятно, из-за различий в файловой системе. Итак, в Windows таблица Table1 такая же, как Table1, а в REFERENCES работают как Table1, так и Table1. В Linux, когда приложение использовало Table1 вместо Table1 при создании структуры базы данных, я увидел ошибку # 150; когда я сделал правильный случай с символом в ссылках Table1, он тоже начал работать с Linux. Итак, если ничего не помогает, убедитесь, что в REFERENCES вы используете правильный регистр символов в имени таблицы, когда вы в Linux.

Ответ 13

Измените двигатели ваших таблиц, только innoDB поддерживает внешние ключи

Ответ 14

Если таблица PK создается в одном CHARSET, а затем вы создаете таблицу FK в другом CHARSET.., то вы также можете получить эту ошибку... Я тоже получил эту ошибку, но после изменения кодировки в PK charset, тогда он был выполнен без ошибок

create table users
(
------------
-------------
)DEFAULT CHARSET=latin1;


create table Emp
(
---------
---------
---------
FOREIGN KEY (userid) REFERENCES users(id) on update cascade on delete cascade)ENGINE=InnoDB, DEFAULT CHARSET=latin1;

Ответ 15

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

Ответ 16

В большинстве случаев проблема возникает из-за ДВИЖЕНИЯ dIfference. Если родительский объект создается InnoDB, тогда таблицы, на которые ссылаются, должны быть созданы MyISAM и наоборот

Ответ 17

В моем случае. У меня были проблемы с движком и кодировкой, потому что мои параметры изменения сервера Хостинга и мои новые таблицы были MyISAM, но мои старые таблицы - InnoDB. Просто я изменился.

Ответ 18

обычно, несоответствие между внешним ключом и первичным ключом вызывает Ошибка:. 150

Внешний ключ должен иметь тот же тип данных, что и первичный ключ. Кроме того, если первичный ключ без знака, то внешний ключ также должен быть без знака.

Ответ 19

У меня была такая же проблема. Это было связано с таблицей Collation и набором символов. Убедитесь, что набор символов и сортировка должны быть одинаковыми для обоих столбцов на двух таблицах. Если вы хотите установить для него внешний ключ. Example- Если вы поместили внешний ключ в столбец userID таблицы userImage, ссылающийся на столбец userID таблицы users. Затем Collation должен быть таким же, как utf8_general_ci, и набор символов utf8 для обоих столбцов таблиц. Как правило, при создании таблицы mysql берет эти две конфигурации из настроек сервера.

Ответ 20

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

Ответ 21

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

Это ограничивало внешние ключи для одного и того же имени базы данных, поэтому переименованная база данных (например, my_db_renamed) имела ограничения внешнего ключа во вновь созданной базе данных (my_db)

Не уверен, что это ошибка в Sequel Pro, или если какой-то прецедент требует такого поведения, но это стоило мне самой лучшей части утра:/

Ответ 22

У меня была такая же ошибка. В моем случае причиной ошибки было то, что у меня был оператор ON DELETE SET NULL в ограничении, в то время как поле, на которое я положил ограничение в его определении, имело инструкцию NOT NULL. Разрешение NULL в поле решало проблему.

Ответ 23

Я столкнулся с такой проблемой при создании БД из текстового файла.

mysql -uroot -padmin < E:\important\sampdb\createdb.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\create_student.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\create_absence.sql

mysql -uroot -padmin sampdb < E:\important\sampdb\insert_student.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\insert_absence.sql

mysql -uroot -padmin sampdb < E:\important\sampdb\load_student.sql
mysql -uroot -padmin sampdb < E:\important\sampdb\load_absence.sql 

Я только что написал выше строки в Create.bat и запустил файл bat.

Моя ошибка в порядке выполнения последовательности в моих файлах sql. Я попытался создать таблицу с первичным ключом, а также с внешним ключом. В то время как его запуск будет искать справочную таблицу, но таблиц там нет. Поэтому он вернет такую ​​ошибку.

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

Ответ 24

У меня была аналогичная проблема, но моя была связана с тем, что я добавлял новое поле в существующую таблицу с данными, а новое поле ссылалось на другое поле из родительской таблицы, а также было Defination of NOT NULL и без каких-либо DEFAULT ЗНАЧЕНИЯ. - Я узнал, что причина не срабатывала, потому что

  • Моему новому полю необходимо было автоматическое заполнение пустых полей значением из родительской таблицы в каждой записи, прежде чем можно было применить ограничение. Каждый раз, когда применяется ограничение, он должен оставить целостность данных таблицы неповрежденной. Внедрение ограничения (внешний ключ), но были некоторые записи базы данных, которые не имели значений из родительской таблицы, означали бы, что данные повреждены, поэтому MySQL НИКОГДА НЕ ПОЗВОЛЯЕТ ВАШЕ СОКРАЩЕНИЕ.

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

Более легкий подход, чтобы избежать этого, заключается в

  • Сохранить данные таблиц базы данных
  • Усечь данные таблицы (и индексы таблицы и т.д.)
  • Применить ограничения
  • Импорт данных

Я надеюсь, что это поможет кому-то

Ответ 25

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

Ответ 26

Убедитесь, что все таблицы могут поддерживать внешний ключ - движок InnoDB

Ответ 27

Столбец таблицы PARENT, к которому вы обращаетесь, из дочерней таблицы должен быть уникальным. Если это не так, вызовите ошибку 150.

Ответ 28

У меня была аналогичная проблема при сбросе базы данных Django mysql с помощью одной таблицы. Я смог решить проблему, сбросив базу данных в текстовый файл, переместив рассматриваемую таблицу в конец файла с помощью emacs и импортировав модифицированный файл дампа sql в новый экземпляр.

HTH Uwe

Ответ 29

Я исправил проблему, приняв переменную accept null

ALTER TABLE `ajout_norme` 
CHANGE `type_norme_code` `type_norme_code` VARCHAR( 2 ) CHARACTER SET utf8 COLLATE utf8_general_ci NULL

Ответ 30

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

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