整体应用程序性能、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 表之前启用 innodb_cmp_per_index_enabled 配置选项。

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

如果压缩和解压缩所需的 CPU 时间过多，更改为更快的 CPU 或多核 CPU 可以帮助提高性能，前提是数据、应用程序工作负载和压缩表集保持不变。增加缓冲池的大小也可能有助于提高性能，以便更多未压缩的页面可以保留在内存中，减少对仅以压缩形式存在于内存中的页面的解压缩需求。

总的压缩操作数量（与应用程序中的 INSERT、UPDATE 和 DELETE 操作数量以及数据库大小相比）过多可能表明某些压缩表更新过于频繁，不利于有效压缩。如果是这种情况，请选择更大的页面大小，或更具选择性地选择要压缩的表。

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