mysql8 行格式_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主机，具体配置是：

配置项

参数