这篇文章给大家分享的是有关mysql中如何进行数据压缩性能对比的内容。小编觉得挺实用的，因此分享给大家做个参考，一起跟随小编过来看看吧。
一台 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对测试结果造成干扰。
2424753条记录，生产环境某一个分片的实际数据；
分别建立了(partition_by1,idx_rank) 和 (partition_by1,chg_idx)的联合索引，其中 partition_by1为32长度的varchar类型 ，用于检索；其余两个字段均为浮点数，多用于排序；
autokid作为子增列，充当PRIMARY KEY，仅作为数据装载时原子性保证用，无实际意义。
压缩率越大，占用的磁盘空间越小，直接降低数据的存储成本；
压缩后查询性能不应该有显著降低。Archive是不支持索引的，因此性能降低是必然的，那么我们也应该心里有个谱，到底降低了多少，能不能接受。
官方的工具当然是不二之选。关于mysqlslap的介绍请参考 官方文档 。
截取生产环境访问topranks_v3表的实际SQL共9973条，从中抽取访问量较大的7条，并发50，重复执行10次。命令如下：
./mysqlslap --defaults-file=../etc/my.cnf -u**** -p**** -c50 -i10 -q ../t.sql --debug-info
| 比较项 | 磁盘空间 | 耗时（秒） | 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中如何进行数据压缩性能对比”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
