Присоединение таблиц ASCII и UTF-8 добавляет накладных расходов?

Question

Многие таблицы будут хорошо работать, используя CHARACTER SET ascii COLLATE ascii_bin, что будет немного быстрее. Вот пример:

CREATE TABLE `session` (
    `id` CHAR(64) NOT NULL,
    `created_at` INTEGER NOT NULL,
    `modified_at` INTEGER NOT NULL,
    PRIMARY KEY (`id`),
    CONSTRAINT FOREIGN KEY (`user_id`) REFERENCES `user`(`id`)
) CHARACTER SET ascii COLLATE ascii_bin;

Но если бы я присоединился к нему:

CREATE TABLE `session_value` (
    `session_id` CHAR(64) NOT NULL,
    `key` VARCHAR(64) NOT NULL,
    `value` TEXT,
    PRIMARY KEY (`session_id`, `key`),
    CONSTRAINT FOREIGN KEY (`session_id`) REFERENCES `session`(`id`) ON DELETE CASCADE
) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;

что будет? Логика подсказывает, что все должно быть гладко, потому что ASCII является подмножеством UTF-8. Человеческая натура подсказывает мне, что я могу ожидать что угодно от дампа ядра до сообщения Follow the white rabbit., появляющегося на моем экране. ¯ \ _ (ツ) _ / ¯

Answer 1

Добавляет ли накладные расходы объединение таблиц ASCII и UTF-8?

Да .

Если вы делаете

SELECT whatever 
  FROM session s
  JOIN session_value v 
         ON s.id = v.session_id

обработчик запросов должен сравнить множество значений id и session_id, чтобы удовлетворить ваш запрос.

Если id и session_id имеют одинаковый тип данных, планировщик запросов сможет использовать индексы и быстрые сравнения.

Но если у них разные наборы символов, планировщик запросов должен интерпретировать ваш запрос следующим образом.

 ...  JOIN session_value v 
         ON CONVERT(s.id USING utf8mb4) = v.session_id

Когда условие WHERE или ON имеет форму f(column), это делает запрос несортируемым: это препятствует эффективному использованию индекса. Это может снизить производительность запросов.

В вашем случае аналогичные проблемы с производительностью возникнут при вставке строк в session_value: сервер должен выполнить преобразование, чтобы проверить ограничение внешнего ключа.

Если эти таблицы собираются в производство, было бы очень разумно использовать один и тот же набор символов для этих столбцов. Это гораздо проще исправить, если у вас тысячи строк, чем когда у вас миллионы. Серьезно.

Что делает оператор SQL пригодным для использования?

Answer 2

Почему бы не использовать UTF-8? Наличие ASCII-таблиц обычно является ошибкой, признаком того, что вы забыли установить кодировку для чего-либо. Использование единственного кодирования значительно упрощает вашу внутреннюю архитектуру.

Кодировка имеет значение только в том случае, если у вас есть столбцы CHAR, VARCHAR или TEXT.

Если у вас есть столбец этого типа, то по умолчанию стоит установить его как UTF8MB4.