MySQL 數據壓縮性能對比：Archive 引擎 vs MyISAM myisampack 空間與查詢效能實測

測試背景

數據魔方業務：數據**一次寫入、極少更新**、海量歷史日志/報表。需壓縮降低存儲成本。對比兩種原生壓縮方案：

• Archive 引擎：行級壓縮（zlib），**不支援索引**（除主鍵），插入快、查詢全表掃描。
• MyISAM + myisampack：靜態壓縮（只讀），**支援全部索引類型**，查詢可走索引。

測試環境

• 硬件：4×2.8GHz Dual-Core Opteron、4GB RAM、7200 RPM SATA 單盤、無 RAID。
• MySQL：關閉 Query Cache，無其他優化。
• 數據：2,424,753 行，生產分片真實數據。聯合索引 (partition_by1, idx_rank)、(partition_by1, chg_idx)，partition_by1 VARCHAR(32) 為核心檢索鍵。
• 工具：mysqlslap 並發 50、迭代 10、7 條生產真實 SQL（含 WHERE partition_by1=?、ORDER BY added_quantity3 DESC LIMIT 500）。

測試結果

深度分析：為什麼 Archive 查詢慘敗？

核心 SQL：

SELECT ... FROM t WHERE partition_by1 = '50008090' ORDER BY added_quantity3 DESC LIMIT 500

• 基準表 / Pack 表：EXPLAIN 顯示 type=ref，用到 idx_partition_by1，**匹配 2,477 行**，再 filesort 排序。
• Archive 表：EXPLAIN 顯示 type=ALL，**全表掃描 2,424,753 行**，無索引可用，再 filesort。

Archive **不允許建立除主鍵外的任何索引**，導致核心檢索列 partition_by1 無法走索引，**全表掃描 + 排序 = 災難性性能**。

適用場景對比

InnoDB 壓縮替代方案（現代選擇）

MySQL 5.6+ InnoDB 支援 **頁面級壓縮** (ROW_FORMAT=COMPRESSED, KEY_BLOCK_SIZE=8/4/2)：

• 支援**完整索引、事務、MVCC、崩潰恢復**。
• 壓縮率通常 40-60%（視數據特性），雖不及 Archive，但**查詢性能幾乎無損**（Buffer Pool 存壓縮頁，解壓在 CPU、緩存命中率高）。
• 線上 DDL 可將現有表轉為壓縮表：ALTER TABLE t ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8;

結論：InnoDB 壓縮表是「可查詢、可更新、可事務、可壓縮」的最佳平衡點，新業務首選；Archive 僅限極少查詢的冷歸檔；MyISAM Pack 僅限遺留只讀系統維護。

結語

壓縮雖能省空間，但**索引缺失帶來的查詢性能崩塌往往得不償失**。測試證實：Archive 空間省 80%，查詢慢 100 倍；MyISAM Pack 空間省 75%，查詢性能持平基準。**InnoDB 頁面壓縮**兼顧空間與性能，是現代 MySQL 壓縮的正解。選型時務必：**先定業務查詢模式，再選壓縮方案，最後實測驗證**——不要為省幾塊硬盤錢換來全表掃描的噩夢。