总体应用程序性能、CPU和I/O利用率以及磁盘文件的大小都是衡量应用程序压缩效果的良好指标。本节基于15.9.1.3节，InnoDB表压缩调优，并展示了如何发现在初始测试期间可能不会出现的问题。

控件可以在运行时监视压缩性能，以深入了解压缩表的性能考虑因素信息模式表格载于例15.1，“使用压缩信息架构表”．这些表反映了内存的内部使用情况和总体使用的压缩率。

的INNODB_CMP表报告关于每个压缩页大小的压缩活动的信息(KEY_BLOCK_SIZE)在使用。这些表中的信息是系统范围的:它总结了数据库中所有压缩表的压缩统计信息。当没有其他压缩表被访问时，您可以使用这些数据来检查这些表，从而帮助决定是否压缩表。它涉及的服务器开销相对较低，因此您可以定期在生产服务器上查询它，以检查压缩特性的整体效率。

的INNODB_CMP_PER_INDEXTable报告关于各个表和索引的压缩活动的信息。这些信息对于评估压缩效率和诊断每次一个表或索引的性能问题更有针对性，也更有用。(因为每个人InnoDB表被表示为一个聚集索引，MySQL在这个上下文中没有对表和索引做很大的区分。)的INNODB_CMP_PER_INDEX表确实涉及大量开销，因此它更适合于开发服务器，在那里您可以比较不同的效果工作负载、数据和压缩设置隔离。为防止意外地施加此监视开销，必须启用innodb_cmp_per_index_enabled配置项，才能查询INNODB_CMP_PER_INDEX表格

需要考虑的关键统计数据是执行压缩和解压缩操作的次数和时间。自从MySQL分裂以来b -树当节点太满而无法包含修改后的压缩数据时，比较节点的数量”成功的”压缩操作的总数。参考资料INNODB_CMP而且INNODB_CMP_PER_INDEX表和整体应用程序性能以及硬件资源利用率，您可能会更改硬件配置，调整缓冲池的大小，选择不同的页大小，或选择要压缩的不同表集。

如果压缩和解压缩所需的CPU时间很长，那么使用更快或多核CPU可以帮助提高相同数据、应用程序工作负载和压缩表集的性能。增加缓冲池的大小也可能有助于提高性能，这样更多未压缩的页面可以留在内存中，从而减少对仅以压缩形式存在于内存中的页面进行解压缩的需要。

大量的压缩操作总体上(相比插入，更新而且删除应用程序中的操作和数据库的大小)可能表明某些压缩表的更新过于频繁，无法进行有效的压缩。如果是，请选择更大的页面大小，或者对压缩的表更有选择性。

如果”成功的”压缩操作(COMPRESS_OPS_OK)占压缩操作总数的较高百分比(COMPRESS_OPS)，则系统可能运行良好。如果这个比率很低，那么MySQL会比期望的更频繁地重组、重新压缩和分裂b树节点。在这种情况下，避免压缩某些表，或者增加KEY_BLOCK_SIZE对于某些压缩表。的数量导致的表关闭压缩”压缩失败”在你的申请中要超过总数的1%或2%。(在数据加载等临时操作期间，这样的故障率可能是可以接受的)。