压缩理念
通过提高CPU利用率和节约成本，降低数据库容量及I/O负载，从而使数据吞吐率得到显著提高。
压缩原理
压缩表减少了磁盘上数据库的大小，使得用户不必频繁地操作写入和读取便可以访问数据。对于 InnoDB的工作量以及传统的用户表而言（特别是在某些读取密集型的应用中，内存有足够的空间存储常用数据），数据压缩不仅大大减少了数据库所需的存储空间，而且还减少了 I/O的工作量，提高了数据吞吐率，从而节约开销处理成本。节省存储成本固然重要，但是减少 I/O成本更为关键。
在InnoDB中，是以16K的页（Page）为基本的存储单位的。我们知道，InnoDB是的数据是在Clustered index中存储的，在Secondary index中仅存储对应数据的PK。Clustered index和Secondary index都是B-Tree结构的，所以对InnoDB数据页和索引页的压缩很大程度上就是对B-Tree节点页的压缩。
在InnoDB中，除了B-Tree节点页，还有一类数据页（Page），称为“overflow page”。当需要存储Long column时，如果当前页能够完全存储全部字段时，则存储在当前页中；如果当前页不足以存储全部，则InnoDB选择最长的字段，将其存储到一个单独的页中，我们称这样的页为“overflow page”，而原数据页仅仅需存储一个20Bytes的指针。参考下图：
压缩使用的是zlib library中的LZ77算法。
压缩限制
为了保持数据库文件的向下兼容性，只有在使用innodb_file_format配置参数来启动“Barracuda”数据库文件格式时，压缩才能被指定。在 InnoDB系统表空间压缩表也是不可行的。系统表空间（space 0, the ibdata* 文件）不仅包含用户数据，还包含InnoDB内部系统信息，永远不能被压缩。因此，压缩只适用于存储在表空间的表（以及索引）。什么时候使用压缩
通常情况下，对于字符串数量适中的表来说，读取数据比写入数据速度更快，压缩性能最佳。压缩时应努力减少数据文件的大小，影响其压缩效率的决定性因素就是数据本身。在一组数据中识别重复的字符串可以撤消压缩。完全随机的数据是最糟糕的。传统的数据往往有重复的值，压缩起来也相对有效。字符串也往往很容易压缩，不管它是定义在CHAR, VARCHAR, TEXT上还是BLOB列上。另一方面，某些表包含了大部分的二进制数据（整数或浮点数）或者之前被压缩的数据（例如JPEG或PNG图像），压缩起来通常比较困难。
除了考虑选择哪些表进行压缩（以及页面大小如何设置），工作量是衡量性能的另一个关键因素。InnoDB为压缩的数据设置了修改日志，如果应用程序以读取为主而不是以更新为主，那么，在索引页占用完每一页“修改日志”的空间之后，只有少数的页面需要进行重组和重新压缩。如果更新主要改变的是非索引列或者一些包含了碰巧被存储为“off-page”的BLOBs及大的字符串的列，压缩的开销是可以接受的。如果表中唯一更改的是使用单递增主键的INSERTs语句，并且不存过太多非聚集索引，那么，便没必要重组或重新压缩索引页。由于InnoDB能够在压缩页面“标记删除”以及删除记录，并以此来“替代”修改未压缩的数据，因此，在表中进行DELETE操作是相对有效的。
对于某些环境，加载数据所耗费的时间与运行检索所需的时间同样意义重大。特别是在数据仓库环境下，很多表的属性为只读或者以读取为主。在这种情况下，除非在更少的磁盘读取中或存储成本上造成的节约效果是显著的，否则，从增加的加载时间角度出发，压缩付出的代价实在不能令人接受。
从根本上说，当CPU时间可用于压缩及解压数据时，压缩效果最佳。因此，如果工作量是由I/O引起的，而不是由CPU引起，压缩便能够提高整体性能。所以，在使用不同的压缩配置测试应用程序时，你应该在一个类似于产品系统计划配置的平台上进行测试。
压缩过程
当使用压缩存储的页面，当Buffer Pool载入后，会将其解压。这时，该页面在Buffer Pool中同时存在“压缩版”和“解压版”。当Buffer Pool需要驱逐这些页的时候，有两种情况会发生：如果InnoDB认为当前应用是IO-Bound，相比CPU还有额外能力来做解压操作，则InnoDB选择仅驱逐页面的“解压版”；否则InnoDB会将页面的两个版本同时驱逐出去。也就是说Buffer Pool会是下图的状态：
