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. 總結延伸閱讀
多年前我對InnoDB表壓縮格式做了個簡單的測試，得到的結論大概是：
按照這個結論，壓縮行格式不建議用在TPS較高的OLTP場景，如果有類似的業務需要，可以考慮用TokuDB或RocksDB引擎。
嘗試過用TokuDB當做Zabbix的後端資料庫，效果還不錯，詳情見
遷移Zabbix資料庫到TokuDB。
不過，TokuDB現在已經基本被Percona抛棄了，還有這類業務需求時，可以考慮改用RocksDB引擎，可以參考這篇文章
MyRocks引擎：入坑須知随着MySQL 8.0.20的釋出，我又重燃了對compressed行格式的興趣，今日就此再做了個簡單測試。
本次測試的伺服器配置是騰訊雲"标準型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 本次測試計劃分為兩種模式
a) 所有資料可以加載到buffer pool中
b) 資料量超過記憶體ibp容量
針對上述兩種模式再分别對dynamic、compressed行格式的差別。
相應的sysbench參數如下：
TBLCNT=50 #共50個表
DURING=900 #一次壓測900秒（5分鐘）
ROWS=100000 #每個表10萬行資料
MAXREQ=5000000 #每個線程執行500萬次請求 | 未壓縮格式（KB） | 壓縮格式（KB） | 壓縮率(1-壓縮格式/未壓縮格式) |
| 1638456 | 1218588 | 25.63% |
數值說明：這表示 未壓縮格式 相對于 壓縮格式的提升比例，例如上圖中第一列的 71.11%，表示 在OLTP模式下，并發256線程壓測時，未壓縮行格式的TPS相對于壓縮行格式增加71.11%，下同。
根據測試結果的幾點結論：
a) 當資料都能放在buffer pool中的時候，是否采用壓縮格式對于讀的業務場景影響很小。
b) 當資料都能放在buffer pool中的時候，混合OLTP業務場景或者以更新為主的業務場景中，Dynamic行格式明顯要比Compressed行格式的性能更好。
綜上，當資料量比較小的時候，并且讀多寫少的業務場景中，可以考慮使用Compressed行格式。而如果是寫多讀少的業務場景，則最好使用Dynamic行格式。