Unknown collation при переносе MySQL: как выбрать путь

Unknown collation при импорте означает, что целевая СУБД не распознаёт указанное имя правила сравнения строк. Сначала установите продукты, версии и поддерживаемые collations обеих сторон. Затем выбирайте совместимую среду либо проверяемое преобразование: простая замена utf8mb4_0900_ai_ci в дампе ещё не доказывает сохранение поведения приложения.

Сохраните исходник и соберите паспорт переноса

Не редактируйте единственную копию выгрузки. Сохраните оригинал, отметьте источник и время получения, а эксперименты проводите на отдельной копии. Это позволит отличить свойства исходной базы от изменений, внесённых ради совместимости.

В паспорте укажите продукт и версию сервера, способ экспорта, версию приложения, используемые кодировки и collations. Нужны фактические сведения о целевой СУБД, а не только название хостингового тарифа. MySQL и MariaDB следует проверять как отдельные продукты.

В разборе ошибки cPanel причиной названа разница версий исходного и целевого серверов MySQL или MariaDB. Публикация предлагает замену имени как обходной путь. Это не подтверждение, что любые сравнения после замены останутся прежними.

Кодировка и правило сравнения — разные свойства

Кодировка определяет представление символов, а collation — правила их сравнения и сортировки. В описании имён MySQL разобраны признаки чувствительности: например, ci относится к регистру, ai — к акцентам. Совпадение начала имени не делает остальные свойства одинаковыми.

Нельзя исправить неизвестное правило переключением всей базы на случайную другую кодировку. Задача переноса — сохранить нужные данные и согласованную семантику операций. Если символы отображаются правильно, это ещё не доказывает правильность поиска или проверки уникальности.

В справочнике MariaDB описано получение доступных наборов и правил для конкретной версии. Проверяйте реальный перечень своего сервера; утверждение «в MariaDB такое никогда не поддерживается» слишком широко для диагностики переноса.

Три решения, которые стоит рассмотреть до правки дампа

• Восстановление в среду, которая поддерживает исходные правила и совместима с приложением. Это требует проверки всего пути миграции, а не только одного имени.
• Повторный экспорт с согласованными настройками совместимости, если выбранные инструменты действительно поддерживают такой сценарий. Результат всё равно проверяется на копии.
• Осознанное преобразование правил сравнения с приёмкой изменившегося поведения. Это решение о данных приложения, а не обычная замена текста.

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

Что проверить на восстановленной копии

Следующая таблица — предлагаемый протокол приёмки условного каталога. Примеры нужно заменить безопасными данными своего проекта. Пустой результат проверки нельзя заполнять предположением «раз импорт завершился, всё совпало».

Почему даже пробел в конце заслуживает проверки

MySQL отдельно описывает PAD SPACE и NO PAD. Для небинарных строк этот атрибут влияет на учёт концевых пробелов при сравнении. При этом LIKE рассмотрен отдельно: переносить на него вывод об обычном сравнении нельзя.

Учебная пара — два кода, у одного из которых есть конечный пробел. Это не предложение хранить такие коды в вашей системе. Пара помогает поставить вопрос: считаются ли значения равными при выбранном правиле и допустимо ли такое поведение для фактического типа поля?

Свойства хранения CHAR и VARCHAR тоже не следует смешивать. Проверяйте реальные столбцы и запросы приложения, а не только абстрактную строковую операцию. Если перенос требует очистки данных, оформите её отдельным согласованным изменением с проверяемым результатом.

Не обходите конфликт уникальности потерей записей

Предположим, после преобразования правила два значения стали конфликтовать. Удаление одной строки ради завершения импорта — уже изменение бизнес-данных. Владелец приложения должен решить, допустимо ли объединение, исправление значения или другой путь совместимости.

Мы советуем получить список конфликтов до переключения сайта и разобрать их по назначению поля. Логин, артикул и название категории могут требовать разных решений. Автоматически применённое правило очистки не должно незаметно менять владельца учётной записи или связь товара с заказом.

Приёмка состоит из двух отдельных результатов

Первый результат — база восстановлена: ожидаемые объекты и данные доступны, ошибки импорта разобраны. Второй — приложение правильно работает на этой базе. Число перенесённых строк полезно, но само по себе не подтверждает поиск, вход пользователей и повторное сохранение объектов.

Отберите операции, чувствительные к строковым сравнениям, и запишите ожидаемое поведение до проверки. Для каталога это могут быть поиск кода, фильтр, сортировка и создание новой записи. Для другого приложения состав будет иным; проверка должна следовать его данным.

Порядок решения ошибки

1. Сохраните оригинальный дамп и зафиксируйте исходную среду.
2. Установите продукт, версию и доступные collations целевого сервера.
3. Выберите путь совместимости с учётом требований приложения.
4. Подготовьте отдельную копию для пробного восстановления.
5. Сравните строковые операции и ограничения на контрольном наборе.
6. Разберите конфликты без скрытой потери данных.
7. Переключайте приложение только после приёмки и подготовки возврата.

В сопровождении сервера полезно сохранить паспорт среды для будущих переносов. Если потребовалась адаптация запросов или данных, оформите её как доработку приложения. Тогда исчезновение Unknown collation будет одним из подтверждённых результатов, а не единственным критерием успеха.