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 |
