Общая производительность приложения, использование ЦП и ввода-вывода, а также размер файлов на диске являются хорошими показателями эффективности сжатия для вашего приложения. Этот раздел опирается на рекомендации по настройке производительности из раздела 17.9.1.3 «Настройка сжатия для таблиц InnoDB» и показывает, как находить проблемы, которые могут не проявляться во время начальных тестов.

Чтобы углубиться в вопросы производительности сжатых таблиц, вы можете отслеживать производительность сжатия во время выполнения, используя таблицы, описанные в примере 17.1 «Использование таблиц информации схемы сжатия». Эти таблицы отражают внутреннее использование памяти и общие скорости сжатия.

Таблица INNODB_CMP содержит информацию о работе сжатия для каждого размера страницы сжатия (KEY_BLOCK_SIZE), используемого в данный момент. Информация в этих таблицах относится ко всему серверу: она суммирует статистику сжатия по всем сжатым таблицам в вашей базе данных. Вы можете использовать эти данные, чтобы решить, следует ли сжимать таблицу, проверяя эти таблицы, когда к другим сжатым таблицам нет доступа. Это влечёт за собой относительно низкую нагрузку на сервер, поэтому вы можете периодически запросить её на сервере в режиме работы для проверки общей эффективности функции сжатия.

Таблица INNODB_CMP_PER_INDEX содержит информацию о работе сжатия для отдельных таблиц и индексов. Эта информация более целенаправленная и более полезна для оценки эффективности сжатия и диагностики проблем производительности для одной таблицы или индекса за раз. (Так как каждая InnoDB таблица представлена как кластеризованный индекс, MySQL не делает большого различия между таблицами и индексами в этом контексте.) Таблица INNODB_CMP_PER_INDEX требует значительной нагрузки, поэтому она больше подходит для серверов разработки, где вы можете сравнить эффекты различных настроек данных и сжатия в изоляции. Чтобы избежать случайной установки этого мониторинга, вы должны включить параметр конфигурации innodb_cmp_per_index_enabled, прежде чем вы сможете запросить таблицу INNODB_CMP_PER_INDEX.

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

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

Большое количество операций сжатия в целом (по сравнению с количеством INSERT, UPDATE и DELETE операций в вашем приложении и размером базы данных) может указывать на то, что некоторые из ваших сжатых таблиц обновляются слишком часто для эффективного сжатия. В этом случае выберите больший размер страницы или более избирательно подходите к выбору таблиц для сжатия.

Если количество успешных операций сжатия (COMPRESS_OPS_OK) составляет высокий процент от общего количества операций сжатия (COMPRESS_OPS), то система, вероятно, работает хорошо. Если соотношение низкое, MySQL часто переупорядочивает, пересжимает и разделяет узлы дерева B, что нежелательно. В этом случае избегайте сжатия некоторых таблиц или увеличьте KEY_BLOCK_SIZE для некоторых сжатых таблиц. Вы можете отключить сжатие для таблиц, которые приводят к тому, что количество ошибок сжатия в вашем приложении превышает 1% или 2% от общего числа. (Такое соотношение ошибок может быть приемлемым во время временной операции, например, загрузки данных).