Als ich den folgenden Befehl ausgeführt habe:

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

Ich habe diese Fehlermeldung erhalten:

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

Informationen zu Spalte1 und Spalte2:

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

Ich denke varchar(20), benötigt nur 21 Bytes, während varchar(500)nur 501 Bytes benötigt. Die Gesamtzahl der Bytes beträgt also 522, weniger als 767. Warum habe ich die Fehlermeldung erhalten?

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

767 Byte ist die angegebene Präfixbeschränkung für InnoDB-Tabellen in MySQL Version 5.6 (und früheren Versionen). Es ist 1.000 Byte lang für MyISAM-Tabellen. In MySQL Version 5.7 und höher wurde diese Grenze auf 3072 Byte erhöht.

Sie müssen sich auch darüber im Klaren sein, dass Sie, wenn Sie einen Index für ein großes char- oder varchar-Feld festlegen, das utf8mb4-codiert ist, die maximale Indexpräfixlänge von 767 Bytes (oder 3072 Bytes) durch 4 teilen müssen, was zu 191 führt. Dies liegt daran Die maximale Länge eines utf8mb4-Zeichens beträgt vier Bytes. Für ein utf8-Zeichen wären es drei Bytes, was zu einer maximalen Indexpräfixlänge von 254 führt.

Eine Möglichkeit besteht darin, Ihre VARCHAR-Felder nur mit einer Untergrenze zu versehen.

Eine andere Option (entsprechend der Antwort auf dieses Problem ) besteht darin, die Teilmenge der Spalte und nicht den gesamten Betrag abzurufen, dh:

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

Optimieren Sie, wenn Sie den Schlüssel zum Anwenden benötigen, aber ich frage mich, ob es sich lohnt, Ihr Datenmodell in Bezug auf diese Entität zu überprüfen, um festzustellen, ob es Verbesserungen gibt, mit denen Sie die beabsichtigten Geschäftsregeln implementieren können, ohne die MySQL-Einschränkung zu treffen.

Wenn jemand Probleme mit INNODB / Utf-8 hat, die versuchen, einen UNIQUEIndex für ein VARCHAR(256)Feld zu erstellen , wechseln Sie zu VARCHAR(255). Es scheint, 255 ist die Einschränkung.

Wenn Sie das Limit erreichen. Stellen Sie Folgendes ein.

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

MySQL geht vom schlechtesten Fall für die Anzahl der Bytes pro Zeichen in der Zeichenfolge aus. Für die MySQL-Codierung 'utf8' sind das 3 Bytes pro Zeichen, da diese Codierung keine darüber hinausgehenden Zeichen zulässt U+FFFF. Für die MySQL-Codierung 'utf8mb4' sind es 4 Bytes pro Zeichen, da MySQL dies als tatsächliches UTF-8 bezeichnet.

Angenommen, Sie verwenden 'utf8', benötigt Ihre erste Spalte 60 Byte des Index und Ihre zweite weitere 1500 Byte.

Führen Sie diese Abfrage vor Ihrer Abfrage aus:

SET @@global.innodb_large_prefix = 1;

Dies erhöht die Grenze auf 3072 bytes.

Lösung für Laravel Framework

Gemäß Laravel 5.4 * Dokumentation. ; Sie müssen die Standardzeichenfolgenlänge in der bootMethode der app/Providers/AppServiceProvider.phpDatei wie folgt festlegen :

use Illuminate\Support\Facades\Schema;

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

Erläuterung dieses Fixes in Laravel 5.4. * Dokumentation :

Laravel verwendet utf8mb4standardmäßig den Zeichensatz, der die Speicherung von "Emojis" in der Datenbank unterstützt. Wenn Sie eine Version von MySQL ausführen, die älter als die Version 5.7.7 oder MariaDB älter als die Version 10.2.2 ist, müssen Sie möglicherweise die durch Migrationen generierte Standardzeichenfolgenlänge manuell konfigurieren, damit MySQL Indizes für sie erstellt. Sie können dies konfigurieren, indem Sie die Schema::defaultStringLengthMethode in Ihrem aufrufen AppServiceProvider.

Alternativ können Sie die innodb_large_prefixOption für Ihre Datenbank aktivieren . Anweisungen zum ordnungsgemäßen Aktivieren dieser Option finden Sie in der Dokumentation Ihrer Datenbank.

Welche Zeichenkodierung verwenden Sie? Einige Zeichensätze (wie UTF-16 usw.) verwenden mehr als ein Byte pro Zeichen.

Ich denke, varchar (20) benötigt nur 21 Bytes, während varchar (500) nur 501 Bytes benötigt. Die Gesamtzahl der Bytes beträgt also 522, weniger als 767. Warum habe ich die Fehlermeldung erhalten?

UTF8 benötigt 3 Byte pro Zeichen der Zeichenfolge zu speichern, so dass in Ihrem Fall 20 + 500 Zeichen = 20 * 3 + 500 * 3 = 1560 Bytes , die sich mehr als erlaubt 767 Bytes.

Das Limit für UTF8 liegt bei 767/3 = 255 Zeichen , für UTF8mb4, das 4 Bytes pro Zeichen verwendet, bei 767/4 = 191 Zeichen.

Es gibt zwei Lösungen für dieses Problem, wenn Sie eine längere Spalte als das Limit verwenden müssen:

1. Verwenden Sie eine "billigere" Codierung (die weniger Bytes pro Zeichen erfordert).
   In meinem Fall musste ich einen eindeutigen Index für eine Spalte hinzufügen, die eine SEO-Artikelzeichenfolge enthält, da ich nur [A-z0-9\-]Zeichen für SEO verwende, latin1_general_cidie nur ein Byte pro Zeichen verwendet Die Spalte kann also eine Länge von 767 Bytes haben.
2. Erstellen Sie einen Hash aus Ihrer Spalte und verwenden Sie nur einen eindeutigen Index.
   Die andere Option für mich bestand darin, eine weitere Spalte zu erstellen, in der SEO-Hash gespeichert wird. Diese Spalte enthält den UNIQUESchlüssel, um sicherzustellen, dass die SEO-Werte eindeutig sind. Ich würde auch einen KEYIndex zur ursprünglichen SEO-Spalte hinzufügen , um das Nachschlagen zu beschleunigen.

Die Antwort, warum Sie eine Fehlermeldung erhalten, wurde bereits von vielen Benutzern hier beantwortet. In meiner Antwort geht es darum, wie man es repariert und so verwendet, wie es ist.

Siehe von diesem Link .

1. Öffnen Sie den MySQL-Client (oder den MariaDB-Client). Es ist ein Befehlszeilenprogramm.
2. Sie werden nach Ihrem Passwort gefragt und geben Ihr korrektes Passwort ein.
3. Wählen Sie Ihre Datenbank mit diesem Befehl aus use my_database_name;

Datenbank geändert

4. set global innodb_large_prefix=on;

Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

5. set global innodb_file_format=Barracuda;

Abfrage OK, 0 Zeilen betroffen (0,02 Sek.)

6. Gehen Sie für eine einfache Verwaltung zu Ihrer Datenbank auf phpMyAdmin oder ähnlichem. > Datenbank auswählen> Tabellenstruktur anzeigen > Zur Registerkarte Vorgänge wechseln. > Ändern Sie ROW_FORMAT in DYNAMIC und speichern Sie die Änderungen.
7. Gehen Sie zur Registerkarte Struktur der Tabelle > Klicken Sie auf die Schaltfläche Eindeutig .
8. Erledigt. Jetzt sollte es keine Fehler geben.

Das Problem dieses Fixes besteht darin, dass Sie db auf einen anderen Server exportieren (z. B. von localhost auf einen echten Host) und die MySQL-Befehlszeile auf diesem Server nicht verwenden können. Sie können es dort nicht zum Laufen bringen.

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

Sie haben diese Nachricht erhalten, weil 1 Byte nur dann 1 Zeichen entspricht, wenn Sie den latin-1Zeichensatz verwenden. Wenn Sie verwenden utf8, wird jedes Zeichen bei der Definition Ihrer Schlüsselspalte als 3 Byte betrachtet. Wenn Sie verwenden utf8mb4, wird jedes Zeichen bei der Definition Ihrer Schlüsselspalte als 4 Byte betrachtet. Daher müssen Sie die Zeichenbeschränkung Ihres Schlüsselfelds mit 1, 3 oder 4 (in meinem Beispiel) multiplizieren, um die Anzahl der Bytes zu bestimmen, die das Schlüsselfeld zulassen möchte. Wenn Sie uft8mb4 verwenden, können Sie nur 191 Zeichen für ein natives InnoDB-Primärschlüsselfeld definieren. Nur nicht 767 Bytes verletzen.

Sie können eine Spalte des MD5 von langen Spalten hinzufügen

Ersetzen Sie utf8mb4mit utf8in der Importdatei.

Dieses Problem trat auf, als versucht wurde, einem VARCHAR (255) -Feld mit utf8mb4 einen EINZIGARTIGEN Index hinzuzufügen. Während das Problem hier bereits gut umrissen ist, wollte ich einige praktische Ratschläge hinzufügen, wie wir dies herausgefunden und gelöst haben.

Bei Verwendung von utf8mb4 zählen Zeichen als 4 Bytes, während sie unter utf8 als 3 Bytes gelten können. InnoDB-Datenbanken haben ein Limit, dass Indizes nur 767 Bytes enthalten dürfen. Wenn Sie utf8 verwenden, können Sie 255 Zeichen (767/3 = 255) speichern. Mit utf8mb4 können Sie jedoch nur 191 Zeichen (767/4 = 191) speichern.

VARCHAR(255)Mit utf8mb4 können Sie durchaus reguläre Indizes für Felder hinzufügen. Die Indexgröße wird jedoch automatisch auf 191 Zeichen gekürzt - wie unique_keyhier:

Dies ist in Ordnung, da reguläre Indizes nur verwendet werden, um MySQL dabei zu unterstützen, Ihre Daten schneller zu durchsuchen. Das gesamte Feld muss nicht indiziert werden.

Warum schneidet MySQL den Index für reguläre Indizes automatisch ab, gibt jedoch einen expliziten Fehler aus, wenn Sie versuchen, dies für eindeutige Indizes zu tun? Damit MySQL herausfinden kann, ob der eingefügte oder aktualisierte Wert bereits vorhanden ist, muss der gesamte Wert indiziert werden und nicht nur ein Teil davon.

Wenn Sie am Ende des Tages einen eindeutigen Index für ein Feld haben möchten, muss der gesamte Inhalt des Felds in den Index passen. Für utf8mb4 bedeutet dies, dass Sie Ihre VARCHAR-Feldlängen auf 191 Zeichen oder weniger reduzieren. Wenn Sie für diese Tabelle oder dieses Feld nicht utf8mb4 benötigen, können Sie es auf utf8 zurücksetzen und Ihre Felder mit einer Länge von 255 behalten.

Hier ist meine ursprüngliche Antwort:

Ich lösche einfach die Datenbank und erstelle sie neu, und der Fehler ist verschwunden:

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

Es funktioniert jedoch nicht in allen Fällen.

Es ist tatsächlich ein Problem, Indizes für VARCHAR-Spalten mit dem Zeichensatz utf8(oder utf8mb4) zu verwenden, wobei VARCHAR-Spalten mehr als eine bestimmte Länge von Zeichen haben. Im Fall von utf8mb4beträgt diese bestimmte Länge 191.

Weitere Informationen zur Verwendung langer Indizes in der MySQL-Datenbank finden Sie im Abschnitt "Langer Index" in diesem Artikel: http://hanoian.com/content/index.php/24-automate-the-converting-a-mysql-database- Zeichensatz-zu-utf8mb4

5 Problemumgehungen:

Das Limit wurde in 5.7.7 (MariaDB 10.2.2?) Erhöht. Und es kann mit etwas Arbeit in 5.6 (10.1) erhöht werden.

Wenn Sie das Limit erreichen, weil Sie versuchen, CHARACTER SET utf8mb4 zu verwenden. Führen Sie dann einen der folgenden Schritte aus (jeder hat einen Nachteil), um den Fehler zu vermeiden:

⚈  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

Ich habe dieses Problem behoben mit:

varchar(200) 

Ersetzt mit

varchar(191)

Alle Varchar, die mehr als 200 haben, ersetzen sie durch 191 oder setzen sie als Text.

Ich habe nach diesem Thema gesucht und endlich eine benutzerdefinierte Änderung erhalten

Für die MySQL Workbench 6.3.7 Version ist eine grafische Zwischenphase verfügbar

1. Starten Sie Workbench und wählen Sie die Verbindung aus.
2. Gehen Sie zu Verwaltung oder Instanz und wählen Sie Optionsdatei.
3. Wenn Workbench Sie um Erlaubnis zum Lesen der Konfigurationsdatei bittet und diese dann durch zweimaliges Drücken von OK zulässt.
4. In der Mitte kommt das Fenster mit den Administratoroptionen.
5. Gehen Sie zur Registerkarte InnoDB und überprüfen Sie das innodb_large_prefix, falls es nicht im Abschnitt Allgemein aktiviert ist.
6. Setzen Sie den Optionswert innodb_default_row_format auf DYNAMIC.

Für Versionen unter 6.3.7 sind keine direkten Optionen verfügbar, daher muss die Eingabeaufforderung verwendet werden

1. Starten Sie CMD als Administrator.
2. Gehen Sie zu Director, wo der MySQL-Server installiert ist. In den meisten Fällen befindet er sich unter "C: \ Programme \ MySQL \ MySQL Server 5.7 \ bin". Der Befehl lautet also "cd \" "CD-Programme \ MySQL \ MySQL Server 5.7 \ bin".
3. Führen Sie jetzt den Befehl mysql -u userName -p databaseasescheema aus. Nun wurde nach dem Kennwort des jeweiligen Benutzers gefragt. Geben Sie ein Passwort ein und geben Sie die MySQL-Eingabeaufforderung ein.
4. Wir müssen einige globale Einstellungen vornehmen. Geben Sie die folgenden Befehle nacheinander ein. Set global innodb_large_prefix = on; set global innodb_file_format = barracuda; set global innodb_file_per_table = true;
5. Als letztes müssen wir das ROW_FORMAT der erforderlichen Tabelle standardmäßig ändern. COMPACT müssen wir auf DYNAMIC setzen.
6. Verwenden Sie den folgenden Befehl alter table table_name ROW_FORMAT = DYNAMIC;
7. Erledigt

Für Laravel 5.7 bis 6.0

Schritte zu folgen

1. Gehe zu App\Providers\AppServiceProvider.php.
2. Fügen Sie dies dem Anbieter use Illuminate\Support\Facades\Schema;oben hinzu.
3. Innerhalb der Boot-Funktion Fügen Sie dies hinzu Schema::defaultStringLength(191);

das alles, viel Spaß.

Ändern Sie Ihre Sortierung. Sie können utf8_general_ci verwenden , das fast alle unterstützt

Nur beim Erstellen von Tabellen zu wechseln utf8mb4, utf8löste mein Problem. Zum Beispiel: CREATE TABLE ... DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;bis CREATE TABLE ... DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;.

Um das zu beheben, funktioniert das für mich wie ein Zauber.

ALTER DATABASE dbname CHARACTER SET utf8 COLLATE utf8_general_ci;

Basierend auf der unten angegebenen Spalte verwenden diese beiden Spalten mit variablen Zeichenfolgen eine utf8_general_ciSortierung ( utf8Zeichensatz ist impliziert).

In MySQL utf8verwendet charset maximal 3 Bytes für jedes Zeichen. Daher müsste es 500 * 3 = 1500 Bytes zuweisen, was viel größer ist als die 767 Bytes, die MySQL zulässt. Deshalb wird dieser 1071-Fehler angezeigt.

Mit anderen Worten, Sie müssen die Zeichenanzahl basierend auf der Bytedarstellung des Zeichensatzes berechnen, da nicht jeder Zeichensatz eine Einzelbyte-Darstellung ist (wie Sie angenommen haben). IE utf8in MySQL verwendet höchstens 3 Byte pro Zeichen, 767/3≈255 Zeichen und für utf8mb4eine höchstens 4-Byte-Darstellung 767 / 4≈191 Zeichen.

Es ist auch bekannt, dass MySQL

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

Ich fand diese Abfrage hilfreich, um festzustellen, welche Spalten einen Index hatten, der die maximale Länge verletzte:

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')

Bitte überprüfen Sie, ob dies der Fall sql_modeist

sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

Wenn dies der Fall ist, wechseln Sie zu

sql_mode=NO_ENGINE_SUBSTITUTION

ODER

Starten Sie Ihren Server neu und ändern Sie Ihre my.cnf-Datei.

innodb_large_prefix=on

In meinem Fall hatte ich dieses Problem, als ich eine Datenbank mit den Ausgabe- / Eingabezeichen für die Linux-Umleitung sicherte. Daher ändere ich die Syntax wie unten beschrieben. PS: mit einem Linux- oder Mac-Terminal.

Backup (ohne die> Weiterleitung)

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

Wiederherstellen (ohne die <Weiterleitung)

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

Der Fehler "Angegebener Schlüssel war zu lang; maximale Schlüssellänge beträgt 767 Bytes" ist einfach verschwunden.

Indexlängen & MySQL / MariaDB

Laravel verwendet standardmäßig den Zeichensatz utf8mb4 , der die Speicherung von "Emojis" in der Datenbank unterstützt. Wenn Sie eine Version von MySQL ausführen, die älter als die Version 5.7.7 oder MariaDB älter als die Version 10.2.2 ist, müssen Sie möglicherweise die durch Migrationen generierte Standardzeichenfolgenlänge manuell konfigurieren, damit MySQL Indizes für sie erstellt. Sie können dies konfigurieren, indem Sie die Schema :: defaultStringLength- Methode in Ihrem AppServiceProvider aufrufen:

use Illuminate\Support\Facades\Schema;

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

Alternativ können Sie die Option innodb_large_prefix für Ihre Datenbank aktivieren. Anweisungen zum ordnungsgemäßen Aktivieren dieser Option finden Sie in der Dokumentation Ihrer Datenbank.

Referenz aus dem Blog: https://www.scratchcode.io/specified-key-too-long-error-in-laravel/

Referenz aus der offiziellen Laravel-Dokumentation: https://laravel.com/docs/5.7/migrations

Wenn Sie etwas erstellen wie:

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;

es sollte so etwas sein

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;

Sie müssen jedoch die Eindeutigkeit dieser Spalte anhand des Codes überprüfen oder eine neue Spalte als MD5 oder SHA1 der varchar-Spalte hinzufügen

Aufgrund von Präfixbeschränkungen tritt dieser Fehler auf. 767 Byte ist die angegebene Präfixbeschränkung für InnoDB-Tabellen in MySQL-Versionen vor 5.7. Es ist 1.000 Byte lang für MyISAM-Tabellen. In MySQL Version 5.7 und höher wurde diese Grenze auf 3072 Byte erhöht.

Wenn Sie für den Dienst, der Ihnen den Fehler gibt, Folgendes ausführen, sollte das Problem behoben sein. Dies muss in der MYSQL-CLI ausgeführt werden.

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

Ändern Sie CHARSET des beschwerdeführenden Indexfelds in "latin1",
dh ALTER TABLE tbl CHANGE myfield myfield varchar (600) CHARACTER SET latin1 DEFAULT NULL;
latin1 benötigt ein Byte für ein Zeichen anstelle von vier

Wenn Sie innodb_log_file_sizekürzlich Änderungen vorgenommen haben , versuchen Sie, den vorherigen Wert wiederherzustellen, der funktioniert hat.