应用程序的整体性能、CPU 和 I/O 使用率，以及磁盘文件大小都是判断压缩对应用程序有效性的良好指标。这一节基于第17.9.1.3节，“Tuning Compression for InnoDB Tables”中的性能调整建议，并展示如何在初始测试中可能未出现的问题。

要深入了解压缩表的性能考虑，可以使用信息架构表，描述在示例17.1，“使用压缩信息架构表”中。这些表反映了内存的内部使用和总体压缩率。

INNODB_CMP 表报告了每个压缩页面大小（KEY_BLOCK_SIZE）的压缩活动信息。这些表中的信息是系统全局的：它对数据库中所有压缩表的压缩统计信息进行总结。你可以使用这个数据来帮助决定是否要压缩一个表，例如，在没有其他压缩表被访问时，可以在这些表上进行查询。服务器上的开销相对较低，因此你可能会在生产服务器上定期查询以检查压缩特性的整体效率。

INNODB_CMP_PER_INDEX 表报告了关于单个表和索引的压缩活动信息。这类信息更加 targeted 和有用，用于评估压缩效率和诊断性能问题一个表或索引一次。 (因为每个 InnoDB 表都被表示为聚簇索引，所以 MySQL 在这个上下文中不 distinction between 表和索引。) INNODB_CMP_PER_INDEX 表涉及到大量的开销，所以更适合于开发服务器，您可以在孤立的情况下比较不同 工作负载、数据和压缩设置的效果。为了防止意外地对这个监控开销，必须在查询 INNODB_CMP_PER_INDEX 表前启用 innodb_cmp_per_index_enabled 配置选项。

需要考虑的关键统计指标是压缩和解压操作的数量和时间消耗。由于MySQL在修改后将B-树节点分割，以容纳压缩后的数据，比较成功的压缩操作数与总体压缩操作数。根据INNODB_CMP和INNODB_CMP_PER_INDEX表中的信息，以及总体应用性能和硬件资源 utilization，您可能会根据硬件配置、调整缓冲池大小、选择不同的页面大小或选择不同的压缩表来进行更改。

如果压缩和解压所需的CPU时间很高，切换到更快或多核CPU可以帮助提高性能，以相同的数据、应用负载和压缩表集。增加缓冲池大小也可能会帮助性能，因为更多的未压缩页面可以留在内存中，从而减少需要解压的内存中的压缩页面。

总体来说，如果您的应用程序中有大量的压缩操作（相比于INSERT、UPDATE和DELETE操作），可能是某些已压缩表被更新太频繁，导致压缩不够有效。如果是这样，请选择更大的页面大小或更加挑选要压缩的表。

如果COMPRESS_OPS_OK（成功压缩操作）的数量占总压缩操作COMPRESS_OPS的高比例，那么系统可能正在运行良好。如果该比率较低，则MySQL可能频繁地重新组织、重新压缩和拆分B-树节点，这不是理想的情况。在这种情况下，可以避免压缩某些表，或者将KEY_BLOCK_SIZE增加到一些已压缩表中。您也可以在应用程序中出现超过1%或2%的压缩失败率时关闭对应表的压缩功能。（这种失败率可能在临时操作，如数据加载期间是可接受的。）