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


北京联盟_本文原题:MySQL 8.0 InnoDB压缩行格式性能测试
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的后端数据库 , 效果还不错 , 详情见。
不过 , TokuDB现在已经基本被Percona抛弃了 , 还有这类业务需求时 , 可以考虑改用RocksDB引擎 , 可以参考这篇文章。
随着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= 1
innodb_buffer_pool_size= 8G
innodb_log_file_size= 2G
MySQL选用最新的8.0.20版本:
Serverversion: 8 .0.20MySQLCommunityServer-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压缩行格式性能测试
本文插图
【格式|MySQL 8.0 InnoDB压缩行格式性能测试】

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


推荐阅读