Кодировка соединения MySQL: проверка каждого участка обмена

Таблица использует utf8mb4, но один клиент записывает кириллицу правильно, а другой — нет. Значит, одной настройки столбца недостаточно. Посмотрим, какую кодировку объявляет соединение MySQL 8.0, что фактически попало в таблицу и как отличить повреждённые данные от ошибки отображения.

Смотрим параметры текущего соединения

SELECT @@character_set_client,
       @@character_set_connection,
       @@character_set_results,
       @@collation_connection;
SET NAMES utf8mb4;
SELECT @@character_set_client,
       @@character_set_connection,
       @@character_set_results;
SELECT HEX('Привет'), CHAR_LENGTH('Привет');

client описывает кодировку входящих запросов, connection участвует в обработке текстовых выражений, а results задаёт преобразование выдаваемых результатов. SET NAMES меняет эти параметры для текущего соединения. Команда сообщает серверу, как интерпретировать отправляемые байты; она не перекодирует неверно сформированную строку на стороне приложения.

Сравниваем запись и чтение

CREATE TABLE demo_charset (id integer PRIMARY KEY, body varchar(80))
  ENGINE=InnoDB DEFAULT CHARACTER SET utf8mb4;
INSERT INTO demo_charset VALUES (1, 'Привет');
SELECT id, body, HEX(body), CHAR_LENGTH(body), LENGTH(body)
FROM demo_charset WHERE id = 1;

Для корректно переданного слова ожидаются шесть символов и двенадцать байт UTF-8. Повторите чтение из второго клиента с явно настроенным utf8mb4 и сравните HEX. Если байты хранения правильные, а отображение отличается, исследуйте преобразование результата и терминал. Если уже сохранённые байты неправильные, смена шрифта не исправит данные.

Настройка должна переживать новые подключения

В приложении задавайте кодировку через предусмотренную настройку драйвера при создании соединения. Ручная команда в консоли не меняет конфигурацию пула приложения. Проверьте новое подключение, восстановление после разрыва и фоновые обработчики: именно они часто используют другой путь инициализации. Сопоставляйте настройки одного конкретного соединения, а не случайные глобальные значения. Запишите название клиента и способ создания соединения рядом с результатом проверки, чтобы следующий специалист мог воспроизвести именно проблемный маршрут передачи текста.

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

Источники и дальнейшее чтение

• MySQL 8.0: кодировка соединения
• MySQL 8.0: настройка приложений