14.16.1.3 使用压缩信息架构 table
示例 14.1 使用压缩信息架构 table
以下是包含压缩 table(请参见第 14.9 节“ InnoDBtable 和页面压缩”,INNODB_CMP,INNODB_CMP_PER_INDEX和INNODB_CMPMEM)的数据库的示例输出。
下 table 显示了workload灯光下INFORMATION_SCHEMA.INNODB_CMP的内容。缓冲池包含的唯一压缩页面大小是 8K。自从重置统计信息以来,压缩或解压缩页面所花费的时间不到一秒钟,因为列COMPRESS_TIME
和UNCOMPRESS_TIME
为零。
page size | compress ops | 压缩操作确定 | 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 个字节。 INNODB_CMPMEM中最小的PAGE_SIZE
用于那些缓冲池中不存在未压缩页面的压缩页面的块 Descriptors。我们看到有 5910 个此类页面。间接地,我们看到 259(6169-5910)压缩页也以未压缩形式存在于缓冲池中。
下 table 显示了workload灯光下INFORMATION_SCHEMA.INNODB_CMPMEM的内容。由于SUM(PAGE_SIZE*PAGES_FREE)=6784
压缩页的内存分配器碎片,某些内存无法使用。这是因为使用伙伴分配系统通过从较大的块(从主缓冲池分配的 16K 块开始)开始拆分较大的块来满足较小的内存分配请求。由于某些已分配的块已重定位(复制)以形成更大的相邻可用块,因此碎片化程度如此之低。 SUM(PAGE_SIZE*RELOCATION_OPS)
个字节的复制消耗的时间少于第二个(SUM(RELOCATION_TIME)=0)
。
page size | pages used | pages free | relocation ops | relocation time |
---|---|---|---|---|
64 | 5910 | 0 | 2436 | 0 |
128 | 0 | 1 | 0 | 0 |
256 | 0 | 0 | 0 | 0 |
512 | 0 | 1 | 0 | 0 |
1024 | 0 | 0 | 0 | 0 |
2048 | 0 | 1 | 0 | 0 |
4096 | 0 | 1 | 0 | 0 |
8192 | 6169 | 0 | 5 | 0 |
16384 | 0 | 0 | 0 | 0 |