Чаще всего, внутренняя оптимизация, описанная в Разделе 5.4.6.5, "Хранение данных InnoDB и Сжатие" гарантируют, что система работает хорошо со сжатыми данными. Однако, потому что эффективность сжатия зависит от природы Ваших данных, можно принять решения, которые влияют на производительность сжатых таблиц:

Используйте направляющие линии в этом разделе, чтобы помочь сделать тот архитектурный выбор и варианты конфигурации. Когда Вы готовы провести длительный срок, тестируя и поместить сжатые таблицы в производство, см. Раздел 5.4.6.4, "Контролируя Сжатие во Времени выполнения" для способов проверить эффективность тех вариантов при реальных условиях.

Когда Использовать Сжатие

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

Характеристики данных и Сжатие

Ключевой детерминант эффективности сжатия в сокращении размера файлов данных является природой данных непосредственно. Вспомните, что сжатие работает, идентифицируя повторные строки байтов в блоке данных. Полностью рандомизированные данные являются худшим случаем. Типичные данные часто повторяли значения, и так сжатия эффективно. Символьные строки часто сжимаются хорошо, определенный ли в CHAR, VARCHAR, TEXT или BLOB столбцы. С другой стороны таблицы, содержащие главным образом двоичных данных (целые числа или числа с плавающей точкой) или данные, которые ранее сжимаются (например JPEG или изображения PNG), возможно, не обычно сжимаются хорошо, значительно или вообще.

Вы выбираете, включить ли сжатие для каждой таблицы InnoDB. Таблица и весь индексируют использование тот же самый (сжатый) размер страницы. Могло бы случиться так, что (кластеризируемый) первичный ключ индексирует, который содержит данные для всех столбцов таблицы, сжатия эффективнее, чем вторичное устройство индексирует. Для тех случаев, где есть длинные строки, использование сжатия могло бы привести к длинным значениям столбцов, сохраненным "вне страницы", как обсуждено в Разделе 5.4.8.3,"DYNAMIC и COMPRESSED Форматы строки". Те страницы переполнения могут сжаться хорошо. Уделенный это внимание, для многих приложений, некоторые таблицы сжимается эффективнее чем другие, и Вы могли бы найти, что Ваша рабочая нагрузка выполняет лучше всего только с подмножеством сжатых таблиц.

Чтобы определить, сжать ли определенную таблицу, проведите эксперименты. Можно получить грубую оценку того, как эффективно Ваши данные могут быть сжаты при использовании утилиты, которая реализует сжатие LZ77 (такой как gzip или WinZip) на копии.ibd файла для несжатой таблицы. Можно ожидать меньше сжатия от MySQL сжатая таблица чем от основанных на файле инструментов сжатия, потому что MySQL сжимает данные в блоках, основанных на размере страницы, 16 Кбит по умолчанию. В дополнение к пользовательским данным формат страницы включает некоторые внутренние системные данные, которые не сжимаются. Основанные на файле утилиты сжатия могут исследовать намного большие блоки данных, и так могли бы найти более повторные строки в огромном файле, чем MySQL может найти в отдельной странице.

Другой способ протестировать сжатие на определенной таблице состоит в том, чтобы скопировать некоторые данные от Вашей несжатой таблицы до подобной, сжатой таблицы (имеющий, все равно индексирует), и смотрите на размер получающегося .ibd файл. Например:

use test;set global innodb_file_per_table=1;set global innodb_file_format=Barracuda;set global autocommit=0;-- Create an uncompressed table with a million or two rows.create table big_table as select * from information_schema.columns;insert into big_table select * from big_table;insert into big_table select * from big_table;insert into big_table select * from big_table;insert into big_table select * from big_table;insert into big_table select * from big_table;insert into big_table select * from big_table;insert into big_table select * from big_table;insert into big_table select * from big_table;insert into big_table select * from big_table;insert into big_table select * from big_table;commit;alter table big_table add id int unsigned not null primary key auto_increment;show create table big_table\Gselect count(id) from big_table;-- Check how much space is needed for the uncompressed table.\! ls -l data/test/big_table.ibdcreate table key_block_size_4 like big_table;alter table key_block_size_4 key_block_size=4 row_format=compressed;insert into key_block_size_4 select * from big_table;commit;-- Check how much space is needed for a compressed table-- with particular compression settings.\! ls -l data/test/key_block_size_4.ibd		

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

-rw-rw----  1 cirrus  staff  310378496 Jan  9 13:44 data/test/big_table.ibd-rw-rw----  1 cirrus  staff  83886080 Jan  9 15:10 data/test/key_block_size_4.ibd

Видеть, эффективно ли сжатие для Вашей определенной рабочей нагрузки:

Сжатие базы данных против Сжатия Приложения

Решите, сжать ли данные в Вашем приложении или в таблице; не используйте оба типа сжатия для тех же самых данных. Когда Вы сжимаете данные в приложении и храните результаты в сжатой таблице, сбережения дополнительного пространства крайне маловероятны, и двойное сжатие только тратит впустую циклы ЦП.

Сжатие в Базе данных

Когда включено, табличное сжатие MySQL является автоматическим и применяется ко всем столбцам, и индексируйте значения. Столбцы могут все еще быть протестированы с операторами такой как LIKE, и операции вида могут все еще использовать, индексирует, даже когда индексировать значения сжимаются. Поскольку индексирует, часто существенная часть полного размера базы данных, сжатие могло привести к существенным сбережениям в хранении, вводе-выводе или процессорное время. Операции сжатия и распаковки происходят на сервере базы данных, который, вероятно, является мощной системой, которая измеряется, чтобы обработать ожидаемую загрузку.

Сжатие в Приложении

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

Гибридный подход

Конечно, возможно объединить эти подходы. Для некоторых приложений может быть уместно использовать некоторые сжатые таблицы и некоторые несжатые таблицы. Это может быть лучшим внешне сжать некоторые данные (и сохранить это в несжатых таблицах) и позволить MySQL сжимать (часть из) другие таблицы в приложении. Как всегда, искренний проект и реальное тестирование ценны в достижении правильного решения.

Характеристики рабочей нагрузки и Сжатие

В дополнение к выбору, какие таблицы сжаться (и размер страницы), рабочая нагрузка является другим ключевым детерминантом производительности. Если приложение во власти чтений, а не обновлений, меньше страниц должно быть реорганизовано и повторно сжато после того, как индексная страница исчерпывает комнату для "журнала модификации на страницу", который MySQL поддерживает для сжатых данных. Если обновления преобладающе изменяют неиндексированные столбцы или тех, которые содержат BLOBs или большие строки, которые, оказывается, сохранены "вне страницы", издержки сжатия могут быть приемлемыми. Если единственные изменения к таблице INSERTs, которые используют монотонно увеличивающийся первичный ключ, и есть, немногие вторичные индексируют, есть небольшая потребность реорганизовать и повторно сжать индексные страницы. Так как MySQL может "удалять-метка" и удалять строки на сжатых страницах "на месте", изменяя несжатые данные, DELETE операции на таблице относительно эффективны.

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

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

Характеристики конфигурации и Сжатие

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

Это - часто особенно случай, работая в многопользовательской среде с быстрыми, многожильными ЦП. Когда страница сжатой таблицы находится в памяти, MySQL часто использует дополнительную память, обычно 16 Кбит, в пуле буферов для несжатой копии страницы. Адаптивный алгоритм LRU пытается сбалансировать использование памяти между сжатыми и несжатыми страницами, чтобы принять во внимание, работает ли рабочая нагрузка в I/O-bound или ограниченном ЦП способе. Однако, конфигурация с большим количеством памяти, выделенной пулу буферов, имеет тенденцию работать лучше при использовании сжатых таблиц чем конфигурация, где память чрезвычайно ограничивается.

Выбор Сжатого Размера страницы

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

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

Как правило, Вы устанавливаете сжатый размер страницы в 8 K или 4 K байтов., Учитывая, что максимальный размер строки для таблицы InnoDB составляет приблизительно 8 k, KEY_BLOCK_SIZE=8 обычно безопасный выбор.