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: не удается создать таблицу './имя_бд/данных.frm '(errno: 150)
30 ответов:
с MySQL - ограничения внешнего ключа документация:
Если вы повторно создаете таблицу, которая была удалена, она должна иметь определение, соответствующее ограничениям внешнего ключа, ссылающимся на нее. Он должен иметь правильные имена столбцов и типы, а также индексы на ссылочных ключах, как указано ранее. если они не удовлетворены, MySQL возвращает ошибку 1005 и ссылается на ошибку 150 в сообщении об ошибке, что означает, что внешний ключевое ограничение было сформировано неверно. аналогично, если ALTER TABLE не удается из-за ошибки 150, это означает, что определение внешнего ключа будет неправильно сформировано для измененной таблицы.
ошибка 150 означает, что у вас есть проблемы с вашим внешним ключом. Возможно, ключ на внешней таблице не является точно таким же типом?
Вы можете получить фактическое сообщение об ошибке, под управлением
SHOW ENGINE INNODB STATUS;
а потом ищемLATEST FOREIGN KEY ERROR
в выходной.
типы данных должны совпадать. Если вы имеете дело с типами varchar, таблицы должны использовать те же параметры сортировки.
Я думаю, что все эти ответы, хотя и правильные, вводят в заблуждение на вопрос.
фактический ответ, прежде чем начать восстановление, если вы восстанавливаете файл дампа с внешними ключами:
SET FOREIGN_KEY_CHECKS=0;
потому что, естественно, восстановление будет создавать некоторые ограничения, прежде чем внешняя таблица даже существует.
в некоторых случаях вы можете столкнуться с этим сообщением об ошибке, если между связанными таблицами существуют разные механизмы. Например, таблица может использовать InnoDB, в то время как другой использует MyISAM. Оба должны быть одинаковыми
ошибка № 150 означает сбой ограничения внешнего ключа. Вероятно, вы создаете эту таблицу перед таблицей, от которой зависит внешний ключ (table
keywords
). Сначала создайте эту таблицу, и она должна работать нормально.если это не так, удалите оператор внешнего ключа и добавьте его после создания таблицы - вы получите более значимое сообщение об ошибке конкретного ограничения.
есть довольно много вещей, которые могут вызвать errno 150, поэтому для людей, ищущих эту тему, вот то, что я думаю, является близким к исчерпывающему списку (source причины Errno 150):
для errno 150 или errno 121, просто набрав в SHOW ENGINE INNODB STATUS, есть раздел под названием "Последняя ошибка внешнего ключа". При этом он даст вам очень полезное сообщение об ошибке, которое, как правило, сразу скажет вам, в чем дело. Вам нужны супер привилегии, чтобы запустить его, поэтому, если у вас этого нет, вам просто нужно проверить следующие сценарии.
1) Типы данных не совпадают: типы столбцов должны быть одинаковыми
2) родительские столбцы не индексируются (или индексируются в неправильном порядке)
3) параметры сортировки столбцов не совпадают
4) Использование SET NULL в столбце NOT NULL
5) параметры сортировки таблицы не совпадают: даже если параметры сортировки столбцов совпадают, в некоторых версиях MySQL это может быть проблема.
6) Родительский столбец фактически не существует в родительской таблице. Проверки орфографии (и, возможно, пробел в начале или конце столбца)
7) один из индексов на одном из столбцов является неполным, или столбец слишком длинный для полного индекса. Обратите внимание, что MySQL (если вы не настроите его) имеет максимальную длину ключа одного столбца 767 байт(это соответствует столбцу varchar (255) UTF)
в случае, если вы получаете errno 121, вот несколько причины:
1) имя ограничения, которое вы выбрали, уже занято
2) в некоторых системах, если есть разница в регистре в именах операторов и таблиц. Это может укусить вас, если вы переходите с одного сервера на другой, которые имеют разные правила обработки обращений.
иногда MySQL просто супер глуп - я могу понять причину причины внешних ключей.. но в моем случае, я только что сбросил всю базу данных, и я все еще получаю ошибку... зачем? я имею в виду, нет базы данных... и sql-пользователь, которого я использую, не имеет доступа ни к какой другой БД на сервере... я имею в виду, сервер "пуст" для текущего пользователя и я все еще получаю эту ошибку? Извините, но я думаю, что MySQL лжет мне... но я могу справиться с этим :) просто добавьте эти две строки в SQL вокруг гребаное заявление:
SET FOREIGN_KEY_CHECKS = 0; # some code that gives you errno: 150 SET FOREIGN_KEY_CHECKS = 1;
теперь sql должен быть выполнен... Если у вас действительно есть проблема с внешним ключом, она будет отображаться до вас по строке, где вы снова включите проверки-это не удастся.. но мой сервер просто тихий:)
после прохождения ответов выше и немного экспериментируя, это эффективный способ решить ошибки внешнего ключа в MySQL (1005 - error 150).
для правильного создания внешнего ключа все запросы MySQL:
- все ссылочные ключи должны иметь либо первичный, либо уникальный индекс.
- ссылочный столбец снова должен иметь идентичный тип данных для указанного столбца.
удовлетворить эти требования и все будет что ж.
я испытал эту ошибку, когда портировал приложение Windows на Linux. В Windows имена таблиц базы данных нечувствительны к регистру, а в Linux они чувствительны к регистру, вероятно, из-за разницы в файловой системе. Итак, на Windows table
Table1
Это то же самое, чтоtable1
иREFERENCES
иtable1
иTable1
строительство. В Linux, когда приложение используетсяtable1
вместоTable1
когда он создал структуру базы данных, я увидел ошибку #150; когда я сделал правильный регистр символов вTable1
ссылки, он начал работать на Linux. Так что, если ничто другое не помогает, убедитесь, что вREFERENCES
вы используете правильный регистр символов в имени таблицы, когда вы на Linux.
если таблица PK создается в одном CHARSET и затем вы создаете таблицу FK в другой кодировке..тогда также вы можете получить эту ошибку...Я тоже получил эту ошибку, но после изменения кодировки на 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;
эта ошибка может возникнуть, если две таблицы имеют ссылку, например, одна таблица-студент, а другая таблица-образование, и мы хотим, чтобы таблица образования имела ссылку на внешний ключ таблицы Student. В этом случае тип данных столбца для обеих таблиц должен быть одинаковым, иначе это приведет к ошибке.
в большинстве случаев проблема из-за разницы в двигателе .Если родитель создан InnoDB, то ссылочные таблицы должны быть созданы MyISAM & наоборот
в моем случае. У меня были проблемы с движком и кодировкой, потому что мой хостинг-сервер изменил настройки, и мои новые таблицы были MyISAM, но мои старые таблицы InnoDB. Просто я изменился.
У меня была такая же проблема. Это было связано со столбцом таблицы сортировка и Набор Символов. Убедитесь, что Набор Символов и сортировка должно быть одинаковым для обоих столбцов в двух таблицах. Если вы хотите установить внешний ключ на эту. Пример-если вы помещаете внешний ключ в столбец userID таблицы userImage, ссылающийся на столбец userID таблицы users.Тогда параметры сортировки должны быть такими же, что и utf8_general_ci и набор символов utf8 для обе колонки таблиц. Обычно при создании таблицы mysql берет эти две конфигурации из настроек сервера.
пожалуйста, убедитесь, что ваш столбец первичного ключа и ссылочный столбец имеют одинаковые типы данных и атрибуты (unsigned, binary, unsigned zerofill и т. д.).
реальный крайний случай-это когда вы использовали инструмент MySQL (Sequel Pro в моем случае) для переименования базы данных. Затем создается база данных с таким же именем.
Это сохраняло ограничения внешнего ключа для того же имени базы данных, поэтому переименованная база данных (например, my_db_renamed) имела ограничения внешнего ключа во вновь созданной базе данных (my_db)
Не уверен, что это ошибка в Sequel Pro, или если какой-то случай использования требует такого поведения, но это стоило мне лучшей части утра :/
У меня была такая же ошибка. В моем случае причиной ошибки было то, что у меня был оператор on DELETE SET NULL в ограничении, в то время как поле, на которое я поставил ограничение в его определении, имело оператор NOT NULL. Разрешение NULL в поле решило проблему.
У меня была аналогичная проблема , но моя была потому, что я добавлял новое поле в существующую таблицу, в которой были данные, и новое поле ссылалось на другое поле из родительской таблицы, а также имело определение NOT NULL и без каких-либо значений по умолчанию. - Я узнал, что причина, по которой все не работает, была в том, что
- мое новое поле должно было автоматически заполнять пустые поля значением из родительской таблицы для каждой записи, прежде чем ограничение может быть применено. Каждый раз ограничение применяется он должен оставить целостность данных таблицы нетронутыми. Реализация ограничения (внешний ключ) еще были некоторые записи базы данных, которые не имеют значения из родительской таблицы будет означать, что данные повреждены, поэтому MySQL никогда не будет применять ваше ограничение
важно помнить, что в обычных условиях, если вы запланировали свою базу данных задолго до времени, и реализовали ограничения перед вставкой данных в этот конкретный сценарий можно было бы избежать
более простой подход, чтобы избежать этого gotcha является
- сохранить
- усечь табличные данные (и табличные артефакты, т. е. индексы и т. д.)
- применить ограничения
- Импорт Данных
надеюсь, это кому-то поможет
обычно несоответствие между внешним ключом и первичным ключом вызывает ошибка:150.
на внешний ключ должно быть то же самое тип как первичный ключ. Также, если первичный ключ и без подписи тут внешний ключ должно быть без подписи.
возможно этой поможет? Определение столбца первичного ключа должно быть точно таким же, как и столбец внешнего ключа.
столбец родительской таблицы, на который вы ссылаетесь из дочерней таблицы, должен быть уникальным. Если это не так, вызовите ошибку № 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. Mine происходит во время создания таблицы при ссылке внешнего ключа на другую таблицу, которая еще не была создана. Это последовательность существования таблицы перед ссылкой.
решение: создать родительской таблицы перед созданием дочерней таблицы, которая имеет внешний ключ.