utf8mb4_unicode_ci против utf8mb4_general_ci в mySQL

Question

Имеется таблица с текcтовым полем:

CREATE TABLE `table1` (
    ...
    `name` TEXT NULL DEFAULT NULL COLLATE 'utf8_general_ci',
    ...
) COLLATE='utf8_general_ci' ENGINE=InnoDB;

Пытаюсь перейти на кодировку utf8mb4_unicode_ci:

ALTER DATABASE myDB CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE `table1` COLLATE='utf8mb4_unicode_ci', CONVERT TO CHARSET utf8mb4;

И получаю вот это:

CREATE TABLE `table1` (
    ...
    `name` TEXT NULL DEFAULT NULL COLLATE 'utf8mb4_general_ci',
    ...
) COLLATE='utf8mb4_unicode_ci' ENGINE=InnoDB;

Т.е. для тектового поле кодировка utf8mb4_general_ci, а для таблицы utf8mb4_unicode_ci. Почему так происходит? Как привести все тектовые поля к кодировке utf8mb4_unicode_ci?

В настройках mySQL:

[server]
init_connect='SET NAMES utf8'
character_set_server=utf8mb4

[client]
default-character-set = utf8mb4.

[mysqld]
init_connect='SET collation_connection = utf8mb4_unicode_ci'
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
...


SHOW VARIABLES WHERE Variable_name LIKE 'character\_set\_%' OR Variable_name LIKE 'collation%';
+--------------------------+--------------------+
| Variable_name            | Value              |
+--------------------------+--------------------+
| character_set_client     | utf8mb4            |
| character_set_connection | utf8mb4            |
| character_set_database   | utf8mb4            |
| character_set_filesystem | binary             |
| character_set_results    | utf8mb4            |
| character_set_server     | utf8mb4            |
| character_set_system     | utf8               |
| collation_connection     | utf8mb4_general_ci |
| collation_database       | utf8mb4_unicode_ci |
| collation_server         | utf8mb4_unicode_ci |
+--------------------------+--------------------+

mySQL 5.7.33

Также возможно ли изменить collation_connection по умолчанию для клиентов mySQL в ее конфиге?

Answer 1

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

скорее всего какие-то функции пост-обработки он использует для старых записей, но они ломают все.

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

Могу ошибаться в деталях, но способ мне помог, когда переносил геобазу из ascii в utf8, хотя мускуль был старее нынешних, может быть сейчас все не так.

БЛОГ НА HUSL

utf8mb4_unicode_ci против utf8mb4_general_ci в mySQL

Ответы (1 шт):