• 首页
  • vue
  • TypeScript
  • JavaScript
  • scss
  • css3
  • html5
  • php
  • MySQL
  • redis
  • jQuery
  • 在运行时监视InnoDB表压缩

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

    要深入了解压缩表的性能注意事项,可以使用示例15.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_CMPINNODB_CMP_PER_INDEX表,整体应用程序性能以及硬件资源利用率,您可以更改硬件配置,调整缓冲池的大小,选择其他页面大小或选择其他表进行压缩。

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

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

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