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)

Из документации MySQL – FOREIGN KEY Constraints :

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

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

Вы можете получить фактическое сообщение об ошибке, запустив SHOW ENGINE INNODB STATUS; а затем ищет LATEST FOREIGN KEY ERROR на выходе.

Источник: ответ от другого пользователя по аналогичному вопросу

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

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

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

 SET FOREIGN_KEY_CHECKS=0; 

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

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

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

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

Существует немало вещей, которые могут вызвать 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) В некоторых системах, если в ваших операторах и именах таблиц есть разность случаев. Это может укусить вас, если вы перейдете с одного сервера на другой, у которого есть разные правила обработки дела.

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

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

Теперь sql должен быть выполнен … Если у вас действительно есть проблема с внешним ключом, это будет отображаться вам по строке, где вы снова включите проверки – это не сработает тогда .. но мой сервер просто тихий 🙂

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

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

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

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

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

У меня была такая же ошибка, затем я создал таблицу, на которую ссылался, а затем ссылался на таблицу

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

это сработало для меня …

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

Если таблица PK создается в одном CHARSET, а затем вы создаете таблицу FK в другом CHARSET .., то вы также можете получить эту ошибку … Я тоже получил эту ошибку, но после изменения 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; 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

HTH Uwe

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

 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. Я попытался создать таблицу с первичным ключом, а также с внешним ключом. В то время как его запуск будет искать справочную таблицу, но таблиц там нет. Поэтому он вернет такую ​​ошибку.

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

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

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

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

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

Создайте таблицу без внешнего ключа, затем установите внешний ключ отдельно.

  • MySQL: нет в GROUP BY
  • Каковы варианты использования CHAR над VARCHAR в SQL?
  • Ошибка: Столбец не существует
  • Создайте дату с дневного месяца и года с помощью T-SQL
  • Почему отношение первично-иностранного ключа требуется, когда мы можем присоединиться без него?
  • Является ли LIKE-оператор чувствительным к регистру с сервером MSSQL?
  • Сортировка столбца строки, содержащего числа в SQL?
  • PostgreSQL «Столбец не существует», но на самом деле он
  • Драйвер не смог установить безопасное соединение с SQL Server с использованием шифрования Secure Sockets Layer (SSL)
  • Excel VBA: запись в базу данных mysql
  • Как реализовать отношения «многие ко многим» в PostgreSQL?
  • Давайте будем гением компьютера.