本文是关于如何比较mysql中的数据压缩性能。我觉得边肖很实用，就和大家分享一下作为参考。让我们跟着边肖看一看。
00-1010
1. 测试环境
搭载2.6.18-92内核、4G内存和四颗2800 MHz双核AMD皓龙(TM)处理器2220 CPUs的64位Linux开发机。
MySQL放在一个7200 rpm的SAT硬盘上，没有raid；
MySQL关闭查询缓存没有进行任何优化，以避免查询缓存对测试结果的干扰。
00-10102424753记录，生产环境某一段的实际数据；
分别建立了(partition_by1，idx_rank)和(partition_by1，chg_idx)的联合索引，其中partition_by1为32长度的varchar类型，用于检索。另外两个字段是浮点数，主要用于排序。
Autokid作为子列，充当PRIMARY KEY，只用于保证数据加载的原子性，没有实际意义。
1.1 软硬件
10-1010，压缩比越高，占用的磁盘空间越小，直接降低了数据的存储成本；
00-1010压缩后的查询性能不应大幅降低。归档不支持索引，所以性能降级是不可避免的，所以我们也要心中有谱，降级多少，是否可以接受。
1.2 表结构
2. 测试目的
官方工具当然是最好的选择。mysqlslap的介绍请参考官方文件。
00-1010，从访问topranks_v3表的生产环境中一共截取了9973条实际的SQL片段，提取了7条访问量较大的片段，并行执行50次，重复执行10次。顺序如下：/mysqlslap -默认值-文件=./etc/my . CNF-u * * * *-p * * * *-c50-i10-q./t.sql -调试-信息
00-1010比较项目磁盘空间时间(秒)CPU IdleLOAD并发基准表(myisam)308301550 archive 4009.00000000005
对于测试表，Archive表占用的空间约为前一张的18.7%，myisampack后占用的空间约为前一张的24.6%。他们很相似。从空间利用的角度来看，似乎需要选择归档表。
让我们看看查询性能，并将其与基准表进行比较。无论总时间消耗还是系统负载，50并发下pack表的查询性能与基准表相当。单并发的情况下存档表需要5分钟以上(等不及了，杀了它)！
然后，我们似乎可以得出结论，ARCHIVE引擎基本上可以忽略需要在线查询的表。
为什么ARCHIVE引擎在这个测试中如此缓慢？
众所周知，mysql提供了归档存储。
引擎是为了降低磁盘开销，但还有一个前提，那就是被归档的数据不需要或者很少被在线查询，偶尔的查询慢一些也是没关系的。鉴于上述原因，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中如何进行数据压缩性能对比”这篇文章就分享到这里了，希望
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/73738.html