MySQL 8.4 发行说明
示例 17.1 使用压缩信息架构表
以下是包含压缩表的数据库的示例输出（请参阅 第 17.9 节 “InnoDB 表和页面压缩”、INNODB_CMP、INNODB_CMP_PER_INDEX 和 INNODB_CMPMEM）。
下表显示了轻度 工作负载 下 INFORMATION_SCHEMA.INNODB_CMP 的内容。缓冲池中包含的唯一压缩页面大小为 8K。自统计信息重置以来，压缩或解压缩页面所花费的时间不到一秒，因为列 COMPRESS_TIME 和 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，缓冲池 中有 6169 个压缩的 8KB 页面。唯一其他分配的块大小为 64 字节。INNODB_CMPMEM 中最小的 PAGE_SIZE 用于那些在缓冲池中不存在未压缩页面的压缩页面的块描述符。我们看到有 5910 个这样的页面。间接地，我们看到 259 (6169-5910) 个压缩页面也以未压缩的形式存在于缓冲池中。
下表显示了轻度 工作负载 下 INFORMATION_SCHEMA.INNODB_CMPMEM 的内容。由于压缩页面内存分配器的碎片，某些内存不可用：SUM(PAGE_SIZE*PAGES_FREE)=6784。这是因为小的内存分配请求是通过拆分更大的块来满足的，从主缓冲池分配的 16K 块开始，使用伙伴分配系统。碎片率如此之低是因为一些已分配的块已被重新定位（复制）以形成更大的相邻空闲块。复制 SUM(PAGE_SIZE*RELOCATION_OPS) 字节所花费的时间不到一秒 (SUM(RELOCATION_TIME)=0)。