真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

成都創(chuàng)新互聯(lián)網(wǎng)站制作重慶分公司

mysql的數(shù)據(jù)壓縮性能比較

本篇內(nèi)容主要講解“MySQL的數(shù)據(jù)壓縮性能比較”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“mysql的數(shù)據(jù)壓縮性能比較”吧!

目前成都創(chuàng)新互聯(lián)公司已為上千多家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)絡(luò)空間、網(wǎng)站托管、服務(wù)器租用、企業(yè)網(wǎng)站設(shè)計(jì)、羅定網(wǎng)站維護(hù)等服務(wù),公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略,正道將秉承"和諧、參與、激情"的文化,與客戶和合作伙伴齊心協(xié)力一起成長,共同發(fā)展。


 
1. 測試環(huán)境:
軟硬件
一臺64位2.6.18-92 內(nèi)核開發(fā)機(jī),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é)果造成干擾。
 
表結(jié)構(gòu)
2424753條記錄,生產(chǎn)環(huán)境某一個分片的實(shí)際數(shù)據(jù);
 
分別建立了(partition_by1,idx_rank) 和(partition_by1,chg_idx)的聯(lián)合索引,其中partition_by1為32長度的varchar類型,用于檢索;其余兩個字段均為浮點(diǎn)數(shù),多用于排序;
 
autokid作為子增列,充當(dāng)PRIMARY KEY,僅作為數(shù)據(jù)裝載時原子性保證用,無實(shí)際意義。
 
2. 測試目的:
壓縮空間對比
壓縮率越大,占用的磁盤空間越小,直接降低數(shù)據(jù)的存儲成本;
 
查詢性能對比
壓縮后查詢性能不應(yīng)該有顯著降低。Archive是不支持索引的,因此性能降低是必然的,那么我們也應(yīng)該心里有個譜,到底降低了多少,能不能接受。
 
3. 測試工具:
slap
官方的工具當(dāng)然是不二之選。關(guān)于mysqlslap的介紹請參考 官方文檔。
 
測試query
截取生產(chǎn)環(huán)境訪問topranks_v3表的實(shí)際SQL共9973條,從中抽取訪問量較大的7條,并發(fā)50,重復(fù)執(zhí)行10次。命令如下:
 
./mysqlslap --defaults-file=../etc/my.cnf -u**** -p**** -c50 -i10 -q ../t.sql --debug-info4.測試結(jié)論
 
比較項(xiàng) 磁盤空間 耗時(秒)CPU Idle LOAD 并發(fā)
基準(zhǔn)表(MyISAM)403956004 2.308 30 15 50
ARCHIVE 75630745 >300 75 4 1
PACK 99302109 2.596 30 22 50
 
根據(jù)上面的表格給出的測試數(shù)據(jù),我們簡單得出以下結(jié)論:
 
針對測試表,Archive表占用空間約為之前的18.7%,myisampack后空間占用約為之前的24.6%;二者相差不多,單純從空間利用情況來看,我們似乎需要選擇archive表;
我們再看查詢性能,與基準(zhǔn)表進(jìn)行對比。無論在總耗時還是系統(tǒng)負(fù)載方面,50并發(fā)下的pack表查詢性能與基準(zhǔn)表相當(dāng);而archive表在單并發(fā)情況下耗時超過了5分鐘(實(shí)在等不了了,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_archive
    -> 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了。
 

到此,相信大家對“mysql的數(shù)據(jù)壓縮性能比較”有了更深的了解,不妨來實(shí)際操作一番吧!這里是創(chuàng)新互聯(lián)網(wǎng)站,更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢,關(guān)注我們,繼續(xù)學(xué)習(xí)!


網(wǎng)站標(biāo)題:mysql的數(shù)據(jù)壓縮性能比較
URL標(biāo)題:http://weahome.cn/article/gejeid.html

其他資訊

在線咨詢

微信咨詢

電話咨詢

028-86922220(工作日)

18980820575(7×24)

提交需求

返回頂部