MySQL: Specified key was too long после перехода на utf8mb4

[lev7399]

Менял кодировку таблицы на utf8mb4 чтобы эмодзи в комментах не превращались в ???. И прилёг: Specified key was too long; max key length is 767 bytes на VARCHAR(255) с индексом. На utf8 всё работало. WTF?

[sqlreact9621]

Всё логично. utf8mb4 это 4 байта на символ, 255 * 4 = 1020 > 767. На utf8 было 3 байта, 255*3=765, впритык влезало. Лимит 767 байт — это старый InnoDB на DYNAMIC/COMPACT без large prefix.

[svetlana_official]

И что, всем урезать поля до VARCHAR(191)? Звучит как костыль.

[vlad_sql22]

191 это классический воркэраунд (191*4=764). Но правильнее включить innodb_large_prefix и ROW_FORMAT=DYNAMIC — тогда лимит станет 3072 байта и VARCHAR(255) спокойно индексируется. На MySQL 5.7.7+ это вообще по дефолту, у тебя видать старьё.

[valera_vector]

5.6, ага. Спасибо, поднял large_prefix + DYNAMIC, заработало без обрезания. И не забыл SET NAMES utf8mb4 в коннекте, а то эмодзи всё равно резались на уровне сессии.

[ruslan_py40]

Суть проблемы: utf8mb4 использует до 4 байт на символ вместо 3 у utf8. VARCHAR(255) * 4 = 1020 байт, что превышает лимит 767 байт для innodb_large_prefix выключенного или старого row format. Решений два: либо уменьшить длину индексируемого поля — ALTER TABLE t MODIFY COLUMN col VARCHAR(191), 191 * 4 = 764 байт, влезает. Либо включить innodb_large_prefix=ON плюс ROW_FORMAT=DYNAMIC или COMPRESSED на таблице — тогда лимит 3072 байта и VARCHAR(255) с utf8mb4 спокойно лезет. Второй путь правильнее если нельзя трогать схему.

[alina_tech]

Если на MySQL 5.7 — проблема в том, что там innodb_large_prefix по дефолту OFF. На MySQL 8.0 это уже не проблема, там DYNAMIC row format по умолчанию и лимит 3072. Если поддерживаете легаси 5.7, самый безопасный фикс без изменения данных: ALTER TABLE имя_таблицы ROW_FORMAT=DYNAMIC; после включения innodb_large_prefix в my.cnf. Но убедитесь что innodb_file_format=Barracuda там же выставлен, иначе DYNAMIC молча игнорируется на 5.6-5.7 ранних.