2.2 数据量超过内存ibp容量
sysbench参数调整ROWS，其余不变。
ROWS=5000000 #每个表500万行数据
2.2.1 数据压缩率
| 未压缩格式（KB） | 压缩格式（KB） | 压缩率(1-压缩格式/未压缩格式) |
| 59596904 | 40210556 | 34.03% |
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 :)
全文完。
</div>
