mysql中如何進行數(shù)據(jù)壓縮性能對比

這篇文章給大家分享的是有關(guān)mysql中如何進行數(shù)據(jù)壓縮性能對比的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

1. 測試環(huán)境

1.1 軟硬件

一臺 64位 2.6.18-92 內(nèi)核Linux開發(fā)機，4G內(nèi)存，4個2800Mhz Dual-Core AMD Opteron(tm) Processor 2220 CPU。

MySQL放在一塊7200轉(zhuǎn)SAT硬盤，未做raid；

MySQL未做任何優(yōu)化， 關(guān)閉了query cache ，目的在于避免query cache對測試結(jié)果造成干擾。

1.2 表結(jié)構(gòu)

2424753條記錄，生產(chǎn)環(huán)境某一個分片的實際數(shù)據(jù)；

分別建立了(partition_by1,idx_rank) 和 (partition_by1,chg_idx)的聯(lián)合索引，其中 partition_by1為32長度的varchar類型 ，用于檢索；其余兩個字段均為浮點數(shù)，多用于排序；

autokid作為子增列，充當(dāng)PRIMARY KEY，僅作為數(shù)據(jù)裝載時原子性保證用，無實際意義。

2. 測試目的

2.1 壓縮空間對比

壓縮率越大，占用的磁盤空間越小，直接降低數(shù)據(jù)的存儲成本；

2.2 查詢性能對比

壓縮后查詢性能不應(yīng)該有顯著降低。Archive是不支持索引的，因此性能降低是必然的，那么我們也應(yīng)該心里有個譜，到底降低了多少，能不能接受。

3. 測試工具

3.1 mysqlslap

官方的工具當(dāng)然是不二之選。關(guān)于mysqlslap的介紹請參考 官方文檔 。

3.2 測試query

截取生產(chǎn)環(huán)境訪問topranks_v3表的實際SQL共9973條，從中抽取訪問量較大的7條，并發(fā)50，重復(fù)執(zhí)行10次。命令如下：

./mysqlslap --defaults-file=../etc/my.cnf -u**** -p**** -c50 -i10 -q ../t.sql --debug-info

4.測試結(jié)論

根據(jù)上面的表格給出的測試數(shù)據(jù)，我們簡單得出以下結(jié)論：

• 針對測試表，Archive表占用空間約為之前的18.7%，myisampack后空間占用約為之前的24.6%；二者相差不多，單純從空間利用情況來看，我們似乎需要選擇archive表；

• 我們再看查詢性能，與基準(zhǔn)表進行對比。無論在總耗時還是系統(tǒng)負載方面，50并發(fā)下的pack表查詢性能與基準(zhǔn)表相當(dāng)； 而archive表在單并發(fā)情況下耗時超過了5分鐘 （實在等不了了，kill之）！

那么，我們似乎可以得出結(jié)論，針對需要在線查詢的表，ARCHIVE引擎基本上可以不考慮了。

為什么這個測試過程中ARCHIVE引擎如此地慢呢？

我們知道，mysql提供archive這種存儲引擎是為了降低磁盤開銷，但還有一個前提，那就是被歸檔的數(shù)據(jù)不需要或者很少被在線查詢，偶爾的查詢慢一些也是沒關(guān)系的。鑒于上述原因，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這個字段上建立了索引，那么，我們初步判斷在基準(zhǔn)表和myisampack表上，這個查詢應(yīng)該用到了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這個字段上的索引，匹配的目標(biāo)行數(shù)為2477，然后還有一個在added_quantity3字段上的排序。由于added_quantity3沒有索引，所以用到了filesort。

我們再看一下這條SQL在歸檔表上的 EXPLAIN 結(jié)果：

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了。

感謝各位的閱讀！關(guān)于“mysql中如何進行數(shù)據(jù)壓縮性能對比”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學(xué)到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！