MySQL 8.4 Release Notes
17.15.1.3 使用压缩信息架构表
示例17.1:使用压缩信息架构表
以下是来自包含压缩表的数据库的样本输出(见第17.9节,“InnoDB 表和页面压缩”,INNODB_CMP
,INNODB_CMP_PER_INDEX
,和INNODB_CMPMEM
)。
以下表格显示了INFORMATION_ SCHEMA.INNODB_CMP
下的内容,在轻微工作负载下。缓冲池中唯一的压缩页面大小是8K。由于统计数据重置时,COMPRESS_TIME
和UNCOMPRESS_TIME
列中的值为零,因此自从统计数据被重置以来,压缩或解压页面已经消耗了少于一秒。
page size | compress ops | compress ops ok | compress time | uncompress ops | uncompress time |
---|---|---|---|---|---|
1024 | 0 | 0 | 0 | 0 | 0 |
2048 | 0 | 0 | 0 | 0 | 0 |
4096 | 0 | 0 | 0 | 0 | 0 |
8192 | 1048 | 921 | 0 | 61 | 0 |
16384 | 0 | 0 | 0 | 0 | 0 |
根据INNODB_CMPMEM
,buffer pool 中有 6169 个压缩的 8KB 页。唯一其他分配的块大小是 64 字节。PAGE_SIZE
在INNODB_CMPMEM
中的最小值用于压缩页的块描述符,其中无未压缩页在 buffer pool 中存在。我们看到有 5910 个这样的页。间接地,我们看到还有 259 个(6169-5910)压缩页在 buffer pool 中以未压缩形式存在。
以下表格显示了在轻微工作负载下INFORMATION_SCHEMA.INNODB_CMPMEM
的内容。由于压缩页面内存分配器的碎片化,某些内存无法使用:SUM(PAGE_SIZE*PAGES_FREE)=6784
。这是因为小内存分配请求被满足通过将更大的块拆分成16K块,从主缓冲池中分配,这是使用buddy分配系统实现的。碎片化很低,因为一些已分配的块已经被重新定位(复制)以形成更大的相邻自由块。这次复制SUM(PAGE_SIZE*RELOCATION_OPS)
字节消耗了少于一秒:(SUM(RELOCATION_TIME)=0)
。