MySQL row_format сжатый и динамический

Я изменил "innodb_file_format" от "Antelope" до "Barracuda" bcoz по следующим причинам.

  • Чтобы избежать ограничения размера строки
  • Чтобы избежать ограничения размера индекса столбца

При изменении формата файла я выбрал "row_format" как "динамический". Это работает нормально.

Но мне хотелось бы изменить "row_format" с "dynamic" на "сжатый" для сжатия данных. Может ли кто-нибудь сказать мне

  • Имеет ли отношение row_format отношение к индексам COLUMN и ВСТАВКА ДАННЫХ в таблицы? Если да, то что рекомендуется и почему?
  • Будет ли сжатый формат приводить к ухудшению производительности?

ОТВЕТЫ

Ответ 1

Использование DYNAMIC или COMPRESSED означает, что InnoDB хранит поля varchar/text/blob, которые не помещаются на странице полностью вне страницы. Но кроме этих столбцов, которые тогда учитывают только 20 байтов на столбец, ограничение размера строки InnoDB не изменилось; он по-прежнему ограничен примерно 8000 байтами в строке.

InnoDB поддерживает только индексы 767 байт на столбец. Вы можете поднять этот 3072 байта, установив innodb_large_prefix=1 и используя формат строки DYNAMIC или COMPRESSED.

Использование формата строки COMPRESSED не заставляет InnoDB поддерживать более длинные индексы.

Что касается производительности, это один из тех случаев, когда "это зависит". Сжатие, как правило, представляет собой компромисс между размером хранилища и загрузкой процессора для сжатия и распаковки. Верно, что для работы со сжатыми данными требуется немного больше процессора, но вы должны помнить, что серверы баз данных обычно ждут ввода-вывода и имеют ресурсы ЦП.

Но не всегда - если вы выполняете сложные запросы против данных, находящихся в пуле буферов, вы можете быть ограничены CPU больше, чем I/O. Таким образом, это зависит от многих факторов, таких как то, насколько хорошо ваши данные вписываются в ОЗУ, тип запросов, которые вы запускаете, и сколько запросов в секунду, а также аппаратные спецификации. Слишком много факторов, чтобы кто-либо еще мог отвечать за ваше приложение на вашем сервере. Вам просто нужно проверить его.

Ваш комментарий:

Одна из возможностей заключается в том, что индекс не подходит в пуле буферов. Производительность значительно ухудшается, если поиск по индексу требует загрузки страниц и выселения страниц во время каждого запроса SELECT. Анализ EXPLAIN не может определить, подходит ли индекс в пуле буферов.

Я не знаю, сколько столбцов или какие типы данных столбцов в вашем индексе, но если вы индексируете длинные столбцы varchar, вам следует рассмотреть использование префиксных индексов (или уменьшение длины столбцов).

Вы также можете получить больше ОЗУ и увеличить размер пула буферов.

Ответ 2

Сжатый будет сжимать данные. Текст будет сжат очень хорошо. У меня есть несколько таблиц и раньше использовала DYNAMIC, переехала в COMPRESSED.

Я использую MySQL 5.7

Таблица:

  • id (int)
  • some_other_id (int)
  • текст (длинный текст) - utf8mb4_unicode_ci ~ 500 КБ/средняя строка
  • updated_at (int)
  • создал_ (инт)

Он использует на 80% меньше места при сжатии по сравнению с динамическим. До: 80Gb, после: 16Gb Огромное сохранение, пока мне не нужны эти данные.

Другие таблицы не были такими уж драматичными, но это сэкономило ~ 50% там, где есть текстовые поля. Например, другой из 6.4Gb → 3.1Gb с 1,5M строк.

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