Ошибка 1005 mysql

Дата: 2.12.2016

Автор: Василий Лукьянчиков , vl (at) sqlinfo (dot) ru

Функционирование внешних ключей в MySQL имеет много нюансов и ограничений из-за чего существует немало возможностей получить ошибку при работе с ними. Одна из проблем состоит в том, что сообщения об ошибках содержат мало полезной информации и не указывают причину возникновения ошибки. В данной статье дается объяснение как получить дополнительную информацию об ошибке и приведен полный список причин возникновения ошибок внешних ключей. Каждая причина снабжена уникальным буквенно-цифровым кодом (А4, Б1, ..), использующимся в сводной таблице в конце статьи, которая поможет вам быстро диагностировать проблему.

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

В MySQL внешние ключи не реализованы на уровне сервера, их поддержка зависит от используемого хранилища данных. Содержание статьи справедливо для InnoDB (в том числе и для XtraDB).

Как получить больше данных об ошибке

После получения ошибки выполните SHOW ENGINE INNODB STATUS и смотрите содержимое секции LATEST FOREIGN KEY ERROR. Этот способ имеет следующие недостатки:

• требует привилегии SUPER
• содержит информацию о последней ошибке, связанной с внешними ключами, из-за чего нужно выполнять SHOW ENGINE INNODB STATUS сразу после возникновения ошибки, что не всегда удобно/возможно
• используются внутренние имена таблиц (например, ‘test.#sql-d88_b’), что затрудняет диагностику
• порой содержит мало полезной информации или таковая вообще отсутствует.

Альтернатива: использовать MariaDB версий больше 5.5.45 и 10.0.21, в которых сообщения об ошибках значительно улучшены и указывают причину возникновения ошибки.

Errno 150

Если в сообщении об ошибке содержится errno 150 (или errno 121), значит парсер MySQL не смог распознать ошибку и передал команду (create/alter) на выполнение в InnoDB. В этом разделе перечислены ситуации, приводящие к ошибкам, содержащим errno 150.

А1. Нет индекса в родительской таблице. Набор полей, на которые ссылается дочерняя таблица, должен быть проиндексирован (или являться левой частью другого индекса). Порядок полей в индексе должен быть таким же как в определении внешнего ключа. Сюда же относится случай отсутствия нужной колонки в родительской таблице (нет колонки, нет и индекса).

Неочевидный момент: на колонке родительской таблицы есть индекс — полнотекстовый (fulltext). Но внешний ключ всё равно не создается и сервер ругается на отсутствие индекса. Это происходит потому, что индекс должен быть обычным (btree).

Другой неочевидный момент: на колонке родительской таблицы есть индекс — префиксный. Но внешний ключ всё равно не создается и сервер ругается на отсутствие индекса. Это происходит потому, что индекс должен быть определен на всей длине колонки.

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

А2. Родительская таблица не найдена в словаре данных InnoDB. Это означает, что родительская таблица должна существовать и быть постоянной InnoDB таблицей. Не временной InnoDB таблицей, так как информация о временных таблицах не сохраняется в словаре данных InnoDB. И уж тем более не представлением.

А3. Синтаксическая ошибка. Внешние ключи реализованы на уровне хранилища, и в старых версиях парсер сервера MySQL не распознавал синтаксические ошибки внешних ключей, из-за чего их было трудно идентифицировать.

А4. Несовпадение типов данных. Столбцы дочерней таблицы, входящие в определение внешнего ключа, должны иметь такие же типы данных, что и столбцы родительской таблицы, на которые они ссылаются, вплоть до атрибутов: знак и кодировка/сопоставление.

А5. Некорректно задано действие внешнего ключа. Если в определении внешнего ключа указано ON UPDATE SET NULL и/или ON DELETE SET NULL, то соответствующие столбцы дочерней таблицы не должны быть определены как NOT NULL.

А6. Дочерняя таблица является временной InnoDB таблицей. Внешние ключи можно создавать только в постоянной, несекционированной InnoDB таблице.

А7. Родительская таблица является секционированной таблицей. На данный момент (MySQL 5.7 и MariaDB 10.1) внешние ключи не поддерживаются для секционированных таблиц (partitioned tables). Иными словами, ни родительская, ни дочерняя таблица не должны иметь секции. В случае, когда внешний ключ ссылается на секционированную таблицу диагностика ошибки затруднена ошибкой вывода show engine innodb status:

Errno 121

Такой результат возникает только в одном случае.

Б1. Неуникальное имя ограничения. Обратите внимание: речь не о имени внешнего ключа. Если при создании внешнего ключа вы указываете не обязательное ключевое слово CONSTRAINT, то идущий после него идентификатор должен быть уникальным в пределах базы данных.

Нет ошибок

Внешний ключ не создается, и нет никаких ошибок. Это может происходить по следующим причинам:

В1. Дочерняя таблица не является InnoDB таблицей. В этом случае для совместимости с другими субд парсер MySQL просто проигнорирует конструкцию внешнего ключа.

В2. Не соответствует синтаксису MySQL. Стандарт SQL разрешает указывать внешний ключ сразу при объявлении колонки с помощью конструкции REFERENCES (например, … a int references t1(a), …), однако MySQL игнорирует такую форму записи. Единственный способ создать в нем внешний ключ — это использовать отдельный блок FOREIGN KEY:

Несоответствие данных

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

Г1. Удаление родительской таблицы. Нельзя удалить родительскую таблицу при наличии внешнего ключа.

Удаление следует понимать в расширенном варианте как удаление из множества InnoDB таблиц. Например, если мы сменим (alter table) движок родительской таблицы на MyISAM, то с точки зрения ограничения внешнего ключа родительская таблица перестанет существовать (т.к. она должна быть постоянной innodb таблицей):

alter table t1 engine=myisam;
ERROR 1217 (23000): Cannot delete or update a parent row: a foreign key constraint fails

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

select table_name from information_schema.key_column_usage
where table_schema = «test» and references_table_name = «t1»;

Г2. Изменение данных в родительской таблице. Если в определении внешнего ключа не задано действие при update/delete, то такие операции над родительской таблицей могут привести к несогласованности данных, т.е. появлению в дочерней таблице записей не имеющих соответствия в родительской таблице.

Г3. Изменение данных в дочерней таблице. Если insert/update записи в дочерней таблицы приводит к несогласованности данных, то

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

Г5. Не уникальный ключ в родительской таблице. По стандарту SQL набор полей, на которые ссылается внешний ключ, должен быть уникальным. Однако, реализация внешних ключей в InnoDB позволяет иметь несколько «родителей». Из-за этого возникает трудно диагностируемая ошибка:

Сводная таблица

По вертикали расположены коды ошибок MySQL, которые возникают при работе с внешними ключами («нет ошибок» соответствует ситуации, когда сервер не генерирует ошибку, но и не создает внешний ключ). По горизонтали — идентификаторы причин, которые могут привести к ошибке. Плюсы на пересечении указывают какие причины приводят к той или иной ошибке.

P.S. Если ваш случай не рассмотрен в статье, то задавайте вопрос на форуме SQLinfo. Вам ответят, а статья будет расширена.

Дата публикации: 2.12.2016

© Все права на данную статью принадлежат порталу SQLInfo.ru. Перепечатка в интернет-изданиях разрешается только с указанием автора и прямой ссылки на оригинальную статью. Перепечатка в бумажных изданиях допускается только с разрешения редакции.

Доброй ночи! Столкнулся с проблемой, не загружает бэкап!
Собственно сама ошибка:

Ошибка
SQL-запрос:

CREATE TABLE  `blogs` (

 `id` INT( 10 ) UNSIGNED NOT NULL AUTO_INCREMENT ,
 `user_id` INT( 10 ) UNSIGNED NOT NULL ,
 `ctg_id` SMALLINT( 5 ) UNSIGNED NOT NULL ,
 `dt` DATETIME NOT NULL ,
 `title` VARCHAR( 255 ) DEFAULT NULL ,
 `content` TEXT NOT NULL ,
PRIMARY KEY (  `id` ) ,
KEY  `blogusr` (  `user_id` ) ,
CONSTRAINT  `blogusr` FOREIGN KEY (  `user_id` ) REFERENCES  `users` (  `id` ) ON DELETE CASCADE
) ENGINE = INNODB AUTO_INCREMENT =14 /*!40101 DEFAULT CHARSET=utf8 */;


#1005 - Can't create table 'test.blogs' (errno: 150)

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

P.S. Хотел выложить ссылку на саму БД, но не знаю разрешено это или нет.

This fails when trying to create the EXCHANGE table:

CREATE TABLE BOOK
(PKACC_NO VARCHAR (20) PRIMARY KEY,
TITLE VARCHAR (50),
AUTHOR VARCHAR (50),
PUBLISHER VARCHAR (50),
EDITION INTEGER (4),
PRICE INTEGER (10));

CREATE TABLE MEMBER
(PKMEMBER_ID VARCHAR (20) PRIMARY KEY,
NAME VARCHAR (50),
TYPE VARCHAR (10),
CONTACT_NO BIGINT (10),
ADHAAR_NO BIGINT(12),
LAST_VISIT DATE );

CREATE TABLE STAFF
(PKSTAFF_ID VARCHAR (20),
NAME VARCHAR(50),
ADHAAR_NO BIGINT (12),
CONTACT_NO BIGINT(10) );

CREATE TABLE EXCHANGE 
(TRANSACTION_ID VARCHAR(20) PRIMARY KEY,
FK1ACC_NO VARCHAR(20),
FK2MEMBER_ID VARCHAR (20),
FK3STAFF_ID VARCHAR(20),
DATE_OF_ISSUE DATE,
DATE_OF_RETURN DATE,
FINE INTEGER(20),
REMARKS VARCHAR(20),
CONSTRAINT FK1 FOREIGN KEY (FK1ACC_NO) REFERENCES BOOK (PKACC_NO)
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT FK2 FOREIGN KEY (FK2MEMBER_ID) REFERENCES MEMBER (PKMEMBER_ID)
ON DELETE CASCADE
ON UPDATE CASCADE,
CONSTRAINT FK3 FOREIGN KEY (FK3STAFF_ID) REFERENCES STAFF (PKSTAFF_ID)
ON DELETE CASCADE
ON UPDATE CASCADE);

The last create statement returns:

ERROR 1005 (HY000): Can't create table `testdb`.`EXCHANGE` (errno: 150 "Foreign key constraint is incorrectly formed")

[Solved-4 Solutions] error 1005 Can’t create table (errno 121)

Error Description:

Error 1005 Can’t create table (errno 121)

Solution 1:

We will get this message if we’re trying to add a constraint with a name that’s already used somewhere else

To check constraints use the following SQL query:

SELECT
constraint_name,
table_name
FROM
information_schema.table_constraints
WHERE
constraint_type = 'FOREIGN KEY'
ANDtable_schema = DATABASE()
ORDERBY
constraint_name;

Solution 2:

Foreign Key Constraint Names Have to be Unique Within a Database

<TABLE_NAME>_<FOREIGN_KEY_COLUMN_NAME>_fk

Solution 3:

There is no need to name our constraints, but if we do, then that is the name that must be unique within each schema. The error is telling us that we already have constraints with the same name elsewhere.

To see where, We can Show Engine Innodb Status;

------------------------
LATEST FOREIGNKEY ERROR
------------------------
13012919:45:00 Error inforeignkeyconstraint creation fortable`test`.`baz`.
A foreignkeyconstraintof name `test`.`foo_id`
alreadyexists.

But in this case, we don’t need to look that up, since it’s apparent from the script that we are reusing the same constraint names in multiple table definitions.

FOREIGNKEY(`Comune`)
REFERENCES`PROGETTO`.`PAESE`(`Comune`)
ONDELETE NO ACTION
ONUPDATECASCADE)

We should not have a problem. we will find that InnoDB will generate names for our constraints, like PAESE_ibfk_1, PAESE_ibfk_2, etc.

Solution 4:

SELECT*FROM INFORMATION_SCHEMA.INNODB_SYS_TABLES WHERE NAME LIKE'%#sql%';

find .-iname'#*'

After discovering the filename, such as #sql-9ad_15.frm, we was able to drop that orphaned table in MySQL:

USEmyschema;
DROPTABLE`#mysql50##sql-9ad_15`;

After doing so, we was then able to successfully run my ALTER TABLE.