Формат строки MySQL сжатый vs динамический

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

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

при изменении формата файла я выбрал "row_format"как " dynamic". Это работает нормально.

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

  1. - Это помощью row_format есть отношение к индексам столбцов и вставкам данных в таблицы? Если да, то что рекомендуется и почему?
  2. приведет ли сжатый формат к ухудшению производительности?
11
innodb mysql

2 ответов

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

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

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

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

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

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

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

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

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

14

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

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

стол:

  • id (int)
  • some_other_id (int)
  • текст (longtext) - utf8mb4_unicode_ci ~500KB/строка среднее
  • updated_at (int)
  • created_at (int)

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

другие таблицы были не так драматичны, но это спас ~50% где есть некоторые текстовые поля. Е. Г. еще с 6,4 Гб -> 3.1 Гб с 1.5 m строк.

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

5