Быстрый запрос в latin1, медленный в utf8 - почему?

Question

У меня есть запрос, который выглядит примерно так:

 SELECT DISTINCT table1.id, {long list of fields} FROM table1 
     INNER JOIN table2 ON table1.table2_id = table2.id 
     {... more joins ...} 
     LEFT JOIN table_last ON table_last.id=some_table.last_id
     WHERE ( table_last.id IS NULL) AND {...more conditions...}
     ORDER BY table1.date_entered desc LIMIT 0,6

Этот запрос в той же базе данных работает нормально (<1s runtime) при запуске с latin1 в качестве клиентской кодировки и очень медленный (не может)t дождаться его окончания) после <code>SET NAMES 'utf8'.Запрос возвращает 70 строк (конечно, часть до лимита), поэтому размер результирующего набора не должен быть проблемой.Я проверил все таблицы во всех соединениях, и все они, кажется, имеют UTF-8 в качестве своей кодировки (я проверил с SHOW TABLE CREATE).

Что может вызвать такое странное поведение?Насколько utf8 в этом случае намного хуже, чем latin1?Если это уместно, поле идентификатора char(36) везде, и в объединениях есть условия, основанные на таких полях, а также целочисленные поля и поля varchar.

PS Я знаю, DISTINCT может занять некоторое время, но я не могу удалить его, так или иначе, его 70 строк, и он работает быстро по умолчанию (latin1)!Так что это выглядит как нечто внешнее по отношению к запросу, но что?

Answer 1

Когда вы используете таблицу utf8, она выделяет в 3 раза длину varchar для каждой строки (256 * 3 = 768 байт)!

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