То, как данные были изначально вставлены в MySQL, не имеет значения.Предположим, вы использовали весь набор символов utf8, например символы BMP.
utf8mb4 - это расширенный набор utf8mb3 (псевдоним utf8), как описано здесь
10.9.7 Преобразование между 3-байтовыми и 4-байтовыми наборами символов Юникода
Одним из преимуществ преобразования utf8mb3 в utf8mb4 является то, что это позволяет приложениям использовать дополнительные символы.Одним из компромиссов является то, что это может увеличить требования к пространству хранения данных.
С точки зрения содержимого таблицы преобразование из utf8mb3 в utf8mb4 не представляет проблем:
Для символа BMP:utf8mb4 и utf8mb3 имеют идентичные характеристики хранения: одинаковые кодовые значения, одинаковая кодировка, одинаковая длина.
Для дополнительного символа utf8mb4 требуется четыре байта для его хранения, тогда как utf8mb3 не может хранить символ ввсе.При преобразовании столбцов utf8mb3 в utf8mb4 вам не нужно беспокоиться о преобразовании дополнительных символов, поскольку их не будет.
С точки зрения структуры таблицы это основные потенциальные несовместимости:
Для символьных типов данных переменной длины (типы VARCHAR и TEXT) максимально допустимая длина в символах меньше для столбцов utf8mb4, чем для столбцов utf8mb3.
Для всех типов символов (CHAR, VARCHAR и TEXT) максимальное количество символов, которое можно проиндексировать, меньше для столбцов utf8mb4, чем для столбцов utf8mb3.
Следовательно, для преобразования таблиц из utf8mb3 в utf8mb4 может потребоваться изменить некоторые определения столбцов или индексов.
Лично у меня были некоторые проблемы с индексами относительно длинных текстов, когда был достигнут максимальный размер индекса.Это был поисковый индекс, а не уникальный индекс, поэтому обходной путь должен был использовать меньше символов в индексе.См. Также этот ответ
Конечно, я предполагаю, что вы будете использовать то же самое сопоставление.Если вы измените параметры сортировки, то возникнут другие проблемы.