MySQL 8 InnoDB Table 和 Page 压缩

压缩用一点CPU换取磁盘IO、内存空间、磁盘空间。

在有Secondary Indexes 的表中，使用压缩更加明显，相关索引数据也会压缩。

InnoDB 表压缩

对表压缩只需要在Create Table 时指定ROW_FORMAT=Compressed即可。

压缩的行格式不适用于InnoDB 系统表空间，这也可能就是为什么@@innodb_default_row_format不能指定为compressed的原因吧。

key_block_size 选项：指定磁盘上Table 的Page Size。较小的值需要的IO也会比较小。但是过小，可能导致单个Page不能保存多行，InnoDB需要重新组织Page。而且Key Block Size 值受到Table 上Index 列的硬性要求。

Key Block Size 的指定，在Buffer Pool 中也需要相应的Page Size 缓存。在InnoDB Buffer Pool中，提取或者更新compressed Page需要先uncompressed Page，在更新UnCompressed Page 后，还需要写回到 Compressed Page中。这里会出现一种情况，Buffer Pool 中保存同一个Page的两种形式：Compressed 和 UnCompressed。如果Buffer Pool 需要空间，会删除UnCompressed Pages，在需要时，再次 UnCompressed Pages。

Key Block Size的大小对于Compress Level没有影响，他只是设置了Page的大小。

是否做表压缩主要是依赖表中数据：

包含字符串、重复值、这样压缩效果才会有。因为InnoDB基于Page来压缩数据，如果没有重复值，或者binary 数据类型（数值型），压缩意义也就不大了。

有两个可选的方法测试表的压缩是否具有可行性：

使用OS压缩工具，比如gzip压缩表，可以大致对比使用MySQL压缩的情况。

创建待压缩表的复制表，压缩复制表。

简单查看压缩效果，对于系统中只有一张压缩表：

select * from information_schema.innodb_cmp;