14.9.1.4 在运行时监视 InnoDBtable 压缩

整体应用程序性能，CPU 和 I/O 利用率以及磁盘文件的大小很好地 table 明了压缩对您的应用程序的有效性。本节以第 14.9.1.3 节“为 InnoDBtable 调整压缩”的性能调整建议为基础，并说明如何查找在初始测试期间可能不会出现的问题。

要深入了解压缩 table 的性能注意事项，您可以使用示例 14.1，“使用压缩信息模式 table”中描述的Information Schematable 在运行时监视压缩性能。这些 table 反映了内存的内部使用以及总体上使用的压缩率。

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

INNODB_CMP_PER_INDEXtable 报告有关单个 table 和索引的压缩活动的信息。此信息更有针对性，对于评估压缩效率和一次诊断一个 table 或索引的性能问题更有用。 (由于每个InnoDBtable 都 table 示为聚集索引，因此 MySQL 在这种情况下并没有在 table 和索引之间进行较大区分.)INNODB_CMP_PER_INDEXtable 确实涉及大量开销，因此它更适合于开发服务器，您可以在其中进行比较隔离不同workloads，数据和压缩设置的效果。为防止意外施加此监视开销，必须先启用innodb_cmp_per_index_enabled配置选项，然后才能查询INNODB_CMP_PER_INDEXtable。

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

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

总体上大量的压缩操作(与应用程序中INSERT，UPDATE和DELETE操作的数量以及数据库的大小相比)可能 table 明某些压缩 table 的更新量太大，无法进行有效的压缩。如果是这样，请选择更大的页面大小，或者对要压缩的 table 有更多选择。

如果“成功”压缩操作(COMPRESS_OPS_OK)的数量占压缩操作总数(COMPRESS_OPS)的高百分比，则系统可能运行良好。如果比率低，则 MySQL 会比期望的更多地重组，重新压缩和拆分 B 树节点。在这种情况下，请避免压缩某些 table，或者为某些压缩 table 增加KEY_BLOCK_SIZE。您可能会关闭对导致应用程序中“压缩失败”次数超过总数的 1％或 2％的 table 的压缩。 (这样的故障率在诸如数据加载之类的临时操作期间可能是可以接受的)。