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

Чтобы углубиться в вопросы производительности сжатых таблиц, вы можете отслеживать производительность сжатия во время работы, используя таблицы, описанные в примере 14.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% от общего количества. (Такой показатель отказов может быть приемлем во время временных операций, таких как загрузка данных).