随着用户对数据访问速度的日益重视,MySQL 数据库在最初的设计中,采用了线性预读的方式,提前将即将使用的数据预读到 Buffer pool 中,来提升数据的访问速度,但在实际使用过程中,线性预读失效的问题愈来愈突出。
对于存在时间比较长,变更又比较频繁的表,除非我们对于这张表进行重建,否则该表会存在大量的数据碎片,导致数据存放不连续,这样会使 MySQL 原有的线性预读功能失效,导致某些查询语句变很慢,如:全表扫描,范围扫描等。
线性预读存在的问题
频繁变更操作会破坏数据的连续性
一般情况下,当我们在数据存放连续时执行全表扫描,数据库就会异步地把这些数据从磁盘加载到 Buffer pool,从而提高数据库的处理速度。
比如当我们访问了 Row A1,Row A2,Row A3 时,数据库会认为你下次有极大的概率去访问 Row A4,Row A5,Row A6,从而自动异步地把这些数据加载到 Buffer pool 中。
但如果在这张表上频繁地执行变更操作,则会破坏数据的连续性。在我们访问 Row A1,Row A2,Row A3 时,数据库发现这三行数据并不连续,所以数据库不会提前将 Row A5,Row A6 从磁盘异步地加载到 Buffer pool,只能一个一个的去请求、加载,从而影响访问效率。数据连续时,访问 500w Row 数据需要 12s,但是数据不连续时,访问 500w Row 数据需要 34s。
对于在线应用来说,重建表会产生较大的运维风险,数据面临丢失的可能。那到底有没有什么特性可以在不重建表的情况下,弥补线性预读失效的问题呢?
线性预读的失效催生出
“逻辑预读”特性
华为云 RDS 数据库服务,新开发了“逻辑预读”特性,在不重建表的情况下,弥补线性预读失效的问题,从而提高分析型业务的执行效率。
“逻辑预读”特性,在预读数据的时候,首先通过对要预读的数据的页号进行排序,去除数据不连续的影响,然后合并相邻数据页的 IO 请求,减少磁盘 IO 的总请求次数,从而提高数据预读的命中率和效率。
华为云数据库团队做了一个测试:采用 8 核 16GB 100GB SSD 规格的 Linux 机器,测试 2.4GB 大小 500w Rows 存在碎片的数据,执行 select *from tablename(全表扫描查询),结果如下:
由此可见,相比开源版本,华为云 MySQL 逻辑预读特性大大缩短了访问时长,极大提升了执行效率,为分析型业务的进一步发展注入了新动力。
每一个改变都是为了更好的服务客户,华为云 MySQL 逻辑预读特性的推出,不仅很好地弥补了线性预读的失效问题,提升了分析型业务的执行效率,更是为客户的业务场景保驾护航,助力其创新发展,实现更多价值。
本文转载自 HW 云数据库公众号。
原文链接:https://mp.weixin.qq.com/s/38Yc3K2jOODgyKLP8D3siA
评论