Кодировка и соединение БД битрикс в utf8mb4?

Question

[Tech]

Подскажите, правильно ли я сдлелал.
Суть: База данных кочевала по серверам, по-видимому, имевших различие в настройках character и collation сервера mysql. В БД существуют, как utf8, так и utf8mb4, utf8_general_ci, utf8_unicode_ci, utf8mb4_general_ci, utf8mb4_unicode_ci.

Выполнение "Проверки системы" в административном разделе 1с-битрикса постоянно ругалось, на это всё. Автоматически исправишь, опять запускаешь проверку, еще что-то вылезает, лезешь делать смену потаблично. Опять проверяешь, опять что-то не нравится.

Решил поступить, возможно, слишком "влоб".
Учитывая, что хотелось бы всё иметь в utf8mb4 и ut8fmb4_unicode_ci (современно, с эмодзи и всё такое, битрикс кстати обновлен тоже до последней версии), открыл дамп бд в vim-е, заменил всё на вышеуказанные кодировку и сравненние.
Подсунул этот дамп битриксу. Запустил проверку, она ругнулась, что кодировка отличается utf8 <---> utf8mb4.
Посмотрел в настройки двух файлов php_interface/after_connect{_d7}.php:
Там:

$this->queryExecute("SET NAMES 'utf8'");                                                                                                                                                    
$this->queryExecute('SET collation_connection = "utf8_unicode_ci"');

Заменила на:

$this->queryExecute("SET NAMES 'utf8mb4'");                                                                                                                                                    
$this->queryExecute('SET collation_connection = "utf8mb4_unicode_ci"');

Теперь "Проверка системы" выполнятеся без ошибок.
Вопрос, чреват ли чем-то такой метод? Не костыли ли это?

Comments

[alexalexes]

Если навскидку прикинуть, что пространство символов utf8mb4_unicode_ci шире и оно вмещает все пространство utf8_unicode_ci, то перевод utf8_unicode_ci на utf8mb4_unicode_ci должен пройти безболезненно.
Возможны косяки, если вы переводите кодировку из широкого в узкое пространство, там выпадут из дампа символы, которые находились в более широкой части регистра пространства, чем позволяет конечная кодировка (как раз эмодзи могут пострадать), но это не ваш случай.

[Akina]

чреват ли чем-то такой метод?

В общем случае да.

Есть одна мелочь в определении collation, на которую обычно не обращают внимания - это space padding. Некоторые collation учитывают хвостовые пробелы при сравнении, некоторые нет. Если эта характеристика не изменяется - то гарантированно всё ровненько. Иначе - надо проверять и убеждаться, что учёт хвостовых пробелов не влияет на поведение программного обеспечения.

См. Trailing Space Handling in Comparisons.

В данном же конкретном случае проблем не будет - и у utf8mb3_unicode_ci, и у utf8mb4_unicode_ci значение Pad_attribute одинаково и равно PAD SPACE. Т.е. сделанная замена никак не изменяет поведения.