Коли я виконав таку команду:

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

Я отримав це повідомлення про помилку:

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

Інформація про колонку1 та стовпчик2:

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

Я думаю, що varchar(20)потрібно лише 21 байт, тоді varchar(500)як потрібно лише 501 байт. Отже, загальна кількість байтів - 522, менше 767. То чому я отримав повідомлення про помилку?

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

767 байт - заявлене обмеження префікса для таблиць InnoDB у версії 5.6 MySQL (та попередніх версіях). Це 1000 байтів для таблиць MyISAM. У MySQL версії 5.7 і вище цей ліміт був збільшений до 3072 байт.

Ви також повинні мати на увазі, що якщо ви встановите індекс на велике поле char або varchar, яке закодовано utf8mb4, вам слід розділити максимальну довжину префікса індексу 767 байт (або 3072 байта) на 4, що призводить до 191. Це тому, що максимальна довжина символу utf8mb4 - чотири байти. Для символу utf8 це буде три байти, що призводить до максимальної довжини префікса - 254.

Один із варіантів - просто встановити нижню межу на полях VARCHAR.

Інший варіант (відповідно до відповіді на це питання ) - отримати підмножину стовпця, а не всю суму, тобто:

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

Налаштуйте, як вам потрібно отримати ключ, який потрібно застосувати, але мені цікаво, чи варто було б переглянути вашу модель даних щодо цієї сутності, щоб побачити, чи є вдосконалення, які дозволять вам реалізувати призначені бізнес-правила, не зачіпаючи обмеження MySQL.

Якщо у когось є проблеми з INNODB / Utf-8, намагаючись поставити UNIQUEіндекс на VARCHAR(256)поле, переключіть його на VARCHAR(255). Здається, 255 є обмеженням.

Коли ви досягнете межі. Встановіть наступне.

• ІННОДБ utf8 VARCHAR(255)
• ІННОДБ utf8mb4 VARCHAR(191)

MySQL передбачає найгірший випадок для кількості байтів на символ у рядку. Для кодування "utf8" MySQL це 3 байти на символ, оскільки таке кодування не дозволяє використовувати символи U+FFFF. Для кодування MySQL 'utf8mb4' це 4 байти на символ, оскільки саме так MySQL називає фактичний UTF-8.

Тож припускаючи, що ви використовуєте 'utf8', ваш перший стовпець займе 60 байт індексу, а другий ще 1500.

запустіть цей запит перед запитом:

SET @@global.innodb_large_prefix = 1;

це збільшить межу до 3072 bytes.

Рішення для Laravel Framework

Відповідно до документації Laravel 5.4. * ; Ви повинні встановити довжину рядка за замовчуванням у bootметоді app/Providers/AppServiceProvider.phpфайлу наступним чином:

use Illuminate\Support\Facades\Schema;

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

Пояснення цього виправлення, надане Laravel 5.4. * Документацією :

Laravel використовує utf8mb4набір символів за замовчуванням, який включає підтримку зберігання "емоджи" в базі даних. Якщо ви використовуєте версію MySQL, старшу за версію 5.7.7 або MariaDB, старшу за версію 10.2.2, можливо, вам доведеться вручну налаштувати довжину рядка за замовчуванням, згенеровану міграціями, щоб MySQL створив для них індекси. Ви можете налаштувати це, зателефонувавши Schema::defaultStringLengthу ваш метод AppServiceProvider.

Крім того, ви можете включити innodb_large_prefixпараметр для вашої бази даних. Зверніться до документації вашої бази даних щодо інструкцій, як правильно включити цю опцію.

Яке кодування символів ви використовуєте? У деяких наборах символів (наприклад, UTF-16 та ін.) Використовується більше одного байта на символ.

Я думаю, що для varchar (20) потрібно лише 21 байт, тоді як varchar (500) вимагає лише 501 байт. Отже, загальна кількість байтів - 522, менше 767. То чому я отримав повідомлення про помилку?

Для зберігання рядка UTF8 потрібно 3 байти на символ , тому у вашому випадку 20 + 500 символів = 20 * 3 + 500 * 3 = 1560 байт, що більше, ніж дозволено 767 байт.

Обмеження для UTF8 становить 767/3 = 255 символів , для UTF8mb4, який використовує 4 байти на символ, це 767/4 = 191 символ.

Існує два рішення цієї проблеми, якщо вам потрібно використовувати довший стовпець, ніж ліміт:

1. Використовуйте "дешевше" кодування (те, що вимагає менше байтів на персонаж)
   У моєму випадку мені потрібно було додати унікальний індекс на стовпчик, що містить SEO рядок статті, оскільки я використовую лише [A-z0-9\-]символи для SEO, я використовував, latin1_general_ciякий використовує лише один байт на символ і тому стовпець може мати довжину 767 байт.
2. Створіть хеш із стовпця та використовуйте унікальний індекс лише для цього
   . Іншим варіантом для мене було створення ще одного стовпця, який би зберігав хеш SEO, цей стовпець мав би UNIQUEключ до того, щоб значення SEO були унікальними. Я також додав би KEYіндекс до оригінальної колонки SEO, щоб пришвидшити пошук.

Тут вже відповіли багато користувачів про те, чому ви отримуєте повідомлення про помилку. Моя відповідь - про те, як це виправити та використовувати як є.

Перейдіть за цим посиланням .

1. Відкрийте клієнт MySQL (або клієнт MariaDB). Це інструмент командного рядка.
2. Він запитає ваш пароль, вводить ваш правильний пароль.
3. Виберіть вашу базу даних за допомогою цієї команди use my_database_name;

База даних змінена

4. set global innodb_large_prefix=on;

Запит OK, 0 рядків задіяно (0,00 сек)

5. set global innodb_file_format=Barracuda;

Запит добре, 0 рядків зачеплені (0,02 сек)

6. Перейдіть у свою базу даних на phpMyAdmin або щось подібне для зручного управління. > Виберіть базу даних> Перегляд структури таблиці > Перейдіть на вкладку « Операції ». > Змініть ROW_FORMAT на DYNAMIC і збережіть зміни.
7. Перейдіть на вкладку структури таблиці> Натисніть кнопку Унікальна .
8. Зроблено. Тепер у нього не повинно бути помилок.

Проблема цього виправлення полягає в тому, що ви експортуєте db на інший сервер (наприклад, з localhost на реальний хост) і ви не можете використовувати командний рядок MySQL на цьому сервері. Ви не можете змусити його працювати там.

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

Ви отримали це повідомлення, оскільки 1 байт дорівнює 1 символу, лише якщо ви використовуєте latin-1набір символів. Якщо ви використовуєте utf8, кожен символ вважатиметься 3 байтами при визначенні ключового стовпця. Якщо ви користуєтесь utf8mb4, кожен символ вважатиметься 4 байтами при визначенні вашого стовпця ключа. Таким чином, вам потрібно помножити ліміт символів вашого ключового поля на, 1, 3 або 4 (на моєму прикладі), щоб визначити кількість байтів, яке намагається дозволити поле ключа. Якщо ви використовуєте uft8mb4, ви можете визначити лише 191 символ для рідного, InnoDB, поля первинного ключа. Просто не порушуйте 767 байт.

ви можете додати стовпчик md5 довгих стовпців

Замінити utf8mb4з utf8в файлі імпорту.

З цією проблемою ми стикалися, намагаючись додати UNIQUE індекс до поля VARCHAR (255) за допомогою utf8mb4. Хоча проблема тут уже добре окреслена, я хотів додати кілька практичних порад щодо того, як ми це розібрали та вирішили.

Під час використання utf8mb4 символи розраховуються як 4 байти, тоді як під utf8 вони можуть бути 3 байтами. Бази даних InnoDB мають обмеження, що індекси можуть містити лише 767 байт. Отже, використовуючи utf8, ви можете зберігати 255 символів (767/3 = 255), але використовуючи utf8mb4, ви можете зберігати лише 191 символ (767/4 = 191).

Ви абсолютно можете додати звичайні індекси для VARCHAR(255)полів, використовуючи utf8mb4, але те, що відбувається - розмір індексу скорочується на 191 символ автоматично - як unique_keyтут:

Це добре, адже звичайні індекси просто використовуються для швидшого пошуку MySQL за вашими даними. Не потрібно індексувати все поле.

Отже, чому MySQL обрізає індекс автоматично для звичайних індексів, але видає явну помилку, намагаючись зробити це для унікальних індексів? Ну а для того, щоб MySQL міг зрозуміти, чи є введене чи оновлене значення вже існує, воно має фактично індексувати ціле значення, а не лише його частину.

Зрештою, якщо ви хочете мати унікальний індекс на полі, весь вміст поля повинен вміщуватися в індекс. Для utf8mb4 це означає зменшити довжину поля VARCHAR до 191 символу або менше. Якщо вам не потрібна utf8mb4 для цієї таблиці або поля, ви можете повернути її до utf8 і мати змогу зберегти свої поля довжиною 255.

Ось моя оригінальна відповідь:

Я просто скидаю базу даних і відтворюю так, і помилка відсутня:

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

Однак це працює не у всіх випадках.

Це фактично проблема використання індексів на стовпцях VARCHAR з набором символів utf8(або utf8mb4), з стовпцями VARCHAR, що мають більше певної довжини символів. У випадку utf8mb4, що певна довжина дорівнює 191.

Для отримання додаткової інформації про використання довгих індексів у базі даних MySQL див. набір символів-utf8mb4

5 обхідних шляхів:

Ліміт був підвищений у 5.7.7 (MariaDB 10.2.2?). І її можна збільшити за допомогою деякої роботи в 5.6 (10.1).

Якщо ви досягаєте межі через спробу використання CHARACTER SET utf8mb4. Потім виконайте одне з наступних (у кожного є недолік), щоб уникнути помилки:

⚈  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

Я вирішив цю проблему за допомогою:

varchar(200) 

замінено на

varchar(191)

усі варшари, яких налічується понад 200, замінюють їх на 191 або встановлюють текст.

Я здійснив деякий пошук на цю тему, нарешті, отримав певні зміни

Для робочої версії MySQL 6.3.7 Версія доступна графічна міжфазова фаза

1. Запустіть Workbench та виберіть з'єднання.
2. Перейдіть до управління чи екземпляра та виберіть Файл опцій.
3. Якщо Workbench попросить вас дозволити прочитати файл конфігурації, а потім дозвольте його, натиснувши ОК два рази.
4. На центральне місце приходить вікно файлу параметрів адміністратора.
5. Перейдіть на вкладку InnoDB і перевірте innodb_large_prefix, якщо він не встановлений у розділі Загальні.
6. встановіть для параметра innodb_default_row_format значення DYNAMIC.

Для версій нижче 6.3.7 прямі опції недоступні, тому потрібно перейти до командного рядка

1. Запустіть CMD як адміністратор.
2. Перейдіть до директора, де встановлено сервер mysql Більшість випадків - це в "C: \ Program Files \ MySQL \ MySQL Server 5.7 \ bin", тому команда - "cd \" "CD Програмні файли \ MySQL \ MySQL Server 5.7 \ bin".
3. Тепер запустіть команду mysql -u userName -p databasescheema Тепер вона запитала пароль відповідного користувача. Введіть пароль і введіть у запит mysql.
4. Ми повинні встановити деякі глобальні налаштування, введіть команди нижче, одна за одною, глобальний innodb_large_prefix = увімкнено; встановити глобальний innodb_file_format = barracuda; встановити глобальний innodb_file_per_table = true;
5. Тепер, нарешті, ми повинні змінити ROW_FORMAT необхідної таблиці за замовчуванням її COMPACT, ми повинні встановити її на DYNAMIC.
6. використовувати наступну команду alter table table_name ROW_FORMAT = DYNAMIC;
7. Зроблено

Для laravel 5,7 до 6,0

Кроки, які слід виконати

1. Йти до App\Providers\AppServiceProvider.php .
2. Додайте це до постачальника use Illuminate\Support\Facades\Schema; вгорі.
3. Всередині функції завантаження Додайте це Schema::defaultStringLength(191);

що все, насолоджуйтесь.

змінити своє порівняння. Ви можете використовувати utf8_general_ci, який підтримує майже всіх

Тільки зміни utf8mb4в utf8при створенні таблиць вирішити мою проблему. Наприклад: CREATE TABLE ... DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;до CREATE TABLE ... DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;.

Щоб виправити це, це працює для мене як шарм.

ALTER DATABASE dbname CHARACTER SET utf8 COLLATE utf8_general_ci;

Спираючись на поданий нижче стовпчик, ці 2 стовпчики змінних рядків використовують utf8_general_ciзіставлення ( utf8діаграма мається на увазі).

У MySQL utf8charset використовує максимум 3 байти для кожного символу. Таким чином, потрібно було б виділити 500 * 3 = 1500 байт, що набагато більше, ніж дозволяє 767 байт, який дозволяє MySQL. Ось чому ви отримуєте цю помилку 1071.

Іншими словами, вам потрібно обчислити кількість символів , заснований на поданні байт кодову сторінку як не кожен набір символів один байт уявлення (як передбачається) . IE utf8в MySQL є використання в більшості 3 байта на символ, 767 / 3≈255 символів, і дляutf8mb4 , максимум, 4-байтне представлення, 767 / 4≈191 символ.

Також відомо, що MySQL

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

Я вважав цей запит корисним для визначення того, які стовпці мають індекс, що порушує максимальну довжину:

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

Перевірте, чи sql_modeподобається

sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

якщо є, перейдіть на

sql_mode=NO_ENGINE_SUBSTITUTION

АБО

перезапустіть сервер, змінивши файл my.cnf (поставивши наступне)

innodb_large_prefix=on

У моєму випадку у мене виникла ця проблема, коли я створював резервну копію бази даних за допомогою символів виводу / вводу перенаправлення Linux. Тому я змінюю синтаксис, як описано нижче. PS: використання linux або mac-терміналу.

Резервне копіювання (без перенаправлення)

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

Відновити (без <переспрямування)

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

Помилка "Вказаний ключ був занадто довгим; максимальна довжина ключа - 767 байт", просто зникла.

Індекс довжини та MySQL / MariaDB

Laravel використовує набір символів utf8mb4 за замовчуванням, який включає підтримку зберігання "емоджи" в базі даних. Якщо ви використовуєте версію MySQL, старшу за версію 5.7.7 або MariaDB, старшу за версію 10.2.2, можливо, вам доведеться вручну налаштувати довжину рядка за замовчуванням, згенеровану міграціями, щоб MySQL створив для них індекси. Ви можете налаштувати це, викликавши метод Schema :: defaultStringLength у своєму AppServiceProvider:

use Illuminate\Support\Facades\Schema;

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

Крім того, ви можете включити параметр innodb_large_prefix для вашої бази даних. Зверніться до документації вашої бази даних щодо інструкцій, як правильно включити цю опцію.

Довідка з блогу: https://www.scratchcode.io/specified-key-too-long-error-in-laravel/

Довідка з офіційної документації на laravel: https://laravel.com/docs/5.7/migramigra

Якщо ви створюєте щось на кшталт:

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;

це має бути щось на кшталт

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;

але вам потрібно перевірити унікальність цього стовпця з коду або додати новий стовпець у вигляді MD5 або SHA1 колонки varchar

Через обмеження префікса ця помилка станеться. 767 байт - заявлене обмеження префікса для таблиць InnoDB у версіях MySQL до 5.7. Це 1000 байтів для таблиць MyISAM. У MySQL версії 5.7 і вище цей ліміт був збільшений до 3072 байт.

Виконавши таке в сервісі, що дає помилку, має вирішити вашу проблему. Це потрібно запустити в MYSQL CLI.

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

Зміна CHARSET поля індексу, що скаржиться, на "latin1",
тобто ALTER TABLE tbl CHANGE myfield myfield varchar (600) CHARACTER SET latin1 DEFAULT NULL;
latin1 бере один байт для одного символу замість чотирьох

Якщо ви innodb_log_file_sizeнещодавно змінилися , спробуйте відновити попереднє значення, яке працювало.