MySQL压缩解决方案

2018-11-07

网络安全和信息化 2018年3期

关键词：字符串压缩比内存

MySQL压缩协议介绍

1.适用场景

MySQL压缩协议适合的场景是MySQL的服务器端和客户端之间传输的数据量很大，或者可用带宽不高的情况，典型的场景有如下两个：

（1）查询大量的数据，带宽不够，比如导出数据的时候。

（2）复制的时候binlog量太大，启用slave_compressed_protocol参数进行日志压缩复制。

2.压缩协议简介

压缩协议是MySQL通信协议的一部分，要启用压缩协议进行数据传输，需要MySQL服务器端和客户端都支持zlib算法。启动压缩协议会导致CPU负载略微上升。使用启用压缩协议使用-C参数或者--compress=true参数启动客户端的压缩功能。如果启用了-C或者compress=true选项，那么在连接到服务器段的时候，会发送0x0020（CLIENT_COMPRESS）的服务器权能标志位，和服务器端协商通过后（3次握手以后），就支持压缩协议了。由于采用压缩，数据包的格式会发生变化，如图1和图2所示。

图1 未压缩的数据包格式

图2 压缩后的数据包格式

大家可能留意到压缩后的数据报格式有压缩和未压缩之分，这个是MySQL为了较少CPU开销而做的一个优化。如果内容小于50个字节的时候，就不对内容进行压缩，而大于50字节的时候，才会启用压缩功能。具体的规则如下：

当第三个字段的值等于0x00的时候，表示当前包没有压缩，因此n*byte的内容为1*byte,n*byte，即请求类型和请求内容。

当第三个字段的值大于0x00时，表示当前包已采用zlib压缩，因此使用的时候需要对n*byte进行解压，解压后内容为1*byte,n*byte，即请求类型和请求内容。

3.方案实践

在客户端连接的时候加上-C或者--compress=true参数。如果是对同步添加压缩协议支持时，则需配置slave_compressed_protocol=1。下面是采用压缩协议连接MySQL服务端的范例：

如果需要在主从复制中启用压缩传输，则在从机开启slave_compressed_protocol=1参数就OK。

4.压缩效果

可通过在mysqldump中使用--compress选项来观察压缩传输的效果，也可通过主从复制中已用slave_compressed_protocol参数来观察压缩传输的效果，很容易看出效果。

MySQL列压缩解决方案

MySQL针对列的压缩目前直接的方案并不支持，映象中腾讯的Tmysql可以直接针对列的压缩。这里主要介绍一个曲线救国的办法，即在业务层面使用MySQL提供的压缩和解压函数来针对列进行压缩和解压操作。也就是要对某一列做压缩，就需要在写入的时候调用COMPRESS函数对那个列的内容进行压缩，然后存放到对应的列。读取的时候，使用UNCOMPRESSED函数对压缩的内容进行解压缩。

1.适用场景

针对MySQL中某个列或者某几个列数据量特别大，一般都是 varchar、text、char等数据类型。

2.压缩函数简介

图3 压缩比截图

MySQL的压缩函数COMPRESS压缩一个字符串，然后返回一个二进制串。使用该函数需要MySQL服务端支持压缩，否则会返回NULL，压缩字段最好采用varbinary或者blob字段类型保存。使用UNCOMPRESSED函数对压缩过的数据进行解压。注意，采用这种方式需要在业务侧做少量改造。压缩后的内容存储方式如下：

（1）空字符串就以空字符串存储。

（2）非空字符串存储方式为前4个bype保存未压缩的字符串，紧接着保存压缩的字符串。

3.方案实践

字段压缩方案涉及到的几个相关的函数如下：

压缩函数

COMPRESS()

解压缩函数

UNCOMPRESS()

字符串长度函数

LENGTH()

未解压字符串长度函数

UNCOMPRESSED_LENGTH()

实践步骤：

（1）创建一张测试表：

CREATE TABLE IF NOT

（2）网表中插入压缩的数据：

（3）读取压缩的数据：

（4）查询对应的长度和内容：

4.压缩效果

从图3中可以看出压缩效果比较好，针对text、char、varchr、blob等，如果里面重复的数据越多压缩效果就越好。

InnoDB表压缩解决方案

1.适用场景

采用压缩表一般都用在由于数据量太大，磁盘空间不足，负载主要体现在IO上，而服务器的CPU又有比较多的余量的场景。

2.表压缩简介

（1）为什么需要压缩

目前很多表都支持压缩，比如 Myisam、InnoDB、TokuDB、MyRocks 。由于使用InnoDB主要是不需要做什么改动，对线上完全透明，压缩方案也成熟，因此这里只对InnoDB做详细说明。

在SSD没有大量横行的时候，数据库几乎都是IO负载型的，在CPU有大量余量的时候，磁盘IO的瓶颈就已经凸显出来。而数据的大量存储，尤其是日志型数据和监控类型的数据，会导致磁盘空间快速增长。硬盘不够用也会在很多业务中凸显出来。

一种比较好的方式就诞生了，那就是通过牺牲少量CPU资源，采用压缩来减少磁盘空间占用，以及优化IO和带宽。尤其针对读多写少的业务。

SSD出来后，数据库的IO负载有所降低，但是对于磁盘空间的问题还是没有很好的解决。因此压缩表使用还是非常的广泛。这也就是为什么那么多的引擎都支持压缩的原因。

而Innodb在MySQL 5.5的时候就支持了压缩功能，只是压缩比比较低，通常在50%左右。而tokuDB能达到80%左右，MyRocks的压缩比能达到70%左右。

注意：压缩比和存储的数据组成有很大关系，并不是所有的数据都能达到上面所说的压缩比。如果大部分是字符串，并且重复的数据比较多，压缩比会很好。

（2）Innodb的压缩介绍

使用Innodb压缩的前提条件是，innodb_file_per_table这个参数要启用，innodb_file_format这个参数设置成Barracuda。

你可以使用ROW_FORMAT=COMPRESSED来create或者alter表来开启Innodb的压缩功能，如果没有指定KEY_BLOCK_SIZE的大小，默认KEY_BLOCK_SIZE为innodb_page_size大小的一半，也可以通过指定KEY_BLOCK_SIZE=n参数来开启Innodb的压缩功能，n可以为 1、2、4、8、16，单位是 K。n的值越小，压缩比越高，消耗的CPU资源也越多。

注意：32K或者64K的页不支持压缩。启用压缩后，索引数据也同样会被压缩。

你也可以通过调整innodb_compression_level来设置压缩的级别，级别从1~9，默认是6。级别越低，意味着压缩比越高，同时也意味着需要更多的CPU资源。

（3）压缩算法

Innodb压缩借助的是著名的zlib库，采用L777压缩算法，这种算法在减少数据大小和CPU利用方面很成熟高效。同时这种算法是无损的，因此原生的未压缩的数据总是能够从压缩文件中重构，LZ777实现原理是查找重复数据的序列号然后进行压缩，所以数据模式决定了压缩效率，一般而言，用户的数据能够被压缩50%以上。

（4）压缩表在buffer_pool中如何处理？

在buffer_pool缓冲池中，压缩的数据通过KEY_BLOCK_SIZE的大小的页来保存，如果要提取压缩的数据或者要更新压缩数据对应的列，则会创建一个未压缩页来解压缩数据，然后在数据更新完成后，会将为压缩页的数据重新写入到压缩页中。内存不足的时候，MySQL会讲对应的未压缩页踢出去。

因此，如果你启用了压缩功能，你的buffer_pool缓冲池中可能会存在压缩页和未压缩页，也可能只存在压缩页。不过可能仍然需要将你的buffer_pool缓冲池调大，以便能同时能保存压缩页和未压缩页。

MySQL采用最少使用（LRU）算法来确定将哪些页保留在内存中，哪些页剔除出去，因此热数据会更多地保留在内存中。当压缩表被访问的时候，MySQL使用自适应的LRU算法来维持内存中压缩页和非压缩页的平衡。当系统IO负载比较高的时候，这种算法倾向于讲未压缩的页剔除，一面腾出更多的空间来存放更多的压缩页。当系统CPU负载比较高的时候，MySQL倾向于将压缩页和未压缩页都剔除出去，这个时候更多的内存用来保留热的数据，从而减少解压的操作。

图4 压缩前后对比图

（5）如何评估KEY_BLOCK_SIZE是否合适？

为了更深入地了解压缩表对性能的影响，在Information Schema库中有对应的表可以用来评估内存的使用和压缩率等指标。

INNODB_CMP是收集的是某一类的KEY_BLOCK_SIZE压缩表的整体状况的信息，汇总的是所有KEY_BLOCK_SIZE压缩表的统计。

而INNODB_CMP_PER_INDEX表则是收集各个表和索引的压缩情况信息，这些信息对于在某个时间评估某个表的压缩效率或者诊断性能问题很有帮助。INNODB_CMP_PER_INDEX表的收集会导致系统性能受到影响，必须innodb_cmp_per_index_enabled选项才会记录，生产环境最好不要开启。

我们可通过观察INNODB_CMP表的压缩失

败情况，如果失败比较多，则需要调大KEY_BLOCK_SIZE。一般建议KEY_BLOCK_SIZE设置为8。