mysql的数据压缩性能对比详情

数据魔方需要的数据，一旦写入就很少或者根本不会更新。这种数据非常适合压缩以降低磁盘占用。mysql本身提供了两种压缩方式――archive引擎以及针对myisam引擎的myisampack方式。今天对这两种方式分别进行了测试，对比了二者在磁盘占用以及查询性能方面各自的优劣。至于为什么做这个，你们应该懂的，我后文还会介绍。且看正文：

1. 测试环境

1.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对测试结果造成干扰。

1.2 表结构

2424753条记录，生产环境某一个分片的实际数据；

分别建立了(partition_by1,idx_rank) 和 (partition_by1,chg_idx)的联合索引，其中 partition_by1为32长度的varchar类型，用于检索；其余两个字段均为浮点数，多用于排序；

autokid作为子增列，充当primary key，仅作为数据装载时原子性保证用，无实际意义。

2. 测试目的

2.1 压缩空间对比

压缩率越大，占用的磁盘空间越小，直接降低数据的存储成本；

2.2 查询性能对比

压缩后查询性能不应该有显著降低。archive是不支持索引的，因此性能降低是必然的，那么我们也应该心里有个谱，到底降低了多少，能不能接受。

3. 测试工具

3.1 mysqlslap

官方的工具当然是不二之选。关于mysqlslap的介绍请参考官方文档。

3.2 测试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）	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了。

到此这篇关于mysql的数据压缩性能对比详情的文章就介绍到这了,更多相关mysql的数据压缩性能对比内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com！