Эти данные были собраны из ALTER TABLE, оператора, который вы не часто используете и который перезаписывает всю таблицу. Важна ваша повседневная рабочая нагрузка, все ВСТАВКИ и ОБНОВЛЕНИЯ, которые ваше приложение выполняет в производственной среде. Согласно руководству по MySQL:

«Вы можете отключить сжатие для таблиц, которые приводят к тому, что количество« сбоев сжатия »в вашем приложении превышает 1% или 2% от общего числа. (Такой коэффициент отказов может быть приемлемым. во время временной операции, такой как загрузка данных) "

Даже после выполнения сжатия вы все равно можете не получить требуемую производительность. Почему?

InnoDB имеет буферный пул для загрузки страниц данных и индексных страниц, прочитанных для выполнения запросов. При чтении таблицы и ее индексов в первый раз сжатая страница должна быть несжатой. Фактически, в результате этого у вас может быть вдвое больше данных в пуле буферов.

Обратите внимание на то, как это происходит из документации MySQL

Сжатие и пула буферов InnoDB

в сжатая таблица InnoDB, каждая сжатая страница (будь то 1K, 2K, 4K или 8K) соответствует несжатой странице размером 16K. Чтобы получить доступ данные на странице, InnoDB читает сжатую страницу с диска, если она еще не находится в пуле буферов, затем распаковывает страницу до ее исходная форма размером 16 Кбайт. В этом разделе описывается, как InnoDB управляет пул буферов по отношению к страницам сжатых таблиц.

Чтобы минимизировать ввод-вывод и уменьшить необходимость распаковки страницы, иногда буферный пул содержит как сжатую, так и несжатую форму страница базы данных. Чтобы освободить место для других необходимых страниц базы данных, InnoDB может «вытеснить» из пула буферов несжатую страницу, в то время как оставляя сжатую страницу в памяти. Или, если страница не была доступ через некоторое время, сжатая форма страницы может быть записана в диск, чтобы освободить место для других данных. Таким образом, в любой момент времени буферный пул может содержать как сжатые, так и несжатые формы страницу, или только сжатую форму страницы, или ни то, ни другое.

InnoDB отслеживает, какие страницы оставить в памяти, а какие удалить используя список наименее недавно использованных (LRU), так что «горячие» или часто полученные данные обычно остаются в памяти. Когда сжатые таблицы доступ, InnoDB использует адаптивный алгоритм LRU для достижения соответствующий баланс сжатых и несжатых страниц в памяти. Этот адаптивный алгоритм чувствителен к тому, работает ли система. с привязкой к вводу-выводу или ЦП. Цель - тоже не тратить много времени на обработку распаковки страниц, когда процессор занят, и Избегайте избыточного ввода-вывода, когда у ЦП есть свободные циклы, которые можно использовать для распаковки сжатых страниц (которые, возможно, уже находятся в памяти). Когда система привязана к вводу-выводу, алгоритм предпочитает исключить несжатую копию страницы, а не обе копии, чтобы освободить место чтобы другие страницы диска стали резидентными в памяти. Когда система Связанный с процессором, InnoDB предпочитает удалять как сжатые, так и сжатые файлы. несжатую страницу, чтобы можно было использовать больше памяти для «горячих» страниц и уменьшение необходимости распаковывать данные в памяти только в сжатых form.

Если это дублирование содержимого данных происходит в пуле буферов, вам необходимо увеличить innodb_buffer_pool_size на небольшой линейный коэффициент новой степени сжатия. Вот как:

СЦЕНАРИЙ

• У вас есть сервер БД с пулом буферов 8G
• Вы выполнили сжатие с key_block_size = 8
  • 8 , это 50,00% из 16
  • 50,00% из 8G составляет 4G
  • поднять innodb_buffer_pool_size до 12G ([11125 + 4G )
• Вы запустили сжатие с key_block_size = 4
  • 4 is 25,00% из 16
  • 25 .