MySQL errno 150 : pourquoi la clé étrangère est refusée

Un import SQL ou une migration s'arrête sur une clé étrangère : "errno: 150", "Cannot add foreign key constraint" ou "are incompatible" selon la version. Ce n'est pas une question de clé primaire, et ALTER TABLE peut ajouter une clé étrangère. La clé ne correspond pas à la colonne référencée : type ou signe différent, collation différente, colonne sans index, table absente ou pas en InnoDB. Nous avons reproduit chaque cas sur MySQL 5.7, MySQL 8.0 et MariaDB 11.4.

Quel message selon votre serveur ?

Sous MariaDB, le message complet est Can't create table ... (errno: 150 "Foreign key constraint is incorrectly formed"). Sous MySQL 5.7, "errno: 150" apparaît dans un autre cas, vu plus bas. La documentation de MySQL résume les règles : les colonnes doivent avoir des types semblables, "The size and sign of fixed precision types such as INTEGER and DECIMAL must be the same", la longueur des chaînes peut différer, mais "the character set and collation must be the same".

Comment trouver la cause exacte ?

MySQL 8.0 nomme les colonnes en cause dans le message. Sous MySQL 5.7, le détail se trouve dans la section LATEST FOREIGN KEY ERROR :

SHOW ENGINE INNODB STATUS\G

Table absente : Cannot resolve table name close to. Type, collation ou index : un seul et même texte, Cannot find an index in the referenced table where the referenced columns appear as the first columns, or column types in the table and the referenced table do not match. Comparez alors les deux colonnes avec SHOW CREATE TABLE sur chaque table.

Les deux colonnes ont-elles vraiment le même type ?

Avec Laravel, le cas typique : $table->id() crée un BIGINT UNSIGNED, et une colonne INT ou BIGINT signée ne peut pas le référencer. Cette table est acceptée :

CREATE TABLE users (id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY) ENGINE=InnoDB;
CREATE TABLE posts (id INT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT UNSIGNED, FOREIGN KEY (user_id) REFERENCES users(id)) ENGINE=InnoDB;

Avec user_id INT ou user_id BIGINT, les trois serveurs la refusent. Pour du texte, un VARCHAR(20) qui référence un VARCHAR(10) passe, mais pas une collation utf8mb4_general_ci face à utf8mb4_unicode_ci, ni utf8 face à utf8mb4, ce qui arrive lors d'un import entre deux serveurs aux réglages différents.

Si la colonne existe déjà, corrigez son type puis ajoutez la clé :

ALTER TABLE posts MODIFY user_id BIGINT UNSIGNED;
ALTER TABLE posts ADD CONSTRAINT posts_user_id_foreign FOREIGN KEY (user_id) REFERENCES users(id);

La colonne référencée a-t-elle un index ?

La colonne référencée n'a pas besoin d'être une clé primaire : il lui faut un index dont elle est la première colonne. La documentation : "InnoDB permits a foreign key to reference any index column or group of columns". Une clé vers users.email sans index échoue ; avec INDEX (email) dans la table users, elle passe.

La table référencée existe-t-elle, et en InnoDB ?

Une clé vers une table pas encore créée ou en MyISAM échoue. Plus sournois : si la table qui référence est en MyISAM, CREATE TABLE réussit, mais aucune clé n'est créée (0 contrainte dans information_schema.REFERENTIAL_CONSTRAINTS).

Un fichier d'import peut désactiver les contrôles avec SET foreign_key_checks=0 : posts a alors pu être créée avant users, avec sa clé. Ce n'est pas un passe-droit pour autant :

• si users est ensuite créée avec un id INT, MySQL 5.7 et 8.0 refusent la table, alors que MariaDB l'accepte sans rien dire ;
• sous MySQL 5.7, modifier le type d'une colonne liée renvoie ERROR 1025 (HY000): Error on rename of ... (errno: 150 - Foreign key constraint is incorrectly formed) ;
• changer la collation de la table référencée (CONVERT TO CHARACTER SET) passe sur MySQL 5.7 et 8.0, et laisse une clé entre deux collations différentes.

Et dans une migration Laravel ?

Laravel crée la table, puis ajoute la clé par un ALTER TABLE : l'erreur cite la requête en cause, un alter table qui ajoute la contrainte articles_author_id_foreign. Deux causes reviennent :

• L'ordre des migrations. Elles s'exécutent dans l'ordre de l'horodatage du nom de fichier : une migration articles datée avant authors échoue (1215 sous MySQL 5.7).
• Un type ancien. Une table créée avec $table->increments('id') (INT UNSIGNED) ne peut pas être référencée par foreignId() (BIGINT UNSIGNED).

La forme courte de la documentation crée la bonne colonne et la bonne clé :

// database/migrations/2026_10_19_110000_create_articles_table.php
Schema::create('articles', function (Blueprint $table) {
    $table->id();
    $table->foreignId('author_id')->constrained();
});

Résultat : author_id bigint(20) unsigned NOT NULL et la contrainte articles_author_id_foreign. Si la table référencée date d'avant et utilise increments, déclarez une colonne du même type (INT UNSIGNED) plutôt que foreignId().

Ces erreurs surgissent lors d'une reprise de données, étape que nous gérons dans nos applications sur mesure comme quand nous connectons des logiciels. Une base à reprendre ? Parlons-en.

Testé avec MySQL 5.7.33, MySQL 8.0.46, MariaDB 11.4.13, Laravel 13.37.0 et PHP 8.3.6.

Questions fréquentes