Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1
Вопрос 1: Допустим, character_set_client = cp1251. Это означает, что сервер MySQL будет ожидать от клиента текст sql-запросов в кодировке cp1251?
Вопрос 2: Теперь пусть character_set_connection = utf8mb3 и пусть требуется в sql-запросе выполнить сравнение строки с полем type таблицы animals. При этом поле type таблицы animals имеет кодировку koi8r. Запрос, например, такой:
SELECT id FROM animals WHERE type = 'кошка'.
MySQL-сервер получает этот запрос в кодировке cp1251, затем переводит поле записи type из кодировки koi8r в кодировку utf8mb3 и строку 'кошка' из кодировки cp1251 в кодировку utf8mb3 и уже только после этого производит сравнение (согласно установленному collation)?
Неактивен
Первый вопрос — да.
Второй вопрос — иногда В случае, когда используется полный скан по таблице, сравнение идет в памяти (и тогда оно должно идти в character_set_connection). В случае, когда над type есть индекс, MySQL должен преобразовать текст в кодировку поля, чтобы можно было использовать индекс.
Подробное описание этих переменных есть в документации: https://dev.mysql.com/doc/refman/8.0/en … ction.html
Но мне кажется, что в 21 веке вредно делать кодировки отличные от utf8/utf8mb4 где-либо вообще.
Неактивен
paulus написал:
Первый вопрос — да.
В случае, когда используется полный скан по таблице, сравнение идет в памяти (и тогда оно должно идти в character_set_connection). В случае, когда над type есть индекс, MySQL должен преобразовать текст в кодировку поля, чтобы можно было использовать индекс.
То есть, создание или удаление индекса для поля type может повлиять на результат запроса
SELECT id FROM animals WHERE type = 'кошка'; ? Ведь для кодировки поля и кодировки connection установлены разные collation.
paulus написал:
Но мне кажется, что в 21 веке вредно делать кодировки отличные от utf8/utf8mb4 где-либо вообще.
Дело в размере. Латинские буквы и цифры в utf8mb3/utf8mb4 весят по 1 байту, а русские – по 2 байта. В cp1251 все символы весят 1 байт. Получается, что в кодировке cp1251 нужно меньше памяти. Но дело не только в этом. Если в таблице есть поле типа CHAR, которое может содержать русские и английские буквы вперемешку, то, если кодировка поля cp1251, то размер поля для каждой записи имеет одинаковый размер в байтах, что скорей всего положительно сказывается на скорости SELECT. Если поле в кодировке utf8/utf8mb4, то размер поля будет "плавать". Ну и как бонус, для кодировки cp1251 меньше нагрузка на сеть.
Отредактированно immelnikoff (05.06.2018 12:18:09)
Неактивен
В 90-х, может быть это имело значение, но сегодня аргументация по поводу сети - не думаю, что имеет реальные основания. Настоятельно рекомендую послушаться совета paulus.
Неактивен
Я попробовал, MySQL оказался еще хитрее: для того, чтобы не свалиться с разным ответом, он игнорирует индекс в случае со смешанными кодировками (и приводит константные данные к кодировке столбца по умолчанию):
Неактивен
paulus написал:
для того, чтобы не свалиться с разным ответом, он игнорирует индекс в случае со смешанными кодировками (и приводит константные данные к кодировке столбца по умолчанию)
То есть, если
character_set_client = cp1251,
character_set_connection = utf8mb3,
а кодировка поля таблицы – koi8r,
то при запросе
Неактивен
Вам нужно в какой-то кодировке хранить данные в памяти. Вот это она.
Неактивен
Страниц: 1