整体应用程序性能、CPU 和 I/O 利用率以及磁盘文件大小是衡量压缩对应用程序有效性的良好指标。本节基于第 17.9.1.3 节“调整 InnoDB 表的压缩”中的性能调优建议，并展示如何查找在初始测试期间可能不会出现的问 题。

要更深入地了解压缩表的性能注意事项，您可以使用信息模式表监控运行时的压缩性能，如示例 17.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 树 节点太大而无法容纳压缩数据时会拆分它们，因此请将“成功”压缩操作的数量与此类操作的总数进行比较。根据 INNODB_CMP 和 INNODB_CMP_PER_INDEX 表中的信息以及整体应用程序性能和硬件资源利用率，您可能会更改硬件配置、调整缓冲池的大小、选择不同的页面大小或选择不同的表集进行压缩。

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

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

如果““成功””压缩操作（COMPRESS_OPS_OK）的数量占压缩操作总数（COMPRESS_OPS）的百分比较高，则表明系统可能运行良好。如果该比率较低，则 MySQL 正在以高于预期频率地重新组织、重新压缩和拆分 B 树节点。在这种情况下，请避免压缩某些表，或者增加某些压缩表的 KEY_BLOCK_SIZE。您可能会对导致应用程序中““压缩失败””数量超过总数 1% 或 2% 的表关闭压缩。（在数据加载等临时操作期间，此类失败率可能是可以接受的）。