
压缩表从名字上来看,简单理解为压缩后的表,也就是把原始表根据一定的压缩算法按照一定的压缩比率压缩后生成的表。
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 BUFFER 就可以不需要,这部分开销就可以规避掉了。查看文件系统的块大小:
root@ytt-pc:/home/ytt# tune2fs -l /dev/mapper/ytt--pc--vg-root | grep -i 'block size'Block size: 4096
1.3 压缩表的优势
压缩表的优点非常明显,占用磁盘空间小!由于占用空间小,从磁盘置换到内存以及之后经过网络传输都非常节省资源。
简单来讲:节省磁盘 IO,减少网络 IO。
1.4 压缩表的缺陷当然压缩表也有缺点,压缩表的写入(INSERT,UPDATE,DELETE)比普通表要消耗更多的 CPU 资源。
压缩表的写入涉及到解压数据,更新数据,再压缩数据,比普通表多了解压和再压缩两个步骤,压缩和解压缩需要消耗一定的 CPU 资源。所以需要选择一个比较优化的压缩算法。
1.5 MySQL 支持的压缩算法这块是 MySQL 所有涉及到压缩的基础,不仅仅用于压缩表,也用于其它地方。比如客户端请求到 MySQL 服务端的数据压缩;主从之间的压缩传输;利用克隆插件来复制数据库 *** 作的压缩传输等等。
从下面结果可以看到 MySQL 支持的压缩算法为 zlib 和 zstd,MySQL 默认压缩算法为 zlib,当然你也可以选择非 zlib 算法,比如 zstd。至于哪种压缩算法最优,暂时没办法简单量化,依赖表中的数据分布或者业务请求。
如果系统磁盘快满了,可能会影响系统性能。我们可以采取以下措施来解决这个问题:1. 删除不需要的文件或程序以释放磁盘空间。可以使用磁盘清理工具或手动删除文件。
2. 移动一些较大的文件到外部存储设备上。例如,将照片、视频等移动到 USB 或外置硬盘。
3. 优化数据库,减少其大小。可以采用数据压缩、分区等方法。
4. 使用云存储技术,将数据存储在云端,减少本地磁盘占用。
5. 增加磁盘空间,可以考虑更换更大容量的硬盘或扩展磁盘空间。
以上方法都可以帮助缓解系统磁盘快满的问题,同时实时读取数据库数据也不会受到太大影响
MRR 是 MySQL 针对特定查询的一种优化手段。假设一个查询有二级索引可用,读完二级索引后要回表才能查到那些不在当前二级索引上的列值,由于二级索引上引用的主键值不一定是有序的,因此就有可能造成大量的随机 IO,如果回表前把主键值给它排一下序,那么在回表的时候就可以用顺序 IO 取代原本的随机 IO。如果想关闭 MRR 优化的话,就要把优化器开关 mrr 设置为 off。
默认只有在优化器认为 MRR 可以带来优化的情况下才会走 MRR,如果你想不管什么时候能走 MRR 的都走 MRR 的话,你要把 mrr_cost_based 设置为 off,不过最好不要这么干,因为这确实是一个坑,MRR 不一定什么时候都好,全表扫描有时候会更加快,如果在这种场景下走 MRR 就完成了。
MRR 要把主键排个序,这样之后对磁盘的 *** 作就是由顺序读代替之前的随机读。从资源的使用情况上来看就是让 CPU 和内存多做点事,来换磁盘的顺序读。然而排序是需要内存的,这块内存的大小就由参数 read_rnd_buffer_size 来控制。
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)