MySQL: 17 MySQL是如何将LRU链表的使用性能优化到极致的?

1. LRU链表的冷数据区域都是什么数据

大部分都是预读加载进来的缓存页,加载进来1s之后都没人访问的,然后包括全表扫描或者一些大的查询语句,加载一堆数据到缓存页,结果都是 1s 之内访问了一下,后续就不再访问这些表的数据了。

类似这些数据,统统都会放在冷数据区域里。

2. Redis里存放了很多缓存数据,是否也有类似冷热数据的问题?如何优化和解决?

以电商系统里的商品缓存数据为例,假设有1亿个商品,如果只要发起查询的商品都放到缓存里去,必然导致大量访问率低的商品都会被放在Redis里去。

经常被访问的商品其实就是热数据,而不经常访问的商品就是冷数据,实际上应该让Redis里放到都是经常访问的热数据,而不是大量的冷数据。

所以在设计缓存机制的时候,需要考虑热数据的缓存预加载。

也就是说,每天统计出哪些商品被访问的次数最多,然后当天晚上有系统启动一个定时工作,把这些热门商品的数据预加载到Redis里。那么第二天热门的商品的访问就会优先走Redis缓存了。

3. LRU链表的热数据区域进行的优化

在热数据区域中,如果访问了一个缓存页,不能立刻把它转移到热数据区域的链表头部去。因为热数据区域里的缓存页可能是经常被访问的,如果经常这么频繁的进行移动对性能的影响会很大。

对于这个问题,LRU链表的热数据区域的访问规则进行了优化,也就是只有在热数据区域的后 3/4 部分的缓存页都被访问了,才会给你移动到链表头部去。

如果是热数据区域的前面1/4 的缓存页被访问,它是不会一定到链表头部去的。

通过这种方式,可以尽可能的减少链表中的节点移动。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值