數據魔方需要的數據，一旦寫入就很少或者根本不會更新。這種數據非常適合壓縮以降低磁盤占用。MySQL本身提供了兩種壓縮方式——archive引擎以及針對MyISAM引擎的myisampack方式。今天對這兩種方式分別進行了測試，對比了二者在磁盤占用以及查詢性能方面各自的優劣。至於為什麼做這個，你們應該懂的，我後文還會介紹。且看正文：
1. 測試環境：
軟硬件
一台64位2.6.18-92 內核Linux開發機，4G內存，4個2800Mhz Dual-Core AMD Opteron(tm) Processor 2220 CPU。
MySQL放在一塊7200轉SAT硬盤，未做raid；
MySQL未做任何優化，關閉了query cache，目的在於避免query cache對測試結果造成干擾。
表結構
2424753條記錄，生產環境某一個分片的實際數據；
分別建立了(partition_by1,idx_rank) 和(partition_by1,chg_idx)的聯合索引，其中partition_by1為32長度的varchar類型，用於檢索；其余兩個字段均為浮點數，多用於排序；
autokid作為子增列，充當PRIMARY KEY，僅作為數據裝載時原子性保證用，無實際意義。
2. 測試目的：
壓縮空間對比
壓縮率越大，占用的磁盤空間越小，直接降低數據的存儲成本；
查詢性能對比
壓縮後查詢性能不應該有顯著降低。Archive是不支持索引的，因此性能降低是必然的，那麼我們也應該心裡有個譜，到底降低了多少，能不能接受。
3. 測試工具：
mysqlslap
官方的工具當然是不二之選。關於mysqlslap的介紹請參考 官方文檔。
測試query
截取生產環境訪問topranks_v3表的實際SQL共9973條，從中抽取訪問量較大的7條，並發50，重復執行10次。命令如下：
./mysqlslap --defaults-file=../etc/my.cnf -u**** -p**** -c50 -i10 -q ../t.sql --debug-info4.測試結論
比較項 磁盤空間 耗時（秒）CPU Idle LOAD 並發
基准表（MyISAM）403956004 2.308 30 15 50
ARCHIVE 75630745 >300 75 4 1
PACK 99302109 2.596 30 22 50
根據上面的表格給出的測試數據，我們簡單得出以下結論：
針對測試表，Archive表占用空間約為之前的18.7%，myisampack後空間占用約為之前的24.6%；二者相差不多，單純從空間利用情況來看，我們似乎需要選擇archive表；
我們再看查詢性能，與基准表進行對比。無論在總耗時還是系統負載方面，50並發下的pack表查詢性能與基准表相當；而archive表在單並發情況下耗時超過了5分鐘（實在等不了了，kill之）！
那麼，我們似乎可以得出結論，針對需要在線查詢的表，ARCHIVE引擎基本上可以不考慮了。
為什麼這個測試過程中ARCHIVE引擎如此地慢呢？
我們知道，mysql提供archive這種存儲引擎是為了降低磁盤開銷，但還有一個前提，那就是被歸檔的數據不需要或者很少被在線查詢，偶爾的查詢慢一些也是沒關系的。鑒於上述原因，archive表是不允許建立自增列之外的索引的。
有了這個共識，我們拿一條測試SQL來分析一下不用索引前後的查詢性能差別為什麼這麼大。在我們的測試SQL中有這麼一條：
SELECT c1,c2,...,cn FROM mysqlslap.rpt_topranks_v3
WHERE ... AND partition_by1 = '50008090'
ORDER BY added_quantity3 DESC
LIMIT 500我們前邊說過，測試的這個表在partition_by1這個字段上建立了索引，那麼，我們初步判斷在基准表和myisampack表上，這個查詢應該用到了partition_by1的索引；EXPLAIN一下：
mysql> EXPLAIN
-> SELECT ... FROM mysqlslap.rpt_topranks_v3
-> WHERE ... AND partition_by1 = '50008090'
-> ORDER BY added_quantity3 DESC
-> LIMIT 500\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
TABLE: rpt_topranks_v3
type: ref
possible_keys: idx_toprank_pid,idx_toprank_chg
KEY: idx_toprank_pid
key_len: 99
ref: const
rows: 2477
Extra: USING WHERE; USING filesort
1 row IN SET (0.00 sec)正如我們所料，這個查詢用到了建立在partition_by1這個字段上的索引，匹配的目標行數為2477，然後還有一個在added_quantity3字段上的排序。由於added_quantity3沒有索引，所以用到了filesort。
我們再看一下這條SQL在歸檔表上的EXPLAIN結果：
mysql> EXPLAIN
-> SELECT ... FROM mysqlslap.rpt_topranks_v3_<strong>archive</strong>
-> WHERE ... AND partition_by1 = '50008090'
-> ORDER BY added_quantity3 DESC
-> LIMIT 500\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
TABLE: rpt_topranks_v3_archive
type: ALL
possible_keys: NULL
KEY: NULL
key_len: NULL
ref: NULL
rows: 2424753
Extra: USING WHERE; USING filesort
1 row IN SET (0.00 sec)EXPLAIN說：“我沒有索引可用，所以只能全表掃描2424753行記錄，然後再來個filesort。”你要追求性能，那顯然是委屈MySQL了。
擴展閱讀：http://www.BkJia.com/database/201202/120001.html
