Error 1215 de MySQL: no se puede agregar la restricción de clave externa

Estoy tratando de reenviar mi nuevo esquema en mi servidor db, pero no puedo entender por qué recibo este error. He intentado buscar la respuesta aquí, pero todo lo que he encontrado me dice que configure el motor de db en Innodb o que me asegure de que las claves que intento utilizar como clave foránea sean claves primarias en sus propias tablas. . He hecho ambas cosas, si no me equivoco. ¿Alguna otra ayuda que ustedes puedan ofrecer?

Executing SQL script in server

ERROR: Error 1215: Cannot add foreign key constraint

-- -----------------------------------------------------
-- Table `Alternative_Pathways`.`Clients_has_Staff`
-- -----------------------------------------------------

CREATE  TABLE IF NOT EXISTS `Alternative_Pathways`.`Clients_has_Staff` (
  `Clients_Case_Number` INT NOT NULL ,
  `Staff_Emp_ID` INT NOT NULL ,
  PRIMARY KEY (`Clients_Case_Number`, `Staff_Emp_ID`) ,
  INDEX `fk_Clients_has_Staff_Staff1_idx` (`Staff_Emp_ID` ASC) ,
  INDEX `fk_Clients_has_Staff_Clients_idx` (`Clients_Case_Number` ASC) ,
  CONSTRAINT `fk_Clients_has_Staff_Clients`
    FOREIGN KEY (`Clients_Case_Number` )
    REFERENCES `Alternative_Pathways`.`Clients` (`Case_Number` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_Clients_has_Staff_Staff1`
    FOREIGN KEY (`Staff_Emp_ID` )
    REFERENCES `Alternative_Pathways`.`Staff` (`Emp_ID` )
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB

Ejecución de script SQL finalizada: declaraciones: 7 exitosas, 1 falló

Aquí está el SQL para las tablas padre.

CREATE  TABLE IF NOT EXISTS `Alternative_Pathways`.`Clients` (
  `Case_Number` INT NOT NULL ,
  `First_Name` CHAR(10) NULL ,
  `Middle_Name` CHAR(10) NULL ,
  `Last_Name` CHAR(10) NULL ,
  `Address` CHAR(50) NULL ,
  `Phone_Number` INT(10) NULL ,
  PRIMARY KEY (`Case_Number`) )
ENGINE = InnoDB

CREATE  TABLE IF NOT EXISTS `Alternative_Pathways`.`Staff` (
  `Emp_ID` INT NOT NULL ,
  `First_Name` CHAR(10) NULL ,
  `Middle_Name` CHAR(10) NULL ,
  `Last_Name` CHAR(10) NULL ,
  PRIMARY KEY (`Emp_ID`) )
ENGINE = InnoDB

Supongo que Clients.Case_Numbery / o Staff.Emp_IDno son exactamente el mismo tipo de datos que Clients_has_Staff.Clients_Case_Numbery Clients_has_Staff.Staff_Emp_ID.

Quizás las columnas en las tablas principales son INT UNSIGNED?

Deben ser exactamente el mismo tipo de datos en ambas tablas.

Razones por las que puede obtener un error de restricción de clave externa:

1. No está utilizando InnoDB como motor en todas las tablas.
2. Está intentando hacer referencia a una clave inexistente en la tabla de destino. Asegúrate de que sea una clave en la otra tabla (puede ser una clave primaria o única)
3. Los tipos de las columnas no son iguales (la excepción es que la columna en la tabla de referencia puede ser anulable).
4. Si el PK / FK es un varchar, asegúrese de que la clasificación sea la misma para ambos.

Actualizar:

5. Una de las razones también puede ser que la columna que está utilizando ON DELETE SET NULLno está definida como nula. Por lo tanto, asegúrese de que la columna esté configurada como nula por defecto.

Mira esto.

Para otros, el mismo error no siempre se debe a una falta de coincidencia del tipo de columna, puede encontrar más información sobre un error de clave foránea de mysql emitiendo un comando

SHOW ENGINE INNODB STATUS;

puede encontrar un error cerca de la parte superior del mensaje impreso, algo así como

No se puede encontrar un índice en la tabla referenciada donde las columnas referenciadas aparecen como las primeras columnas, o los tipos de columna en la tabla y la tabla referenciada no coinciden para la restricción.

El error 1215 es molesto. La respuesta de la píldora de explosión cubre lo básico. Debes asegurarte de comenzar desde allí. Sin embargo, hay más, mucho más casos sutiles a tener en cuenta:

Por ejemplo, cuando intente vincular CLAVES PRIMARIAS de diferentes tablas, asegúrese de proporcionar opciones ON UPDATEy ON DELETEopciones adecuadas . P.ej:

...
PRIMARY KEY (`id`),
FOREIGN KEY (`id`) REFERENCES `t` (`other_id`) ON DELETE SET NULL
....

no volará, porque las CLAVES PRIMARIAS (como id) no pueden ser NULL.

Estoy seguro de que hay problemas aún más sutiles al agregar este tipo de restricciones, razón por la cual al encontrar errores de restricción, siempre asegúrese de que las restricciones y sus implicaciones tengan sentido en su contexto actual. ¡Buena suerte con tu error 1215!

Verifique la clasificación de la tabla, utilizando SHOW TABLE STATUSpuede verificar la información sobre las tablas, incluida la clasificación.

Ambas tablas tienen que tener la misma colación.

Me ha pasado a mi

En mi caso, había eliminado una tabla usando SET FOREIGN_KEY_CHECKS=0, luego SET FOREIGN_KEY_CHECKS=1después. Cuando fui a recargar la mesa, lo conseguí error 1215. El problema era que había otra tabla en la base de datos que tenía una clave externa para la tabla que había eliminado y que estaba volviendo a cargar. Parte del proceso de recarga implicaba cambiar un tipo de datos para uno de los campos, lo que invalidaba la clave externa de la otra tabla, por lo tanto, se disparaba error 1215. Resolví el problema soltando y luego volviendo a cargar la otra tabla con el nuevo tipo de datos para el campo involucrado.

Obtuve el mismo error al intentar agregar un fk. En mi caso, el problema fue causado por la PK de la tabla FK que estaba marcada como sin firmar.

Hay un obstáculo que he experimentado con el "Error 1215: No se puede agregar una restricción de clave externa" cuando uso Laravel 4, especialmente con los Generadores Laravel 4 de JeffreyWay.

En Laravel 4, puede usar los Generadores de JeffreyWay para generar archivos de migración para crear tablas una por una, lo que significa que cada archivo de migración genera una tabla. Debe tener en cuenta el hecho de que cada archivo de migración se genera con una marca de tiempo en el nombre del archivo, lo que les da un orden. El orden de generación es también el orden de operación de migración cuando se activa el comando Artisan CLI "php artisan migrate". Por lo tanto, si un archivo solicita una restricción de clave externa que se refiere a una clave que se generará, pero todavía no, en un último archivo, se activa el Error 1215. En tal caso, lo que debe hacer es ajustar el orden de generación de los archivos de migración. Genere nuevos archivos en el orden correcto, copie el contenido y luego elimine los archivos viejos desordenados.

Tuve el mismo problema, mi solución:

Antes de:

CREATE TABLE EMPRES
( NoFilm smallint NOT NULL

  PRIMARY KEY (NoFilm)

  FOREIGN KEY (NoFilm) REFERENCES cassettes

);

Solución:

CREATE TABLE EMPRES
(NoFilm smallint NOT NULL REFERENCES cassettes,

 PRIMARY KEY (NoFilm)

);

Espero que sea de ayuda;)

Yo tuve el mismo problema.
Lo resolví haciendo esto:

Creé la siguiente línea en el
primary key: (id int(11) unsigned NOT NULL AUTO_INCREMENT)

Descubrí esta solución después de intentar importar una tabla en mi generador de esquemas. Si te funciona, ¡házmelo saber!

¡Buena suerte!

Felipe Tércio

Solo quería agregar este caso también para VARCHAR la relación de clave externa. Pasé la última semana tratando de resolver esto en MySQL Workbench 8.0 y finalmente pude corregir el error.

Respuesta corta: el conjunto de caracteres y la clasificación del esquema, la tabla, la columna, la tabla de referencia, la columna de referencia y cualquier otra tabla que haga referencia a la tabla principal deben coincidir.

Respuesta larga: tenía un tipo de datos ENUM en mi tabla. Cambié esto a VARCHARy puedo obtener los valores de una tabla de referencia para no tener que alterar la tabla principal para agregar opciones adicionales. Esta relación de clave externa parecía sencilla pero obtuve un error 1215. La respuesta de arvind y el siguiente enlace sugirieron el uso de

SHOW ENGINE INNODB STATUS;

Al usar este comando, obtuve la siguiente descripción detallada del error sin información útil adicional

No se puede encontrar un índice en la tabla referenciada donde las columnas referenciadas aparecen como las primeras columnas, o los tipos de columna en la tabla y la tabla referenciada no coinciden para la restricción. Tenga en cuenta que el tipo de almacenamiento interno de ENUM y SET cambió en las tablas creadas con> = InnoDB-4.1.12, y las columnas de las tablas antiguas no pueden hacer referencia a ellas en las tablas nuevas. Consulte http://dev.mysql.com/doc/refman/8.0/en/innodb-foreign-key-constraints.html para obtener la definición correcta de la clave externa.

Después de lo cual utilicé SET FOREIGN_KEY_CHECKS=0;según lo sugerido por Arvind Bharadwaj y el enlace aquí :

Esto dio el siguiente mensaje de error:

Código de error: 1822. Error al agregar la restricción de clave externa. Falta el índice para la restricción

En este punto, hice una 'ingeniería inversa' del esquema y pude establecer la relación de clave externa en el diagrama EER. En 'ingeniería avanzada', recibí el siguiente error:

Error 1452: no se puede agregar o actualizar una fila secundaria: falla una restricción de clave externa

Cuando 'reenvié a los ingenieros' el diagrama EER a un nuevo esquema, el script SQL se ejecutó sin problemas. Al comparar el SQL generado a partir de los intentos de reenviar la ingeniería, descubrí que la diferencia era el conjunto de caracteres y la clasificación. La tabla primaria, la tabla secundaria y las dos columnas tenían un utf8mb4conjunto de caracteres y una utf8mb4_0900_ai_ciclasificación, sin embargo, se hizo referencia CHARACTER SET = utf8 , COLLATE = utf8_bin ;a otra columna de la tabla primaria utilizando una tabla secundaria diferente.

Para todo el esquema, cambié el conjunto de caracteres y la clasificación de todas las tablas y todas las columnas a lo siguiente:

CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci;

Esto finalmente resolvió mi problema con el error 1215.

Nota al margen: La clasificación utf8mb4_general_cifunciona en MySQL Workbench 5.0 o posterior. La clasificación utf8mb4_0900_ai_cifunciona solo para MySQL Workbench 8.0 o superior. Creo que una de las razones por las que tuve problemas con el conjunto de caracteres y la recopilación se debe a la actualización de MySQL Workbench a 8.0 en el medio. Aquí hay un enlace que habla más sobre esta recopilación.

No puedo encontrar este error

CREATE TABLE RATING (

Riv_Id INT(5),
Mov_Id INT(10) DEFAULT 0,
Stars INT(5),
Rating_date DATE, 

PRIMARY KEY (Riv_Id, Mov_Id),

FOREIGN KEY (Riv_Id) REFERENCES REVIEWER(Reviewer_ID)
ON DELETE SET NULL ON UPDATE CASCADE,

FOREIGN KEY (Mov_Id) REFERENCES MOVIE(Movie_ID)
ON DELETE SET DEFAULT ON UPDATE CASCADE
)

Esto también sucede cuando el tipo de las columnas no es el mismo.

por ejemplo, si la columna a la que se refiere es INT NO FIRMADA y la columna a la que se hace referencia es INT, obtendrá este error.

Para MySQL (INNODB) ... obtenga definiciones para las columnas que desea vincular

SELECT * FROM information_schema.columns WHERE 
TABLE_NAME IN (tb_name','referenced_table_name') AND 
COLUMN_NAME  IN ('col_name','referenced_col_name')\G

comparar y verificar ambas definiciones de columna tienen

mismo COLUMN_TYPE (longitud), mismo COLATION

podría ser útil para jugar como

set foreign_key_checks=0;
ALTER TABLE tb_name ADD FOREIGN KEY(col_name) REFERENCES ref_table(ref_column) ON DELETE ...
set foreign_key_checks=1;

Verifique la compatibilidad de la tabla. Por ejemplo, si una tabla es MyISAMy la otra es InnoDB, puede tener este problema.

Otra razón: si usa ON DELETE SET NULL todas las columnas que se usan en la clave externa, debe permitir valores nulos. Alguien más descubrió esto en esta pregunta .

Según tengo entendido, no sería un problema con respecto a la integridad de los datos, pero parece que MySQL simplemente no admite esta función (en 5.7).

Cuando se produce este error porque la tabla referenciada usa el motor MyISAM, esta respuesta proporciona una forma rápida de convertir su base de datos para que todas las tablas de modelos de Django usen InnoDB: https://stackoverflow.com/a/15389961/2950621

Es un comando de administración de Django llamado convert_to_innodb.

Wooo lo acabo de conseguir! Fue una mezcla de muchas respuestas ya publicadas (innoDB, sin firmar, etc.). Sin embargo, una cosa que no vi aquí es: si su FK apunta a una PK, asegúrese de que la columna fuente tenga un valor que tenga sentido. Por ejemplo, si la PK es una mediaint (8), asegúrese de que la columna fuente también contenga una mediaint (8). Eso fue parte del problema para mí.

Para mí fueron los tipos de columna. BigINT! = INT.

Pero entonces todavía no funcionó.

Así que revisé los motores. Asegúrese de que Table1 = InnoDB y Table = InnoDB

Experimenté este error por una razón completamente diferente. Usé MySQL Workbench 6.3 para crear mi modelo de datos (herramienta increíble). Noté que cuando el orden de columnas definido en la definición de restricción de clave externa no se ajusta a la secuencia de columnas de la tabla, también se genera este error.

Me llevó alrededor de 4 horas probar todo lo demás, excepto comprobar eso.

Ahora todo funciona bien y puedo volver a la codificación. :-)

cuando intente crear una clave externa cuando use la migración de laravel

como este ejemplo:

tabla de usuario

    public function up()
{
    Schema::create('flights', function (Blueprint $table) {
        $table->increments('id');
        $table->string('name');
        $table->TinyInteger('color_id')->unsigned();
        $table->foreign('color_id')->references('id')->on('colors');
        $table->timestamps();
    });
}

tabla de colores

    public function up()
{
    Schema::create('flights', function (Blueprint $table) {
        $table->increments('id');
        $table->string('color');
        $table->timestamps();
    });
}

a veces las propiedades no funcionaban

[PDOException]
SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint

este error ocurrió porque la clave externa (tipo) en [tabla de usuario] es diferente de la clave primaria (tipo) en [tabla de colores]

Para resolver este problema debe cambiar la clave primaria en [tabla de colores]

$table->tinyIncrements('id');

Cuando usas la clave primaria $table->Increments('id');

debes usar Integercomo clave foránea

    $table-> unsignedInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

Cuando usas la clave primaria $table->tinyIncrements('id');

debes usar unsignedTinyIntegercomo clave foránea

    $table-> unsignedTinyInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

Cuando usas la clave primaria $table->smallIncrements('id');

debes usar unsignedSmallIntegercomo clave foránea

    $table-> unsignedSmallInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

Cuando usas la clave primaria $table->mediumIncrements('id');

debes usar unsignedMediumIntegercomo clave foránea

    $table-> unsignedMediumInteger('fk_id');
    $table->foreign('fk_id')->references('id')->on('table_name');

En mi caso, tuve que desactivar las FOREIGN KEYcomprobaciones ya que las tablas de origen no existían.

SET FOREIGN_KEY_CHECKS=0;

Tenga en cuenta el uso de backquotes también. Tenía en un guión la siguiente declaración

ALTER TABLE service ADD FOREIGN KEY (create_by) REFERENCES `system_user(id)`;

pero las citas al final eran falsas. Debería haber sido:

ALTER TABLE service ADD FOREIGN KEY (create_by) REFERENCES `system_user`(`id`);

MySQL lamentablemente no proporciona detalles sobre este error ...

Otra fuente de este error es que tiene 2 o más nombres de tabla iguales que tienen los mismos nombres de clave externa. Esto a veces les sucede a las personas que usan software de modelado y diseño, como Mysql Workbench, y luego generan el script a partir del diseño.

Sé que llego MUY tarde a la fiesta, pero quiero publicarlo aquí para que aparezca en la lista.

Además de todos los consejos anteriores para asegurarse de que los campos estén definidos de manera idéntica y que los tipos de tabla también tengan la misma clasificación, asegúrese de no cometer el error de novato de intentar vincular campos donde los datos en el campo NIÑO no están ya en el campo de PADRES. Si tiene datos que están en el campo NIÑO que aún no ha ingresado en el campo PADRES, eso causará este error. Es una pena que el mensaje de error no sea un poco más útil.

Si no está seguro, haga una copia de seguridad de la tabla que tiene la clave externa, elimine todos los datos y luego intente crear la clave externa. Si tiene éxito, entonces, ¿qué hacer?

Buena suerte.

Esta es una versión sutil de lo que ya se ha dicho, pero en mi caso, tenía 2 bases de datos (foo y bar). Primero creé foo y no me di cuenta de que hacía referencia a una clave foránea en bar.baz (que aún no se había creado). Cuando intenté crear bar.baz (sin ninguna clave externa), seguía recibiendo este error. Después de mirar alrededor por un rato, encontré la clave foránea en foo.

Entonces, para resumir, si obtiene este error, es posible que tenga una clave externa preexistente para la tabla que se está creando.

Para mí, el error 1215 ocurrió cuando estaba importando un archivo de volcado creado por mysqldump, que crea las tablas alfabéticamente, lo que en mi caso causó que las claves foráneas hicieran referencia a tablas creadas más adelante en el archivo. (Consejos para esta página para señalarlo: https://www.percona.com/blog/2017/04/06/dealing-mysql-error-code-1215-cannot-add-foreign-key-constraint/ )

Como mysqldump ordena las tablas alfabéticamente y no quería cambiar los nombres de las tablas, seguí las instrucciones en la respuesta de JeremyWeir en esta página , que indica colocar set FOREIGN_KEY_CHECKS = 0;en la parte superior del archivo de volcado y colocar SET FOREIGN_KEY_CHECKS = 1;en la parte inferior del archivo de volcado .

Esa solución funcionó para mí.

Así que probé todas las soluciones anteriores y no tuve suerte. Es posible que me falte el error en mis tablas: simplemente no pude encontrar la causa y seguí recibiendo el error 1215. Así que utilicé esta solución.

En mi entorno local en phpMyAdmin, exporté datos de la tabla en cuestión. Seleccioné el formato CSV. Mientras todavía estaba en phpMyAdmin con la tabla seleccionada, seleccioné "Más-> Opciones". Aquí me desplacé hasta "Copiar tabla a (database.table). Seleccione" Estructura solamente ". Cambie el nombre de la tabla a algo, tal vez solo agregue la palabra" copiar "al lado del nombre de la tabla actual. Haga clic en" Ir ". Esto creará un nuevo tabla. Exporte la nueva tabla e impórtela al servidor nuevo u otro. También estoy usando phpMyAdmin aquí también. Una vez importado, cambie el nombre de la tabla a su nombre original. Seleccione la nueva tabla, seleccione importar. Para el formato seleccione CSV Desmarque "habilitar verificaciones de clave externa". Seleccione "Ir". Hasta ahora todo funciona bien.

Publiqué mi solución en mi blog .

Incluso yo tuve el mismo problema. Y la falla fue con el marcador "sin firmar" en la tabla PK de FK

Tuve el mismo error una vez. Simplemente reinicié el servidor MySQL y solucioné el problema.