关于mysql的offset

关于mysql的offset,第1张

offset(偏移量)这个一般是在分页会用到,而且用也不是这样单独的。取一条数据应该是:select * from user limi 1取1至10条:select * from user limi 1,10 //后面的10就相当于offset

limit x, y:表示跳过x个数据读取y个数据

limit x offset y:表示跳过y个数据读取x个数据,offset表示偏移量

limit x:表示从头开始读取x个数据,相当于limit 0,x

在写 select 语句的时候,使用 limit, offset 可能就像是我们吃饭喝水一样自然了。

刚开始工作的时候也经常听前辈们教导:使用 limit, offset,当 offset 变大的时候执行效率会越来越低。

相信在前辈们的言传身教,和自己的实战过程中,大家也都知道了为什么会这样。

因为 select 在执行过程中,对于存储引擎返回的记录,经过 server 层的 WHERE 条件筛选之后,符合条件的前offset 条记录,会被直接无情的抛弃,直到符合条件的第 offset + 1 条记录,才开始发送给客户端,发送了 limit 条记录之后,查询结束。

虽然知道了是什么,也知道了为什么,但是我也一直好奇底层是怎么实现的,所以今天我们来扒一扒它的庐山真面目。

先来简单的回顾一下 select 语句中 limit, offset 的语法,MySQL 支持 3 种形式:

在读取数据的过程中,对于符合条件的前offset 条记录,会直接忽略,不发送给客户端,从符合条件的第 offset + 1 条记录开始,发送 limit 条记录给客户端。

所以,server 层实际上需要从存储引擎读取offset + limit 条记录,源码里也是这么实现的,语法解析阶段,在验证了 offset 和 limit 都是大于等于 0 的整数之后,就把 offset + limit 的计算结果保存到一个叫做 select_limit_cnt 的属性里,offset 也会保存到一个叫做 offset_limit_cnt 的属性里。

来到发送数据阶段,此时的记录已经通过了 WHERE 条件的筛选,接下来就是判断这条记录是不是要发送给客户端。

第 1 步

因为 offset 已经保存到offset_limit_cnt 中了,先来判断 offset_limit_cnt 是否大于 0,如果大于 0,这条记录就会被抛弃了,不发送给客户端;如果等于 0,记录就具备了发送给客户端的资格了,然后接着进入 第 2 步 。

第 2 步

来到这一步,记录就具备了发送给客户端的资格了,至于要不要发,就看客户端想不想要它了,而客户端想不想要它,取决于select_limit_cnt 。

所以,在这一步要判断 已发送记录数量 (send_records)和 需要发送记的录数量 (select_limit_cnt)之间的关系,如果已发送记录数量 大于等于 需要发送的记录数量,则结束查询,否则就接着进入第 3 步。

第 3 步

在这里,记录愉快的等待着被发送给客户端。

既然在offset 变大之后,使用 limit, offset 效率越来越低,那应该怎么办呢?对于实战经验丰富的小伙伴来说,这是相当简单了,但是以防万一刚看到本文的小伙伴是刚刚开始用 SQL 写 Bug,所以还是要大概的写一下的。

以一个 SQL 为例:

为了取到 10 条记录,要先找到 8888 条记录,然后取到需要的 10 条,前面 8888 条记录都白找了,太浪费了,可以这样修改一下:

LAST_MAX_ID 是上一次执行 SQL 时读取到的 主键 ID 的最大值,如果是第一次执行语句, LAST_MAX_ID = 0 。

不过这种方案也有个问题,不支持跳着翻页,只支持顺序翻页(就是每次都点 下一页 的这种)。

如果要支持跳着翻页,怎么办?

只用 MySQL 这把锤子显然有点不够用了,还要再找一把锤子(Redis),可以把符合条件的记录的 主键 ID 都读取出来,存入到 Redis 的有序集合(zset)中,用 zset 相应的函数读取到某一页应该展示的数据对应的那些 主键 ID ,然后用这些主键 ID 去 MySQL 中查询对应的数据,从而用两把锤子间接的实现了分页功能。

当然,这个方案也是有适用场景的,比如,这个方案明显就不适用于这些场景:符合条件的记录非常非常多导致存主键 ID 到 Redis 要占用很大的内存、记录更新频繁导致存主键 ID 的缓存经常被清除。如果碰到更复杂的场景,就要结合业务具体情况具体分析了


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/6109804.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-15
下一篇 2023-03-15

发表评论

登录后才能评论

评论列表(0条)

保存