資料魔方需要的資料，一旦寫入就很少或者根本不會更新。這種資料非常適合壓縮以降低磁碟占用。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: ******
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_archive
-> where ... and partition_by1 = '50008090'
-> order by added_quantity3 desc
-> limit 500\g
*************************** 1. row ***************************
id: 1
select_type: ******
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了。
擴充套件閱讀：
mysql 資料壓縮 mysql的資料壓縮效能對比
資料魔方需要的資料，一旦寫入就很少或者根本不會更新。這種資料非常適合壓縮以降低磁碟占用。mysql本身提供了兩種壓縮方式 archive引擎以及針對myisam引擎的myisampack方式。今天對這兩種方式分別進行了測試，對比了二者在磁碟占用以及查詢效能方面各自的優劣。至於為什麼做這個，你們應該懂...
Solr與MySQL查詢效能對比
測試資料量 10407608 num docs 10407608 在專案中乙個最常用的查詢，查詢某段時間內的資料，sql查詢獲取資料，30s左右 select from tf hotspotdata copy test where collecttime between 2014 12 06 00 ...
MySQL批量更新（下 效能對比
前面寫了批量更新的上篇 四種實現方式，本節對他們的效能進行測試。本次測試 方法一 case 指令 效能 方法二 join update 效能 可以看出join的方式效能優於case 通過explain 我們可以看出兩種批量更新效能差距的背後原理 方法一id select type table par...