压缩理念：通过提高CPU利用率和节约成本，降低数据库容量及I/O负载，从而使数据吞吐率得到显著提高。
压缩原理：压缩表减少了磁盘上数据库的大小，使得用户不必频繁地操作写入和读取便可以访问数据。对于 InnoDB的工作量以及传统的用户表而言（特别是在某些读取密集型的应用中，内存有足够的空间存储常用数据），数据压缩不仅大大减少了数据库所需的存储空间，而且还减少了 I/O的工作量，提高了数据吞吐率，从而节约开销处理成本。节省存储成本固然重要，但是减少 I/O成本更为关键。
压缩限制：为了保持数据库文件的向下兼容性，只有在使用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引起，压缩便能够提高整体性能。所以，在使用不同的压缩配置测试应用程序时，你应该在一个类似于产品系统计划配置的平台上进行测试。
