mysql的數據壓縮性能比較

152次閱讀

共計 2619 個字符，預計需要花費 7 分鐘才能閱讀完成。

本篇內容主要講解“mysql 的數據壓縮性能比較”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓丸趣 TV 小編來帶大家學習“mysql 的數據壓縮性能比較”吧!

1. 測試環境：
軟硬件
一臺 64 位 2.6.18-92 內核開發機，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. 測試工具：
slap
官方的工具當然是不二之選。關于 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 了。