共计 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 了。
到此，相信大家对“mysql 的数据压缩性能比较”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
