InnoDB数据页面压缩（Page Compression）技术可以使数据文件体积变小，减少降低磁盘开销，2亿行记录，可提高吞吐量（20%-30%），以较小的成本地提高了CPU的利用率。尤其是对只读/读多写少的业务，（例如，查询历史订单表）最为有效，同样的磁盘空间可以存储更多的数据。
InnoDB提供了两种压缩技术，一种是早期的行格式压缩（COMPRESSED Row Format），该方法是在创建表时指定ROW_FORMAT=COMPRESS，并通过选项 KEY_BLOCK_SIZE 设置压缩比例。另一种是新的页面压缩Page Compression，在支持稀疏文件（Sparse file（稀疏文件）的EXT4/XFS文件系统上，通过使用打洞（Punch Hole（打洞）特性进行压缩。
行格式压缩的COMPRESSED Row Format工作原理是：当用户获取数据时，如果压缩页没有不在Innodb_Buffer_Pool缓冲池里，那么就会从磁盘加载进去，并且会在Innodb_Buffer_Pool缓冲池里开辟一个新的未压缩的16KB的数据页来解压缩，固因此在缓冲池里同时存在着压缩和解压缩两个页面。为了避免多次压缩和解压缩，当有足够的内存空间时，InnoDB 会尝试将压缩和解压缩的页面都保留在Innodb_Buffer_Pool缓冲池中。当没有足够的内存空间时，InnoDB 会使用自适应 LRU 算法来决定是否应该从Innodb_Buffer_Pool缓冲区中驱逐压缩或解压缩的页面。当系统处于CPU瓶颈时，首先驱逐压缩页面；当系统处于I/O瓶颈时，解压缩页首先被驱逐解压缩页面。
由于一个数据页是16KB，现在因此可以在建表时指定压缩的页面大小是1KB、2KB、4KB，还是或者8KB，如果设置过小，则会导致消耗更多的CPU，因此通常设置为8KB。
很明显，这样的实现方式会增加对内存的开销，会导致Innodb_Buffer_Pool缓存池能存放的有效数据变少，数据库的性能也会出现显著下降。
使用页面压缩时Page Compression，从表空间文件中读取压缩页面会立即解压缩，Innodb_Buffer_Pool缓冲池中只存储了解压缩页面。相比之下，使用行格式压缩时COMPRESSED Row Format，解压缩页面和压缩页面都存储在Innodb_Buffer_Pool缓冲池中。这就意味着行格式压缩COMPRESSED Row Format占用的内存空间比页面压缩要大Page Compression要多。
使用页面压缩Page Compression，页面在写入表空间文件之前被压缩。相反，使用行格式压缩，页面在任意COMPRESSED Row Format，页面在任何更改之后都会立即重新压缩，这就意味着行格式压缩比COMPRESSED Row Format 比Page Compression页面压缩更频繁地压缩数据。
使用Page Compression页面压缩，可以支持多种压缩算法。相比之下，行格式压缩COMPRESSED Row Format，zlib是唯一支持的压缩算法是zlib。
一般来说，Page Compression综上所述，页面压缩要优于行格式压缩COMPRESSED Row Format。
开启t1表页面压缩，命令如下：
SET GLOBAL innodb_compression_algorithm='ZLIB';
ALTER TABLE t1 PAGE_COMPRESSED=1;
ALTER TABLE t1 ENGINE = InnoDB;需要特别注意的是：通过命令 ALTER TABLE xxx PAGE_COMPRESSED = 1 可以启用页面压缩，但是这只会对后续新增的数据会进行压缩，而不会对于原有的数据则不进行压缩。所以上述ALTER TABLE 操作只是修改 元原元数据（Metadata），瞬间就能完成。若想要对整个表进行压缩，则需要执行 ALTER TABLE xxx ENGINE = InnoDB 命令。
MySQL 8.0的语法不同于MariaDB，命令如下：
ALTER TABLE t1 COMPRESSION='ZLIB';
ALTER TABLE t1 ENGINE = InnoDB;摘自《MySQL运维进阶指南》
