传统上,InnoDB
压缩 功能主要推荐用于只读或以读为主的 工作负载,例如在 数据仓库 配置中。随着 SSD 存储设备的兴起,这些设备速度快,但相对较小且价格昂贵,因此压缩对 OLTP
工作负载也具有吸引力:高流量、交互式网站可以通过使用压缩表来减少其存储需求和每秒 I/O 操作 (IOPS),这些表适用于进行频繁的 INSERT
、UPDATE
和 DELETE
操作的应用程序。
这些配置选项允许您调整压缩对特定 MySQL 实例的工作方式,重点是写入密集型操作的性能和可扩展性
innodb_compression_level
允许您增加或降低压缩程度。较高的值允许您将更多数据放入存储设备,但会以压缩期间更多的 CPU 开销为代价。较低的值允许您在存储空间不那么重要的情况下减少 CPU 开销,或者您预计数据不易压缩。innodb_compression_failure_threshold_pct
指定压缩表更新期间 压缩失败 的截止点。当超过此阈值时,MySQL 开始在每个新的压缩页面中留出额外的可用空间,动态调整可用空间量,直到达到由innodb_compression_pad_pct_max
指定的页面大小百分比。innodb_compression_pad_pct_max
允许您调整在每个 页面 中保留的最大空间量,以记录对压缩行的更改,而无需再次压缩整个页面。值越大,无需重新压缩页面即可记录的更改就越多。MySQL 对每个压缩表中的页面使用可变数量的可用空间,仅当指定百分比的压缩操作在运行时 “失败”,需要进行昂贵的操作来拆分压缩页面时。innodb_log_compressed_pages
允许您禁用将 重新压缩 的 页面 的图像写入 重做日志。当对压缩数据进行更改时,可能会发生重新压缩。此选项默认启用,以防止在恢复过程中使用不同版本的zlib
压缩算法时可能发生的损坏。如果您确定zlib
版本不会发生更改,请禁用innodb_log_compressed_pages
以减少修改压缩数据的负载的重做日志生成。
由于处理压缩数据有时会涉及同时在内存中保留压缩和未压缩版本的页面,因此在将压缩与 OLTP 风格的工作负载一起使用时,请准备好增加 innodb_buffer_pool_size
配置选项的值。