应用程序的整体性能、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 可以帮助改善性能，使用相同的数据、应用程序工作负载和压缩表集。增加缓冲池的大小也可能有助于性能，以便更多的未压缩页面可以留在内存中，减少了对内存中仅以压缩形式存在的页面的解压缩需求。

如果您的应用程序和数据库大小相比，总体 compression 操作的数量很大（与 INSERT、UPDATE 和 DELETE 操作相比），这可能表明某些压缩表被更新得太频繁，无法有效地压缩。如果是这样，请选择更大的页面大小，或者更有选择性地选择要压缩的表。

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