14.9.1.1 table 压缩概述

由于处理器和高速缓存的速度增加的速度超过磁盘存储设备，因此许多工作负载为disk-bound。数据compression以较小的 CPU 使用率增加的代价实现了较小的数据库大小，减少的 I/O 和改进的吞吐量。在具有足够 RAM 以便将经常使用的数据保留在内存中的系统上，压缩对于读取密集型应用程序特别有价值。

用ROW_FORMAT=COMPRESSED创建的InnoDBtable 可以在磁盘上使用比配置的innodb_page_size值小的page size。较小的页面需要更少的 I/O 来读取和写入磁盘，这对于SSD设备特别有用。

通过CREATE TABLE或ALTER TABLE KEY_BLOCK_SIZE参数指定压缩的页面大小。不同的页面大小要求将 table 放置在file-per-tabletable 空间或general tablespace而不是system tablespace中，因为系统 table 空间无法存储压缩 table。有关更多信息，请参见第 14.6.3.2 节“每 table 文件 table 空间”和第 14.6.3.3 节“常规 table 空间”。

不管KEY_BLOCK_SIZE值如何，压缩级别都相同。当您为KEY_BLOCK_SIZE指定较小的值时，您将获得越来越小的页面的 I/O 好处。但是，如果指定的值太小，则当数据值无法充分压缩以适合每个页面中的多行时，将需要额外的开销来重组页面。根据 table 中每个索引的键列的长度，对 table 的KEY_BLOCK_SIZE大小有一个硬性限制。指定一个太小的值，并且CREATE TABLE或ALTER TABLE语句失败。

在缓冲池中，压缩数据保存在小页面中，其页面大小基于KEY_BLOCK_SIZE值。为了提取或更新列值，MySQL 还使用未压缩的数据在缓冲池中创建了未压缩的页面。在缓冲池中，对未压缩页面的所有更新也将重新写回到等效的压缩页面。您可能需要调整缓冲池的大小以容纳压缩和未压缩页面的附加数据，尽管在需要空间时未压缩的页面是从缓冲池中返回的evicted，然后在下次访问时再次解压缩。