总体应用程序性能、CPU 和 I/O 利用率以及磁盘文件的大小是衡量应用程序压缩效果的良好指标。本节基于 第 14.9.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在 B 树节点太满而无法包含修改后的压缩数据时拆分B 树节点，因此将“成功” 压缩操作的数量与此类操作的总体数量进行比较。根据 INNODB_CMP和 INNODB_CMP_PER_INDEX表中的信息以及整体应用程序性能和硬件资源利用率，您可以更改硬件配置、调整缓冲池的大小、选择不同的页面大小或选择一组不同的表进行压缩。

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

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

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