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表压缩格式做了个简单的测试，得到的结论大概是：
按照这个结论，压缩行格式不建议用在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=1 innodb_buffer_pool_size=8G innodb_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相差值
数值说明：这表示 未压缩格式 相对于 压缩格式的提升比例，例如上图中第一列的 71.11%，表示 在OLTP模式下，并发256线程压测时，未压缩行格式的TPS相对于压缩行格式增加71.11%，下同。
2.1.3 平均延迟差值 avg Latency (ms)
2.1.4 99%延迟差值 99th percentile Latency (ms)
根据测试结果的几点结论：
a) 当数据都能放在buffer pool中的时候，是否采用压缩格式对于读的业务场景影响很小。
b) 当数据都能放在buffer pool中的时候，混合OLTP业务场景或者以更新为主的业务场景中，Dynamic行格式明显要比Compressed行格式的性能更好。
综上，当数据量比较小的时候，并且读多写少的业务场景中，可以考虑使用Compressed行格式。而如果是写多读少的业务场景，则最好使用Dynamic行格式。
</div>
