整体应用程序性能、CPU 和 I/O 利用率以及磁盘文件的大小是衡量应用程序压缩效果的良好指标。

INNODB_CMP表报告有关每个正在使用的压缩页面大小的压缩活动的信息。这些表中的信息是系统范围的：它汇总了数据库中所有压缩表的压缩统计信息。当没有其他压缩表被访问时，您可以通过检查这些表来帮助决定是否压缩表。它在服务器上的开销相对较低，因此您可以在生产服务器上定期查询它以检查压缩功能的整体效率。

INNODB_CMP_PER_INDEX表报告有关各个表和索引的压缩活动的信息。此信息更有针对性，对于一次评估压缩效率和诊断一个表或索引的性能问题更有用。（因为每张InnoDB表都表示为一个聚集索引，所以MySQL在这种情况下并没有对表和索引做大的区分。） INNODB_CMP_PER_INDEX表涉及到相当大的开销，所以更适合开发服务器，可以对比效果不同的工作负载、数据和压缩设置。为防止意外施加此监视开销，您必须先启用 innodb_cmp_per_index_enabled 配置选项，然后才能查询 INNODB_CMP_PER_INDEX表。

要考虑的关键统计数据是执行压缩和解压缩操作的数量和时间量。由于 MySQL会在B-tree 节点太满而无法包含修改后的压缩数据时对其进行拆分，因此将“成功”压缩操作的数量与此类操作的总体数量进行比较。根据 INNODB_CMP、INNODB_CMP_PER_INDEX表和整体应用程序性能和硬件资源利用率，您可以更改硬件配置，调整缓冲池的大小，选择不同的页面大小，或选择不同的表集进行压缩。

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

总体上大量的压缩操作（与应用程序中的INSERT、 UPDATE和DELETE 操作的数量以及数据库的大小相比）可能表明您的某些压缩表被过度更新而无法进行有效压缩。如果是这样，请选择更大的页面大小，或者对压缩哪些表更有选择性。

如果“成功”的压缩操作数 ( COMPRESS_OPS_OK) 在压缩操作总数 ( COMPRESS_OPS) 中占很大比例，则系统可能运行良好。如果该比率较低，则 MySQL 重组、重新压缩和拆分 B 树节点的频率超出了预期。在这种情况下，避免压缩一些表，或者增加一些压缩表的KEY_BLOCK_SIZE。您可能会关闭导致“压缩失败”次数过高的表的压缩。（在数据加载等临时操作期间，这样的故障率可能是可以接受的）。