Не понимаю что от меня хочет MySQL

PRIMARY KEY `PRIMARY` (`iEquColorID`,`sEquColorName`),
Specified key was too long; max key length is 767 bytes

https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_...

И что с этим делать? По сути это просто вытащенная из frm структура таблицы. Искать старый MySQL на котором это работало? А хз, я даже версии не знаю.

Прочитай внимательнее, что тебе скинули по ссылке.

Там всего-лишь надо включить опцию, разрешающую большие ключи.

Не работает это.

MariaDB [(none)]> set global innodb_large_prefix = 'ON'
    -> ;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> CREATE TABLE `color`.`equ_color` (
    ->   `iEquColorID` int(11) NOT NULL AUTO_INCREMENT comment 'Системный код производителя краски', 
    ->   `sEquColorName` varchar(765) NOT NULL comment 'Наименование производителя', 
    ->   `iActive` int(1) DEFAULT NULL comment 'Признак логического удаления. 0-архив; 1-живая запись', 
    -> PRIMARY KEY `PRIMARY` (`iEquColorID`,`sEquColorName`),
    -> UNIQUE KEY `iEquColorID_UNIQUE` (`iEquColorID`)
    -> ) ENGINE=InnoDB COMMENT 'Справочник производителей краски';
ERROR 1709 (HY000): Index column size too large. The maximum column size is 767 bytes.

Нормализация, твою мать. До ю андестенд? Вместо названия производителя поставь идентификатор производителя из справочной таблицы.

Судя по всему ты такой одарённый не один, раз они даже до 767 позволяют ключи делать. Но ты превзошёл дебилов из дебилов! Прям герой.

Не моя база, мне её просто восстановить надо.

view сделай. А структуру нормальную. Оптимизатор должен разобраться

Можно подробнее? Никогда с MySQL особо не работал.

Если вываливается такая ошибка достаточно уменьшить размер поля скажем до 150 симолов

PRIMARY KEY `PRIMARY` (`iEquColorID`,`sEquColorName`)

Зачем тебе вторая колонка в primary key, если у тебя первая - int/autoincrement и уникальная по определению? Делай отдельный btree индекс по второй колонке и не парься.

P.S. Схему базы проектировал рукожоп.

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

В переводе на русский язык: спецификация слишком длинная, максимальная длина может быть = 767 байтов...

кодировка наверное utf8mb4 вот и все проблемы

Там и двух байт на символ хватит, чтобы за лимит выйти

Зачем тебе вторая колонка в primary key, если у тебя первая - int/autoincrement и уникальная по определению? Делай отдельный btree индекс по второй колонке и не парься.

Два чая

Так как написать то? И оно сработает? По идее я потом буду делать ALTER TABLE таблица DISCARD TABLESPACE;, подпихивать файлы, а потом писать ALTER TABLE таблица IMPORT TABLESPACE;. И резко бэкапить пока оно вообще работает.

Я просто в первый раз, если честно, столкнулся с sql.

да нужно просто уменьшить varchar(765) до 755, это же Наименование производителя ёмаё

Вместо названия производителя поставь идентификатор производителя из справочной таблицы.

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

Короче я воспользовался другой версией mysqlfrm, она мне выдала другие структуры таблиц. Правда, без комментов. Решил забить, пофигу. В целом всё работает. Гляну что скажет чувак который это заказал.

Два чая

какой нах 2 чая если это просто костыли и обход проблемы, а вот иногда (не спрашивай зачем:)) нужен именно такой индекс

фикс сдесь следующий
https://dev.mysql.com/doc/refman/5.7/en/create-index.html
нужно просто ограничить длину нужной колонки для индекса до приемлемой
к примеру

PRIMARY KEY `PRIMARY` (`iEquColorID`,`sEquColorName`(20)),

Мои исправления структуры будут работать точно также, как и старые, а вот как раз твое изменение и есть костыль. Ключ UNIQUE KEY `iEquColorID_UNIQUE` (`iEquColorID`) как в ОП избыточен, так как составной ключ может работать как ключ только по первому полю а пихать индекс по sEquColorName в первичный ключ не имеет никакого смысла.

не спрашивай зачем:)

А вот спрошу.

Мои исправления структуры будут работать точно также, как и старые

нет
к примеру может быть ситуация INSERT ... ON DUPLICATE KEY UPDATE
если убрать составной ключ - работать будет неверно

Ключ UNIQUE KEY `iEquColorID_UNIQUE` (`iEquColorID`) как в ОП избыточен, так как составной ключ может работать как ключ только по первому полю а пихать индекс по sEquColorName в первичный ключ не имеет никакого смысла.

а разве я говорил обратное? он здесь нахрен не нужен
Просто нельзя просто так удалить составной индекс, т.к. на нем может быть завязана другая логика

P.S. Схему базы проектировал рукожоп.

это точно