Jeśli ktoś ma problemy z INNODB / Utf-8 próbując umieścić indeks UNIQUE w polu VARCHAR(256), przełącz go na VARCHAR(255). Wydaje się, że 255 jest ograniczeniem.

Kiedy osiągniesz limit. Ustaw następujące.

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

MySQL przyjmuje najgorszy rozmiar dla liczby bajtów na znak w łańcuchu. Dla kodowania MySQL 'utf8', to 3 bajty na znak, ponieważ kodowanie to nie pozwala na znaki poza U+FFFF. Dla kodowania MySQL 'utf8mb4' jest to 4 bajty na znak, ponieważ MySQL nazywa to rzeczywistym UTF-8.

Więc zakładając, że używasz 'utf8', Pierwsza kolumna zajmie 60 bajtów indeksu, a druga kolejne 1500.

Uruchom to zapytanie przed zapytaniem:

SET @@global.innodb_large_prefix = 1;

To zwiększy limit do 3072 bytes.

Jakiego kodowania znaków używasz? Niektóre zestawy znaków (jak UTF-16, itd.) używają więcej niż jednego bajtu na znak.

Rozwiązanie Dla Laravel Framework

Zgodnie z Laravel 5.4.* documentation ; musisz ustawić domyślną długość łańcucha wewnątrz

Boot

Metoda

App / Providers/AppServiceProvider.php

Plik w następujący sposób:

use Illuminate\Support\Facades\Schema;

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

Wyjaśnienie tej poprawki podane przez Laravel 5.4.* dokumentacja;

Laravel domyślnie używa zestawu znaków utf8mb4, który zawiera obsługa przechowywania "emotikon" w bazie danych. Jeśli używasz wersji MySQL starszej niż wersja 5.7.7 lub MariaDB starszej niż wersja 10.2.2, może być konieczne ręczne skonfigurowanie domyślnej długości ciągu generowanego przez migracje, aby MySQL mógł tworzyć dla nich indeksy. Można to skonfigurować, wywołując metodę Schema:: defaultStringLength wewnątrz AppServiceProvider

Alternatywnie można włączyć opcję innodb_large_prefix dla Twojego baza danych. Zapoznaj się z dokumentacją bazy danych, aby uzyskać instrukcje dotyczące jak prawidłowo włączyć tę opcję.

Myślę, że varchar(20) wymaga tylko 21 bajtów, podczas gdy varchar (500) tylko wymaga 501 bajtów. Więc suma bajtów wynosi 522, mniej niż 767. Więc dlaczego czy dostałem komunikat o błędzie?

UTF8 wymaga 3 bajtów na znak do przechowywania ciągu znaków, więc w Twoim przypadku 20 + 500 znaków = 20*3+500*3 = 1560 bajtów, które jest więcej niż dozwolone 767 bajtów.

Limit dla UTF8 wynosi 767/3 = 255 znaków , dla UTF8mb4, który używa 4 bajtów na znak to 767/4 = 191 znaków.

Istnieją dwa rozwiązania tego problemu, jeśli potrzebujesz użyć dłuższej kolumny niż limit:

1. użyj "tańszego" kodowania (takiego, które wymaga mniej bajtów na znak)
   W moim przypadku musiałem dodać unikalny indeks na kolumnie zawierającej ciąg SEO artykułu, ponieważ używam tylko znaków [A-z0-9\-] do SEO, użyłem latin1_general_ci, który używa tylko jednego bajtu na znak, a więc kolumna może mieć długość 767 bajtów.
2. Utwórz hash z Twojej kolumny i użyj unikalnego indeksu tylko na tym
   Inną opcją dla mnie było stworzenie innej kolumny, która przechowywałaby hash SEO, kolumna ta miałaby klucz UNIQUE, aby zapewnić unikalne wartości SEO. Dodałbym również KEY indeks do oryginalnej kolumny SEO, aby przyspieszyć wyszukiwanie.

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

Otrzymałeś tę wiadomość, ponieważ 1 bajt równa się 1 znak tylko wtedy, gdy używasz zestawu znaków latin-1. Jeśli użyjesz utf8, każdy znak będzie traktowany jako 3 bajty podczas definiowania kolumny kluczowej. Jeśli użyjesz utf8mb4, każdy znak będzie traktowany jako 4 bajty podczas definiowania kolumny kluczowej. Tak więc, musisz pomnożyć limit znaków swojego pola klucza przez, 1, 3 lub 4 (w moim przykładzie), aby określić liczbę bajtów, na które pole klucza próbuje zezwolić. Jeśli używasz uft8mb4, możesz tylko zdefiniuj 191 znaków dla natywnego, InnoDB, podstawowego pola klucza. Tylko nie naruszaj 767 bajtów.

Możesz dodać kolumnę md5 długich kolumn

Odpowiedź o tym, dlaczego otrzymujesz komunikat o błędzie, została już udzielona przez wielu użytkowników tutaj. Moja odpowiedź jest o tym, jak naprawić i używać go tak, jak to jest.

Zobacz z ten link .

1. otwórz klienta MySQL (lub klienta MariaDB). Jest to narzędzie wiersza poleceń.
2. zapyta o hasło, wprowadź poprawne hasło.
3. Wybierz bazę danych za pomocą tego polecenia use my_database_name;

Baza danych zmieniona

1. set global innodb_large_prefix=on;

Zapytanie OK, 0 wierszy dotkniętych (0.00 sec)

1. set global innodb_file_format=Barracuda;

Zapytanie OK, 0 wierszy dotkniętych (0.02 sec)

1. przejdź do bazy danych na phpMyAdmin lub coś podobnego, aby ułatwić zarządzanie. > Wybierz bazę danych > wyświetl tabelę struktura > przejdź do zakładki operacje. > Zmień ROW_FORMAT na DYNAMIC i zapisz zmiany.
2. przejdź do tabeli struktura zakładka > kliknij na Unique guzik.
Zrobione. Teraz nie powinno mieć żadnych błędów.

Problem tej poprawki polega na tym, że wyeksportujesz db do innego serwera (na przykład z localhost do prawdziwego hosta) i nie możesz użyć linii poleceń MySQL na tym serwerze. Nie uda ci się.

Napotkaliśmy ten problem podczas próby dodania unikalnego indeksu do pola VARCHAR (255) przy użyciu utf8mb4. Chociaż problem jest już dobrze zarysowany, chciałem dodać kilka praktycznych porad, jak to rozwiązaliśmy i rozwiązaliśmy.

Podczas używania utf8mb4, znaki liczą się jako 4 bajty, podczas gdy w utf8 mogą być jako 3 bajty. Bazy danych InnoDB mają limit, że indeksy mogą zawierać tylko 767 bajtów. Więc używając utf8, możesz zapisać 255 znaków( 767/3 = 255), ale używając utf8mb4, możesz może przechowywać tylko 191 znaków(767/4 = 191).

Możesz dodawać zwykłe indeksy dla pól VARCHAR(255) używając utf8mb4, ale to, co się dzieje, to rozmiar indeksu jest automatycznie obcinany na 191 znaków - jak unique_key tutaj:

Jest to w porządku, ponieważ zwykłe indeksy są używane do szybszego przeszukiwania danych przez MySQL. Całe pole nie musi być indeksowane.

Więc dlaczego MySQL obcina indeks automatycznie dla zwykłych indeksy, ale rzucać wyraźny błąd, gdy próbuje to zrobić dla unikalnych indeksów? Cóż, aby MySQL mógł dowiedzieć się, czy wstawiana lub aktualizowana wartość już istnieje, musi faktycznie indeksować całą wartość, a nie tylko jej część.

Pod koniec dnia, jeśli chcesz mieć unikalny indeks na polu, Cała zawartość pola musi pasować do indeksu. W przypadku utf8mb4 oznacza to zmniejszenie długości pola VARCHAR do 191 znaków lub mniej. Jeśli nie potrzebujesz utf8mb4 dla ta tabela lub pole, można upuścić go z powrotem do utf8 i być w stanie zachować swoje pola długości 255.

Oto moja oryginalna odpowiedź:

Po prostu upuszczam bazę danych i odtwarzam tak, a błąd zniknie:

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

Jednak to nie działa we wszystkich przypadkach.

W rzeczywistości jest to problem użycia indeksów na kolumnach VARCHAR z zestawem znaków utf8 (lub utf8mb4), z kolumnami VARCHAR, które mają więcej niż określoną długość znaków. W przypadku utf8mb4, pewna długość wynosi 191.

Proszę zapoznać się z sekcją długi indeks w w tym artykule więcej informacji na temat używania długich indeksów w bazie danych MySQL: http://hanoian.com/content/index.php/24-automate-the-converting-a-mysql-database-character-set-to-utf8mb4{[18]

Poszperałem trochę w tym temacie w końcu dostałem jakieś niestandardowe zmiany

Dla MySQL workbench w wersji 6.3.7 dostępna jest graphical inter phase

1. Uruchom Workbench i wybierz połączenie.
2. przejdź do zarządzania lub instancji i wybierz opcje Plik.
3. Jeśli Workbench poprosi Cię o pozwolenie na odczyt pliku konfiguracyjnego, a następnie Zezwól na to, naciskając dwa razy OK.
4. na środku pojawia się okno opcji administratora pliku.
5. Idź Do Zakładka InnoDB i sprawdź innodb_large_prefix, jeśli nie jest zaznaczona w sekcji Ogólne.
6. ustaw wartość opcji innodb_default_row_format na dynamiczną.

Dla wersji poniżej 6.3.7 bezpośrednie opcje nie są dostępne, więc trzeba przejść z wierszem polecenia

1. uruchom CMD jako administrator.
2. przejdź do director gdzie serwer mysql jest instalowany w większości przypadków na "C:\Program Files\MySQL \ MySQL Server 5.7 \ bin" więc polecenie jest "cd \" "cd Program Files\MySQL\MySQL Serwer 5.7 \ bin".
3. Teraz uruchom polecenie mysql-u userName-P databasescheema Teraz poprosił o hasło danego użytkownika. Podaj hasło i wprowadź w monit mysql.
4. musimy ustawić kilka globalnych ustawień wprowadź poniższe polecenia jeden po drugim set global innodb_large_prefix = on; set global innodb_file_format=barracuda; set global innodb_file_per_table = true;
5. Teraz na końcu musimy zmienić WIERSZ_FORMAT wymaganej tabeli domyślnie jej zwartość musimy ustawić ją na Dynamiczny.
6. użyj następującego polecenia alter table table_name ROW_FORMAT=DYNAMIC;
7. zrobione

Zmień swoje zestawienie. Możesz użyć utf8_general_ci , który obsługuje prawie wszystkie

Na podstawie kolumny podanej poniżej, Te 2 zmienne kolumny łańcuchowe używają utf8_general_ci collation (utf8 charset jest implikowany).

W MySQL, utf8 charset używa maksymalnie 3 bajtów dla każdego znaku. W związku z tym musiałby przeznaczyć 500*3=1500 bajtów, co jest znacznie większe niż 767 bajtów MySQL pozwala. Dlatego dostajesz ten błąd 1071.

Innymi słowy, musisz obliczyć liczbę znaków na podstawie reprezentacji bajtów zestawu znaków, ponieważ nie każdy charset jest reprezentacją pojedynczego bajtu (jak przypuszczałeś.) Tj. utf8 w MySQL jest używany co najwyżej 3-bajt na znak, 767/3≈255 znaków, a dla utf8mb4, co najwyżej 4-bajtowa reprezentacja, 767/4≈191 znaków.

Wiadomo też, że MySQL

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

Naprawiłem ten problem za pomocą:

varchar(200) 

Zastąpione przez

varchar(191)

Wszystkie warszary, które mają więcej niż 200, zastępują je przez 191 lub ustawiają je jako tekst.

Znalazłem to zapytanie przydatne w wykrywaniu, które kolumny mają indeks naruszający maksymalną długość:

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

Proszę sprawdzić czy sql_mode jest jak

sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

Jeśli tak, zmień na

sql_mode=NO_ENGINE_SUBSTITUTION

Lub

Uruchom ponownie serwer zmieniając swoje my.plik cnf (putting following)

innodb_large_prefix=on

Tylko zmiana utf8mb4 Na {[1] } Podczas tworzenia tabel rozwiązała mój problem. Na przykład: CREATE TABLE ... DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; do CREATE TABLE ... DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;.

Zmień CHARSET pola indeksu reklamacji na "latin1"
np. ALTER TABLE TBL CHANGE myfield myfield varchar (600) zestaw znaków latin1 DEFAULT null;
latin1 pobiera jeden bajt dla jednego znaku zamiast czterech

Jeśli tworzysz coś w stylu:

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;

Powinno być coś w rodzaju

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;

Ale musisz sprawdzić unikalność tej kolumny z kodu lub dodać nową kolumnę jako MD5 lub SHA1 kolumny varchar

Jeśli ostatnio zmieniłeś innodb_log_file_size, spróbuj przywrócić poprzednią wartość, która działała.

W moim przypadku, miałem ten problem podczas tworzenia kopii zapasowej bazy danych przy użyciu znaków wyjścia/wejścia przekierowania Linuksa. Dlatego zmieniam składnię w sposób opisany poniżej. PS: używanie terminala linux lub mac.

Backup (bez > redirect)

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

Restore (bez

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

Błąd "podany klucz był zbyt długi; maksymalna długość klucza to 767 bajtów" zniknął.

Dla laravel 5.6

Kroki do wykonania

1. przejdź do app \ Providers \ AppServiceProvider.php
2. Add this to provider |/(Don ' t include pipeline) use Illuminate\Support\Facades \ Schema;
3. wewnątrz funkcji rozruchowej Dodaj ten schemat / / (nie dołączaj potoku):: defaultStringLength (191);

To wszystko, smacznego.

Dla mnie problem "# 1071-określony klucz był zbyt długi; maksymalna długość klucza to 767 bajtów" został rozwiązany po zmianie kombinacji primarykey / uniquekey poprzez ograniczenie rozmiaru kolumny o 200.

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

W przypadku, gdy uruchomisz Laravel (Laravel teraz domyślnie 4 bajtowy Unicode, co powoduje to) możesz rozwiązać ten problem zmieniając kolejne linie w config / database.php from

'charset' => 'utf8mb4',
'collation' => 'utf8mb4_unicode_ci',

 do

'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',