使用场景:
数据分布特点，决定了空间压缩的效率，如果存入的数据的重复率较高，其压缩率就会较高；通常情况下字符类型数据(CHAR, VARCHAR, TEXT or BLOB )具有较高的压缩率，而一些二进制数据(integers or floating point numbers)或者一些已经压缩过的数据(JPEG or PNG images)的压缩率不会很好；
应用场景，可以简单解释为应用的insert，update，delete，select的比率：
如果应用select占了绝大部分，只有很少的update，那么只有较少的页当modification log[为了尽可能多的避免压缩、解压带来的额外消耗，InnoDB在压缩后的B-Tree页中新增了一个modification log区，通过记录当前的页的修改日志，来避免频繁压缩解压]空间不足时候，才需要重组或者重新压缩的，这种场景下使用compress也是不错的选择；
如果应用只是单纯的insert，此时数据的插入按照主键递增的方式组织，即使表中的secondary index page也基本上不需要重组和重压缩；
对于delete操作，由于innodb删除行采用打标志位的方式来删除，所以对compress行的删除通过修改uncompressed数据的方式实现，所以效率很高；
对于update操作，如果不是对索引列或者存储在off-page的blob，text，长字符串的列的更新，这种场景下使用压缩也是可以接受的；
上面结合insert，update，delete，select说明了各个使用场景，但是归根结底是利用cpu time来换取性能的提升，如果应用的瓶颈为io瓶颈，而不是cpu瓶颈，那么可以利用剩余的cpu来提升应用性能。
监控性能：我们可以观察应用程序的性能，数据服务器的cpu，i/o，磁盘空间等重要指标，通过这些指标我们来判断compress的性能再好不过了；除了上面的手段外，innodb plugin提供了监控compress压缩率以及内存的使用情况的视图：{information_schema:innodb_cmp,innodb_cmp_rest}:两个视图的列都是相同的，记录了页在compress和uncompress操作过程中的一些状态值，只不过innodb_cmp记录的是一个历史汇总，而innodb_cmp_rest记录的是一个较为实时的统计值，包括btree页compress/uncompress的次数，所花费时间,compress成功次数，以及compress-page的大小；
通过这两个视图能够帮助我们决定是否对采取对某一个表进行压缩(前提是没有使用其他压缩表)，其中值得我们关注的信息包括plugin执行压缩，解压的时间，次数；如果有大量的compress操作(对比insert，update，delte)，则有可能表明压缩表被更新的太频繁导致压缩效率变低，这个时候需要选择大一些的page，或者其他的表进行压缩；成功率：compress_ops_ok/compress_ops的比率很高的话，则表明系统运行的良好，反之则表明innodb经常进行 reorganize, recompress and split B-tree nodes，此时则需要对该表禁止使用compress或者选择较大的key_block_size；当对btree节点进行一次更新操作时，如果该节点已经没有足够的空间容下压缩数据，而不得不节点split，这个时候我们就需要关注compress success的次数了；{information_schema.innodb_cmpmem,innodb_cmpmem_rest}：这两个视图记录压缩页使用buffer pool的一些信息，innodb plugin使用了buddy allocator系统来分配不同大小的页：1kb到16kb，详细信息包括：buffer pool为压缩页分配正在使用的page数，可供使用的page数，buddy allocator重新分配page的次数及时间；
从上面的查询出来的信息中可以看到buffer pool中只含有8k的压缩页，一共进行了1048次压缩，其中921次成功，61次的解压缩，同时可以看出压缩和解压页所花费的时间都是小于1秒的，因为查询出来的值都为0；
上面这幅图展示了buffer pool内存分配情况，有6169个8kb的压缩页在buffer pool中，除此剩余的还分配了64字节的page，这个page的用途为记录在buffer中有多少压缩页并且还未以压缩形式存在，即我们可以得出有6169-5910=259个压缩页以未压缩的状态存在于buffer pool中；同时可以得到由于内存分配给压缩页导致的碎片，而不能使用的(128*1+512*1+2048*1+4096*1)内存，导致碎片的原因官方文档中这样说的：This is because small memory allocation requests are fulfilled by splitting bigger blocks, starting from the 16K blocks that are allocated from the main buffer pool, using the buddy allocation system.The fragmentation is this low, because some allocated blocks have been relocated (copied) to form bigger adjacent free blocks. This copying of SUM(PAGE_SIZE*RELOCATION_OPS) bytes has consumed less than a second (SUM(RELOCATION_TIME)=0).
