2.2 数据量超过内存ibp容量

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

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

2.2.1 数据压缩率

2.2.2 TPS相差值

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

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

根据测试结果的几点结论：

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) 读多写少。

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

延伸阅读

• 15.9 InnoDB Table and Page Compression, https://dev.mysql.com/doc/refman/8.0/en/innodb-compression.html
  

enjoy MySQL :)

全文完。