資料魔方需要的資料，一旦寫入就很少或者根本不會更新。這種資料非常適合壓縮以降低磁碟占用。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-info
4.測試結論
比較項磁碟空間
耗時(秒)
cpu idle
load
併發基準表(myisam)
2.308
archive
>300
pack
2.596
根據上面的**給出的測試資料，我們簡單得出以下結論：
針對測試表，archive表占用空間約為之前的18.7%，myisampack後空間占用約為之前的24.6%；二者相差不多，單純從空間利用情況來看，我們似乎需要選擇archive表；
我們再看查詢效能，與基準表進行對比。無論在總耗時還是系統負載方面，50併發下的pack表查詢效能與基準表相當；而archive表在單併發情況下耗時超過了5分鐘(實在等不了了，kill之)！
為什麼這個測試過程中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了。
MySQL5 6 開啟表資料壓縮
mysql5.6 開啟表壓縮，需要確保例項有如下配置 set global innodb file per table 1 setglobal innodb file format barracuda 在建立表的時候，指定row format compressed，即可。如果是針對現有表結構進行壓縮...
mysql的資料壓縮效能對比
資料魔方需要的資料，一旦寫入就很少或者根本不會更新。這種資料非常適合壓縮以降低磁碟占用。mysql本身提供了兩種壓縮方式 archive引擎以及針對myisam引擎的myisampack方式。今天對這兩種方式分別進行了測試，對比了二者在磁碟占用以及查詢效能方面各自的優劣。至於為什麼做這個，你們應該懂...
ASIHTTPRequest 資料壓縮
從0.9版本開始，asihttprequest會提示伺服器它可以接收gzip壓縮過的資料。apache 2.x以上版本已經配備了mod deflate擴充套件，這使得apache可以透明地壓縮特定種類的資料。要開啟這個特性，你需要在apache的配置檔案中啟用mod deflate。並將mod de...