整體應用程式效能、CPU 和 I/O 使用率以及磁碟檔案的大小，都是評估壓縮對您的應用程式有多有效的好指標。本節以第 17.9.1.3 節「調整 InnoDB 表格的壓縮」的效能調整建議為基礎，並展示如何找出在初始測試期間可能不會出現的問題。

若要深入探討壓縮表格的效能考量，您可以使用資訊綱要表格（如範例 17.1「使用壓縮資訊綱要表格」中所述）在執行期間監控壓縮效能。這些表格反映了記憶體的內部使用情況和整體使用的壓縮率。

INNODB_CMP表格會報告每個使用的壓縮頁面大小 (KEY_BLOCK_SIZE) 的壓縮活動相關資訊。這些表格中的資訊是系統範圍的：它會摘要資料庫中所有壓縮表格的壓縮統計資料。當未存取其他壓縮表格時，您可以檢閱這些表格，以協助判斷是否要壓縮表格。它在伺服器上的負擔相對較低，因此您可能會定期在生產伺服器上查詢它，以檢查壓縮功能的整體效率。

INNODB_CMP_PER_INDEX表格會報告個別表格和索引的壓縮活動相關資訊。此資訊更具針對性，更適用於一次評估一個表格或索引的壓縮效率和診斷效能問題。（因為每個 InnoDB 表格都以叢集索引表示，因此 MySQL 在此內容中不會區分表格和索引。）INNODB_CMP_PER_INDEX 表格會產生大量負擔，因此更適合用於開發伺服器，您可以在其中隔離比較不同工作負載、資料和壓縮設定的效果。為了避免意外施加此監控負擔，您必須啟用 innodb_cmp_per_index_enabled 設定選項，才能查詢 INNODB_CMP_PER_INDEX 表格。

要考慮的關鍵統計資料是壓縮和解壓縮作業的次數和花費的時間。由於 MySQL 會在 B 樹節點太滿而無法包含修改後的壓縮資料時分割它們，請比較「成功」壓縮作業的次數與此類作業的整體次數。根據 INNODB_CMP 和 INNODB_CMP_PER_INDEX 表格中的資訊，以及整體應用程式效能和硬體資源利用率，您可能會變更硬體設定、調整緩衝池大小、選擇不同的頁面大小，或選取不同的表格集進行壓縮。

如果壓縮和解壓縮所需的 CPU 時間很高，改用速度更快或多核心的 CPU 可以幫助在相同的資料、應用程式工作負載和一組壓縮表格下提升效能。增加緩衝池的大小也可能有所幫助，這樣可以讓更多未壓縮的頁面保留在記憶體中，減少對僅以壓縮形式存在於記憶體中的頁面進行解壓縮的需求。

大量的壓縮操作（相較於您的應用程式中的 INSERT、UPDATE 和 DELETE 操作的數量以及資料庫的大小而言）可能表示您的一些壓縮表格的更新頻率過高，以至於壓縮效果不佳。如果是這樣，請選擇更大的頁面大小，或更慎重地選擇要壓縮的表格。

如果 「成功」的壓縮操作次數（COMPRESS_OPS_OK）佔總壓縮操作次數（COMPRESS_OPS）的比例很高，那麼系統很可能運作良好。如果這個比例很低，則表示 MySQL 正在重新組織、重新壓縮和分割 B 樹節點的頻率高於理想值。在這種情況下，請避免壓縮某些表格，或者為某些壓縮表格增加 KEY_BLOCK_SIZE。您可以針對那些導致應用程式中 「壓縮失敗」次數超過總數的 1% 或 2% 的表格關閉壓縮功能。（在臨時操作（例如資料載入）期間，這樣的失敗率可能是可以接受的）。