传统上,InnoDB
压缩功能主要推荐用于只读或以读取为主的
工作负载,例如在
数据仓库
配置中。SSD存储设备的兴起,
速度快但相对较小且昂贵,这使得压缩对工作负载也具有吸引力
:高流量、交互式网站可以通过使用压缩表OLTP
来降低存储需求和每秒 I/O 操作数 ( IOPS )频繁执行
INSERT
、
UPDATE
和
DELETE
操作的应用程序。
MySQL 5.6 中引入的配置选项可让您调整压缩对特定 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
配置选项的值。