Lorsque j'ai exécuté la commande suivante:

ALTER TABLE `mytable` ADD UNIQUE (
`column1` ,
`column2`
);

J'ai reçu ce message d'erreur:

#1071 - Specified key was too long; max key length is 767 bytes

Informations sur la colonne1 et la colonne2:

column1 varchar(20) utf8_general_ci
column2  varchar(500) utf8_general_ci

Je pense varchar(20)que ne nécessite que 21 octets alors que varchar(500)ne nécessite que 501 octets. Ainsi, le nombre total d'octets est de 522, moins de 767. Alors pourquoi ai-je reçu le message d'erreur?

#1071 - Specified key was too long; max key length is 767 bytes

767 octets est la limitation de préfixe indiquée pour les tables InnoDB dans MySQL version 5.6 (et les versions antérieures). C'est 1000 octets de long pour les tables MyISAM. Dans MySQL version 5.7 et supérieure, cette limite a été augmentée à 3072 octets.

Vous devez également savoir que si vous définissez un index sur un grand champ char ou varchar codé en utf8mb4, vous devez diviser la longueur maximale du préfixe d'index de 767 octets (ou 3072 octets) par 4, ce qui donne 191. En effet, la longueur maximale d'un caractère utf8mb4 est de quatre octets. Pour un caractère utf8, ce serait trois octets résultant en une longueur maximale de préfixe d'index de 254.

Une option que vous avez consiste simplement à placer une limite inférieure sur vos champs VARCHAR.

Une autre option (selon la réponse à ce problème ) est d'obtenir le sous-ensemble de la colonne plutôt que le montant total, c'est-à-dire:

ALTER TABLE `mytable` ADD UNIQUE ( column1(15), column2(200) );

Ajustez au besoin pour obtenir la clé à appliquer, mais je me demande si cela vaut la peine de revoir votre modèle de données concernant cette entité pour voir s'il y a des améliorations qui vous permettraient de mettre en œuvre les règles métier prévues sans atteindre la limitation MySQL.

Si quelqu'un rencontre des problèmes avec INNODB / Utf-8 pour essayer de mettre un UNIQUEindex sur un VARCHAR(256)champ, basculez-le sur VARCHAR(255). Il semble que 255 soit la limitation.

Lorsque vous atteignez la limite. Réglez les éléments suivants.

• INNODB utf8 VARCHAR(255)
• INNODB utf8mb4 VARCHAR(191)

MySQL suppose le pire des cas pour le nombre d'octets par caractère dans la chaîne. Pour l'encodage MySQL 'utf8', c'est 3 octets par caractère car cet encodage ne permet pas les caractères au-delà U+FFFF. Pour l'encodage 'utf8mb4' de MySQL, c'est 4 octets par caractère, car c'est ce que MySQL appelle le vrai UTF-8.

Donc, en supposant que vous utilisez 'utf8', votre première colonne prendra 60 octets de l'index et votre seconde 1500 autres.

exécutez cette requête avant votre requête:

SET @@global.innodb_large_prefix = 1;

cela augmentera la limite à 3072 bytes.

Solution pour Laravel Framework

Selon la documentation Laravel 5.4. * ; Vous devez définir la longueur de chaîne par défaut dans la bootméthode du app/Providers/AppServiceProvider.phpfichier comme suit:

use Illuminate\Support\Facades\Schema;

public function boot() 
{
    Schema::defaultStringLength(191); 
}

Explication de ce correctif, fournie par la documentation Laravel 5.4. * :

Laravel utilise le utf8mb4jeu de caractères par défaut, qui inclut la prise en charge du stockage des "emojis" dans la base de données. Si vous exécutez une version de MySQL antérieure à la version 5.7.7 ou MariaDB antérieure à la version 10.2.2, vous devrez peut-être configurer manuellement la longueur de chaîne par défaut générée par les migrations afin que MySQL crée des index pour eux. Vous pouvez configurer cela en appelant la Schema::defaultStringLengthméthode dans votreAppServiceProvider .

Alternativement, vous pouvez activer l' innodb_large_prefixoption pour votre base de données. Reportez-vous à la documentation de votre base de données pour savoir comment activer correctement cette option.

Quel encodage de caractères utilisez-vous? Certains jeux de caractères (comme UTF-16, et cetera) utilisent plus d'un octet par caractère.

Je pense que varchar (20) ne nécessite que 21 octets tandis que varchar (500) ne nécessite que 501 octets. Ainsi, le nombre total d'octets est de 522, moins de 767. Alors pourquoi ai-je reçu le message d'erreur?

UTF8 nécessite 3 octets par caractère pour stocker la chaîne, donc dans votre cas 20 + 500 caractères = 20 * 3 + 500 * 3 = 1560 octets, ce qui est plus que autorisé 767 octets.

La limite pour UTF8 est de 767/3 = 255 caractères , pour UTF8mb4 qui utilise 4 octets par caractère, elle est de 767/4 = 191 caractères.

Il existe deux solutions à ce problème si vous devez utiliser une colonne plus longue que la limite:

1. Utilisez un encodage "moins cher" (celui qui nécessite moins d'octets par caractère)
   Dans mon cas, je devais ajouter un index unique sur la colonne contenant la chaîne d'article SEO, car j'utilise uniquement des [A-z0-9\-]caractères pour le référencement, j'ai utilisélatin1_general_ci qui n'utilise qu'un octet par caractère et ainsi la colonne peut avoir une longueur de 767 octets.
2. Créez un hachage à partir de votre colonne et utilisez un index unique uniquement sur celui-ci.
   L'autre option pour moi était de créer une autre colonne qui stockerait le hachage du référencement, cette colonne aurait la UNIQUEclé pour garantir que les valeurs du référencement sont uniques. J'ajouterais également un KEYindex à la colonne SEO d'origine pour accélérer la recherche.

De nombreux utilisateurs ont déjà répondu à la raison pour laquelle vous obtenez un message d'erreur. Ma réponse est de savoir comment le réparer et l'utiliser tel quel.

Référez-vous à partir de ce lien .

1. Ouvrez le client MySQL (ou client MariaDB). Il s'agit d'un outil en ligne de commande.
2. Il vous demandera votre mot de passe, entrez votre mot de passe correct.
3. Sélectionnez votre base de données à l'aide de cette commande use my_database_name;

Base de données modifiée

4. set global innodb_large_prefix=on;

Requête OK, 0 lignes affectées (0,00 sec)

5. set global innodb_file_format=Barracuda;

Requête OK, 0 lignes affectées (0,02 sec)

6. Accédez à votre base de données sur phpMyAdmin ou quelque chose comme ça pour une gestion facile. > Sélectionner la base de données> Afficher la structure de la table > Aller à l' onglet Opérations . > Changez ROW_FORMAT en DYNAMIC et enregistrez les modifications.
7. Accédez à l' onglet de structure du tableau > Cliquez sur Unique bouton .
8. Terminé. Maintenant, il ne devrait pas avoir d'erreurs.

Le problème de ce correctif est que si vous exportez db vers un autre serveur (par exemple de l'hôte local vers l'hôte réel) et que vous ne pouvez pas utiliser la ligne de commande MySQL sur ce serveur. Vous ne pouvez pas le faire fonctionner là-bas.

Specified key was too long; max key length is 767 bytes

Vous avez reçu ce message car 1 octet équivaut à 1 caractère uniquement si vous utilisez le latin-1jeu de caractères. Si vous utilisez utf8, chaque caractère sera considéré comme 3 octets lors de la définition de votre colonne clé. Si vous utilisez utf8mb4, chaque caractère sera considéré comme 4 octets lors de la définition de votre colonne clé. Ainsi, vous devez multiplier la limite de caractères de votre champ clé par 1, 3 ou 4 (dans mon exemple) pour déterminer le nombre d'octets que le champ clé essaie d'autoriser. Si vous utilisez uft8mb4, vous ne pouvez définir que 191 caractères pour un champ de clé primaire native, InnoDB. Il suffit de ne pas violer 767 octets.

Remplacez utf8mb4par utf8dans votre fichier d'importation.

vous pouvez ajouter une colonne du md5 de longues colonnes

Nous avons rencontré ce problème lors de la tentative d'ajout d'un index UNIQUE à un champ VARCHAR (255) à l'aide de utf8mb4. Bien que le problème soit déjà bien décrit ici, je voulais ajouter quelques conseils pratiques sur la façon dont nous avons compris cela et l'avons résolu.

Lors de l'utilisation de utf8mb4, les caractères comptent pour 4 octets, alors que sous utf8, ils peuvent l'être pour 3 octets. Les bases de données InnoDB ont une limite selon laquelle les index ne peuvent contenir que 767 octets. Ainsi, lorsque vous utilisez utf8, vous pouvez stocker 255 caractères (767/3 = 255), mais en utilisant utf8mb4, vous ne pouvez stocker que 191 caractères (767/4 = 191).

Vous pouvez absolument ajouter des index réguliers pour les VARCHAR(255)champs en utilisant utf8mb4, mais ce qui se passe, c'est que la taille de l'index est tronquée automatiquement à 191 caractères - comme unique_keyici:

C'est très bien, car les index réguliers sont juste utilisés pour aider MySQL à rechercher plus rapidement dans vos données. Le champ entier n'a pas besoin d'être indexé.

Alors, pourquoi MySQL tronque-t-il automatiquement l'index pour les index réguliers, mais renvoie-t-il une erreur explicite lorsque vous essayez de le faire pour les index uniques? Eh bien, pour que MySQL puisse déterminer si la valeur insérée ou mise à jour existe déjà, il doit réellement indexer la valeur entière et pas seulement une partie.

À la fin de la journée, si vous souhaitez avoir un index unique sur un champ, tout le contenu du champ doit tenir dans l'index. Pour utf8mb4, cela signifie réduire la longueur des champs VARCHAR à 191 caractères ou moins. Si vous n'avez pas besoin d'utf8mb4 pour cette table ou ce champ, vous pouvez le redéposer vers utf8 et conserver vos 255 champs de longueur.

Voici ma réponse originale:

Je laisse simplement tomber la base de données et recrée comme ceci, et l'erreur a disparu:

drop database if exists rhodes; create database rhodes default CHARACTER set utf8 default COLLATE utf8_general_ci;

Cependant, cela ne fonctionne pas pour tous les cas.

Il s'agit en fait d'un problème d'utilisation d'index sur les colonnes VARCHAR avec le jeu de caractères utf8(ou utf8mb4), avec les colonnes VARCHAR qui ont plus d'une certaine longueur de caractères. Dans le cas deutf8mb4 , cette certaine longueur est de 191.

Veuillez consulter la section Index long de cet article pour plus d'informations sur l'utilisation des index longs dans la base de données MySQL: http://hanoian.com/content/index.php/24-automate-the-converting-a-mysql-database- jeu de caractères-à-utf8mb4

5 solutions:

La limite a été relevée en 5.7.7 (MariaDB 10.2.2?). Et il peut être augmenté avec un peu de travail en 5.6 (10.1).

Si vous atteignez la limite parce que vous essayez d'utiliser CHARACTER SET utf8mb4. Effectuez ensuite l'une des opérations suivantes (chacune présente un inconvénient) pour éviter l'erreur:

⚈  Upgrade to 5.7.7 for 3072 byte limit -- your cloud may not provide this;
⚈  Change 255 to 191 on the VARCHAR -- you lose any values longer than 191 characters (unlikely?);
⚈  ALTER .. CONVERT TO utf8 -- you lose Emoji and some of Chinese;
⚈  Use a "prefix" index -- you lose some of the performance benefits.
⚈  Or... Stay with older version but perform 4 steps to raise the limit to 3072 bytes:

SET GLOBAL innodb_file_format=Barracuda;
SET GLOBAL innodb_file_per_table=1;
SET GLOBAL innodb_large_prefix=1;
logout & login (to get the global values);
ALTER TABLE tbl ROW_FORMAT=DYNAMIC;  -- (or COMPRESSED)

- http://mysql.rjweb.org/doc.php/limits#767_limit_in_innodb_indexes

J'ai résolu ce problème avec:

varchar(200) 

remplacé par

varchar(191)

tous les varchar qui en ont plus de 200 les remplacent par 191 ou leur mettent du texte.

J'ai fait quelques recherches sur ce sujet, j'ai finalement obtenu des modifications personnalisées

Pour MySQL Workbench 6.3.7 Version L'inter phase graphique est disponible

1. Démarrez Workbench et sélectionnez la connexion.
2. Accédez à la gestion ou à l'instance et sélectionnez Fichier d'options.
3. Si Workbench vous demande l'autorisation de lire le fichier de configuration, puis l'autorisez en appuyant deux fois sur OK.
4. Au centre, la fenêtre du fichier d'options administrateur s'affiche.
5. Allez sur l'onglet InnoDB et vérifiez le innodb_large_prefix s'il n'est pas coché dans la section Général.
6. définissez la valeur de l'option innodb_default_row_format sur DYNAMIC.

Pour les versions inférieures à 6.3.7, les options directes ne sont pas disponibles, il faut donc aller avec l'invite de commande

1. Démarrez CMD en tant qu'administrateur.
2. Aller au directeur où le serveur mysql est installé La plupart des cas, c'est dans "C: \ Program Files \ MySQL \ MySQL Server 5.7 \ bin", donc la commande est "cd \" "cd Program Files \ MySQL \ MySQL Server 5.7 \ bin".
3. Maintenant, exécutez la commande mysql -u nom_utilisateur -p databasecheema Maintenant, il a demandé le mot de passe de l'utilisateur respectif. Fournissez le mot de passe et entrez dans l'invite mysql.
4. Nous devons définir certains paramètres globaux entrer les commandes ci-dessous un par un ensemble global innodb_large_prefix = on; set global innodb_file_format = barracuda; set global innodb_file_per_table = true;
5. Maintenant, nous devons enfin modifier le ROW_FORMAT de la table requise par défaut son COMPACT, nous devons le définir sur DYNAMIC.
6. utilisez la commande suivante alter table nom_table ROW_FORMAT = DYNAMIC;
7. Terminé

Pour laravel 5.7 à 6.0

Étapes à suivre

1. Allez à App\Providers\AppServiceProvider.php.
2. Ajoutez ceci au fournisseur use Illuminate\Support\Facades\Schema;en haut.
3. A l'intérieur de la fonction de démarrage Ajouter ceci Schema::defaultStringLength(191);

que tout, profitez-en.

changez votre classement. Vous pouvez utiliser utf8_general_ci qui prend en charge presque tous

Le simple fait de passer utf8mb4à la utf8création de tableaux a résolu mon problème. Par exemple: CREATE TABLE ... DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;à CREATE TABLE ... DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;.

Pour résoudre ce problème, cela fonctionne pour moi comme un charme.

ALTER DATABASE dbname CHARACTER SET utf8 COLLATE utf8_general_ci;

Sur la base de la colonne ci-dessous, ces 2 colonnes de chaînes variables utilisent le utf8_general_ciclassement (le utf8jeu de caractères est implicite).

Dans MySQL, utf8charset utilise un maximum de 3 octets pour chaque caractère. Ainsi, il devrait allouer 500 * 3 = 1500 octets, ce qui est beaucoup plus important que les 767 octets autorisés par MySQL. C'est pourquoi vous obtenez cette erreur 1071.

En d'autres termes, vous devez calculer le nombre de caractères en fonction de la représentation des octets du jeu de caractères car tous les jeux de caractères ne sont pas une représentation à un seul octet (comme vous le supposiez.) IE utf8dans MySQL utilise au plus 3 octets par caractère, 767 / 3≈255 caractères et, pour utf8mb4une représentation d'au plus 4 octets, 767 / 4≈191 caractères.

Il est également connu que MySQL

column1 varchar(20) utf8_general_ci
column2  varchar(500) utf8_general_ci

J'ai trouvé cette requête utile pour détecter les colonnes dont l'index violait la longueur maximale:

SELECT
  c.TABLE_NAME As TableName,
  c.COLUMN_NAME AS ColumnName,
  c.DATA_TYPE AS DataType,
  c.CHARACTER_MAXIMUM_LENGTH AS ColumnLength,
  s.INDEX_NAME AS IndexName
FROM information_schema.COLUMNS AS c
INNER JOIN information_schema.statistics AS s
  ON s.table_name = c.TABLE_NAME
 AND s.COLUMN_NAME = c.COLUMN_NAME 
WHERE c.TABLE_SCHEMA = DATABASE()
  AND c.CHARACTER_MAXIMUM_LENGTH > 191 
  AND c.DATA_TYPE IN ('char', 'varchar', 'text')

Veuillez vérifier si sql_modec'est comme

sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

si c'est le cas, passez à

sql_mode=NO_ENGINE_SUBSTITUTION

OU

redémarrez votre serveur en changeant votre fichier my.cnf (en mettant ce qui suit)

innodb_large_prefix=on

Dans mon cas, j'ai eu ce problème lorsque je sauvegardais une base de données en utilisant les caractères de sortie / entrée de redirection linux. Par conséquent, je change la syntaxe comme décrit ci-dessous. PS: en utilisant un terminal linux ou mac.

Sauvegarde (sans la> redirection)

# mysqldump -u root -p databasename -r bkp.sql

Restaurer (sans la <redirection)

# mysql -u root -p --default-character-set=utf8 databasename
mysql> SET names 'utf8'
mysql> SOURCE bkp.sql

L'erreur "La clé spécifiée était trop longue; la longueur maximale de la clé est de 767 octets" a simplement disparu.

Longueurs d'index et MySQL / MariaDB

Laravel utilise le jeu de caractères utf8mb4 par défaut, qui inclut la prise en charge du stockage des "emojis" dans la base de données. Si vous exécutez une version de MySQL antérieure à la version 5.7.7 ou MariaDB antérieure à la version 10.2.2, vous devrez peut-être configurer manuellement la longueur de chaîne par défaut générée par les migrations afin que MySQL crée des index pour eux. Vous pouvez configurer cela en appelant la méthode Schema :: defaultStringLength dans votre AppServiceProvider:

use Illuminate\Support\Facades\Schema;

/**
 * Bootstrap any application services.
 *
 * @return void
 */
public function boot()
{
    Schema::defaultStringLength(191);
}

Vous pouvez également activer l'option innodb_large_prefix pour votre base de données. Reportez-vous à la documentation de votre base de données pour savoir comment activer correctement cette option.

Référence du blog: https://www.scratchcode.io/specified-key-too-long-error-in-laravel/

Référence de la documentation officielle de laravel: https://laravel.com/docs/5.7/migrations

Si vous créez quelque chose comme:

CREATE TABLE IF NOT EXISTS your_table (
  id int(7) UNSIGNED NOT NULL AUTO_INCREMENT,
  name varchar(256) COLLATE utf8mb4_bin NOT NULL,
  PRIMARY KEY (id),
  UNIQUE KEY name (name)
) ENGINE=INNODB DEFAULT CHARSET=utf8mb4 AUTO_INCREMENT=1 ROW_FORMAT=FIXED;

ça devrait être quelque chose comme

CREATE TABLE IF NOT EXISTS your_table (
      id int(7) UNSIGNED NOT NULL AUTO_INCREMENT,
      name varchar(256) COLLATE utf8mb4_bin NOT NULL,
      PRIMARY KEY (id)
    ) ENGINE=INNODB DEFAULT CHARSET=utf8mb4 AUTO_INCREMENT=1 ROW_FORMAT=FIXED;

mais vous devez vérifier l'unicité de cette colonne à partir du code ou ajouter une nouvelle colonne en tant que MD5 ou SHA1 de la colonne varchar

En raison des limitations de préfixe, cette erreur se produira. 767 octets est la limitation de préfixe indiquée pour les tables InnoDB dans les versions MySQL antérieures à 5.7. C'est 1000 octets de long pour les tables MyISAM. Dans MySQL version 5.7 et supérieure, cette limite a été augmentée à 3072 octets.

L'exécution de ce qui suit sur le service vous donnant l'erreur devrait résoudre votre problème. Cela doit être exécuté dans la CLI MYSQL.

SET GLOBAL innodb_file_format=Barracuda;
SET GLOBAL innodb_file_per_table=on;
SET GLOBAL innodb_large_prefix=on;

Remplacez CHARSET du champ d'indexation par "latin1",
c'est-à-dire ALTER TABLE tbl CHANGE myfield myfield varchar (600) CHARACTER SET latin1 DEFAULT NULL;
latin1 prend un octet pour un caractère au lieu de quatre

Si vous avez changé innodb_log_file_sizerécemment, essayez de restaurer la valeur précédente qui fonctionnait.