展开全部
压缩表从名字上来看,简单理解为压缩后的表,也就是把原始表根据一定的压62616964757a686964616fe58685e5aeb931333433656638缩算法按照一定的压缩比率压缩后生成的表。
1.1 压缩能力强的产品
表压缩后从磁盘占用上看要比原始表要小很多。如果你熟悉列式数据库,那对这个概念一定不陌生。比如,基于 PostgreSQL 的列式数据库 Greenplum;早期基于 MySQL 的列式数据库 inforbright;或者 Percona 的产品 tokudb 等,都是有压缩能力非常强的数据库产品。
1.2 为什么要用压缩表?
情景一:磁盘大小为 1T,不算其他的空间占用,只能存放 10 张 100G 大小的表。如果这些表以一定的比率压缩后,比如每张表从 100G 压缩到 10G,那同样的磁盘可以存放 100 张表,表的容量是原来的 10 倍。情景二:默认 MySQL 页大小 16K,而 OS 文件系统一般块大小为 4K,所以在 MySQL 在刷脏页的过程中,有一定的概率出现页没写全而导致数据坏掉的情形。比如 16K 的页写了 12K,剩下 4K 没写成功,导致 MySQL 页数据损坏。这个时候就算通过 Redo Log 也恢复不了,因为几乎有所有的关系数据库采用的 Redo Log 都记录了数据页的偏移量,此时就算通过 Redo Log 恢复后,数据也是错误的。所以 MySQL 在刷脏数据之前,会把这部分数据先写入共享表空间里的 DOUBLE WRITE BUFFER 区域来避免这种异常。此时如果 MySQL 采用压缩表,并且每张表页大小和磁盘块大小一致,比如也是 4K,那 DOUBLE WRITE