MySQL 8.0 InnoDB压缩行格式性能测试

Wesley13
• 阅读 769

InnoDB compressed好吃吗?
不,它有点硌牙。

1. 背景信息1. 测试环境2. 进行测试2.1 所有数据可以加载到buffer pool中2.1.1 数据压缩率2.1.2 TPS相差值2.1.3 平均延迟差值 avg Latency (ms)2.1.4 99%延迟差值 99th percentile Latency (ms)2.2 数据量超过内存ibp容量2.2.1 数据压缩率2.2.2 TPS相差值2.2.3 平均延迟差值 avg Latency (ms)2.2.4 99%延迟差值 99th percentile Latency (ms)3. 总结延伸阅读

1. 背景信息

多年前我对InnoDB表压缩格式做了个简单的测试,得到的结论大概是:

InnoDB采用compressed行格式后,OLTP整体性能大约为原来的1/10,压缩率约为50%。

按照这个结论,压缩行格式不建议用在TPS较高的OLTP场景,如果有类似的业务需要,可以考虑用TokuDB或RocksDB引擎。

尝试过用TokuDB当做Zabbix的后端数据库,效果还不错,详情见 迁移Zabbix数据库到TokuDB

不过,TokuDB现在已经基本被Percona抛弃了,还有这类业务需求时,可以考虑改用RocksDB引擎,可以参考这篇文章 MyRocks引擎:入坑须知

随着MySQL 8.0.20的发布,我又重燃了对compressed行格式的兴趣,今日就此再做了个简单测试。

1. 测试环境

本次测试的服务器配置是腾讯云"标准型S5"型CVM主机,具体配置是:

配置项

参数

CPU

4 Core(Intel(R) Xeon(R) Platinum 8255C CPU @ 2.50GHz)

内存

16GB

数据盘

500GB SSD云硬盘(理论最大随机IOPS值 16800,实际上最高也只能跑到10000不到)

my.cnf中InnoDB相关配置参数(其余采用默认设置)

innodb_flush_log_at_trx_commit=1innodb_buffer_pool_size=8Ginnodb_log_file_size = 2G

MySQL选用最新的8.0.20版本:

Server version:        8.0.20 MySQL Community Server - GPL

2. 进行测试

本次测试计划分为两种模式
a) 所有数据可以加载到buffer pool中
b) 数据量超过内存ibp容量
针对上述两种模式再分别对dynamic、compressed行格式的区别。

2.1 所有数据可以加载到buffer pool中

相应的sysbench参数如下:

TBLCNT=50 #共50个表DURING=900 #一次压测900秒(5分钟)ROWS=100000 #每个表10万行数据MAXREQ=5000000 #每个线程执行500万次请求

2.1.1 数据压缩率

未压缩格式(KB)

压缩格式(KB)

压缩率(1-压缩格式/未压缩格式)

1638456

1218588

25.63%

2.1.2 TPS相差值

MySQL 8.0 InnoDB压缩行格式性能测试

数值说明:这表示 未压缩格式 相对于 压缩格式的提升比例,例如上图中第一列的 71.11%,表示 **在OLTP模式下,并发256线程压测时,未压缩行格式的TPS相对于压缩行格式增加71.11%**,下同。

2.1.3 平均延迟差值 avg Latency (ms)

MySQL 8.0 InnoDB压缩行格式性能测试

2.1.4 99%延迟差值 99th percentile Latency (ms)

MySQL 8.0 InnoDB压缩行格式性能测试

根据测试结果的几点结论:
a) 当数据都能放在buffer pool中的时候,是否采用压缩格式对于读的业务场景影响很小。
b) 当数据都能放在buffer pool中的时候,混合OLTP业务场景或者以更新为主的业务场景中,Dynamic行格式明显要比Compressed行格式的性能更好。
综上,当数据量比较小的时候,并且读多写少的业务场景中,可以考虑使用Compressed行格式。而如果是写多读少的业务场景,则最好使用Dynamic行格式。

2.2 数据量超过内存ibp容量

sysbench参数调整ROWS,其余不变。

ROWS=5000000 #每个表500万行数据

2.2.1 数据压缩率

未压缩格式(KB)

压缩格式(KB)

压缩率(1-压缩格式/未压缩格式)

59596904

40210556

34.03%

2.2.2 TPS相差值

MySQL 8.0 InnoDB压缩行格式性能测试

2.2.3 平均延迟差值 avg Latency (ms)

MySQL 8.0 InnoDB压缩行格式性能测试

2.2.4 99%延迟差值 99th percentile Latency (ms)

MySQL 8.0 InnoDB压缩行格式性能测试

根据测试结果的几点结论:
a) 当数据无法全部放在buffer pool中的时候,如果是读多写少的业务场景,则用Compressed行格式性能更高。
b) 当数据无法全部放在buffer pool中的时候,如果是写多读少的业务场景,则用Dynamic行格式性能更高。
综上,当数据量比较小的时候,并且读多写少的业务场景中,可以考虑使用压缩行格式。

3. 总结

根据上面的测试结果来看,如果是下面几种业务场景,则可以考虑使用InnoDB表想要使用compressed行格式:
a) 对压缩比需求不是特别高,本案中,只压缩了 25% ~ 34% 数据量,优势不大。
b) 数据量无法全部加载到buffer pool中的时候,读多写少的业务场景。

本案中,测试条件存在几点不足:
a) 服务器配置不算高。
b) 测试持续时长不够,只有15分钟。
c) 测试表和实际业务预计相差比较大,实际业务环境中,可能文本类型列会多一些,这样压缩比也会高一些。

综合来看,类似下面的业务场景,可以考虑使用compressed格式:
a) 数据量较大,且文本数据较多。
b) 磁盘比较紧张。
c) 读多写少。

最后,最好还是自己再亲自测试下比较靠谱哈。

延伸阅读

enjoy MySQL :)

全文完。

由叶老师主讲的知数堂「MySQL优化课」课程早已升级到MySQL 8.0版本了,现在上车刚刚好,扫码开启MySQL 8.0的修行之旅吧。

MySQL 8.0 InnoDB压缩行格式性能测试


另外,叶老师在腾讯课堂《MySQL性能优化》精编版第一期已完结,本课程讲解读几个MySQL性能优化的核心要素:合理利用索引,降低锁影响,提高事务并发度

下面是自动拼团的二维码直接享受组团价

MySQL 8.0 InnoDB压缩行格式性能测试  

本文分享自微信公众号 - 老叶茶馆(iMySQL_WX)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

点赞
收藏
评论区
推荐文章
blmius blmius
3年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
皕杰报表之UUID
​在我们用皕杰报表工具设计填报报表时,如何在新增行里自动增加id呢?能新增整数排序id吗?目前可以在新增行里自动增加id,但只能用uuid函数增加UUID编码,不能新增整数排序id。uuid函数说明:获取一个UUID,可以在填报表中用来创建数据ID语法:uuid()或uuid(sep)参数说明:sep布尔值,生成的uuid中是否包含分隔符'',缺省为
Jacquelyn38 Jacquelyn38
3年前
2020年前端实用代码段,为你的工作保驾护航
有空的时候,自己总结了几个代码段,在开发中也经常使用,谢谢。1、使用解构获取json数据let jsonData  id: 1,status: "OK",data: 'a', 'b';let  id, status, data: number   jsonData;console.log(id, status, number )
Stella981 Stella981
3年前
KVM调整cpu和内存
一.修改kvm虚拟机的配置1、virsheditcentos7找到“memory”和“vcpu”标签,将<namecentos7</name<uuid2220a6d1a36a4fbb8523e078b3dfe795</uuid
Easter79 Easter79
3年前
Twitter的分布式自增ID算法snowflake (Java版)
概述分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的。有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成。而twitter的snowflake解决了这种需求,最初Twitter把存储系统从MySQL迁移
Wesley13 Wesley13
3年前
mysql设置时区
mysql设置时区mysql\_query("SETtime\_zone'8:00'")ordie('时区设置失败,请联系管理员!');中国在东8区所以加8方法二:selectcount(user\_id)asdevice,CONVERT\_TZ(FROM\_UNIXTIME(reg\_time),'08:00','0
Stella981 Stella981
3年前
Android蓝牙连接汽车OBD设备
//设备连接public class BluetoothConnect implements Runnable {    private static final UUID CONNECT_UUID  UUID.fromString("0000110100001000800000805F9B34FB");
Wesley13 Wesley13
3年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
为什么mysql不推荐使用雪花ID作为主键
作者:毛辰飞背景在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究
Python进阶者 Python进阶者
9个月前
Excel中这日期老是出来00:00:00,怎么用Pandas把这个去除
大家好,我是皮皮。一、前言前几天在Python白银交流群【上海新年人】问了一个Pandas数据筛选的问题。问题如下:这日期老是出来00:00:00,怎么把这个去除。二、实现过程后来【论草莓如何成为冻干莓】给了一个思路和代码如下:pd.toexcel之前把这