MySQL 9.0 版本資訊
範例 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)。