MySQL 查询 limit 1000,10 和 limit 10 速度一样快吗? 深度分页如何破解
Hollis的新书限时折扣中,一本深入讲解Java基础的干货笔记!
刷网站的时候,我们经常会遇到需要分页查询的场景。
比如下图红框里的翻页功能。
我们很容易能联想到可以用mysql实现。
假设我们的建表sql是这样的
建表sql大家也不用扣细节,只需要知道id是主键,并且在user_name建了个非主键索引就够了,其他都不重要。
为了实现分页。
很容易联想到下面这样的sql语句。
select * from page order by id limit offset, size;
比如一页有10条数据。
第一页就是下面这样的sql语句。
select * from page order by id limit 0, 10;
第一百页就是
select * from page order by id limit 990, 10;
那么问题来了。
用这种方式,同样都是拿10条数据,查第一页和第一百页的查询速度是一样的吗?为什么?
两种limit的执行过程
上面的两种查询方式。对应 limit offset, size
和 limit size
两种方式。
而其实 limit size
,相当于 limit 0, size
。也就是从0开始取size条数据。
也就是说,两种方式的区别在于offset是否为0。
我们先来看下limit sql的内部执行逻辑。
mysql内部分为server层和存储引擎层。一般情况下存储引擎都用innodb。
server层有很多模块,其中需要关注的是执行器是用于跟存储引擎打交道的组件。
执行器可以通过调用存储引擎提供的接口,将一行行数据取出,当这些数据完全符合要求(比如满足其他where条件),则会放到结果集中,最后返回给调用mysql的客户端(go、java写的应用程序)。
我们可以对下面的sql先执行下 explain
。
explain select * from page order by id limit 0, 10;
可以看到,explain中提示 key 那里,执行的是PRIMARY,也就是走的主键索引。
主键索引本质是一棵B+树,它是放在innodb中的一个数据结构。
我们可以回忆下,B+树大概长这样。
在这个树状结构里,我们需要关注的是,最下面一层节点,也就是叶子结点。而这个叶子结点里放的信息会根据当前的索引是主键还是非主键有所不同。
如果是主键索引,它的叶子节点会存放完整的行数据信息。
如果是非主键索引,那它的叶子节点则会存放主键,如果想获得行数据信息,则需要再跑到主键索引去拿一次数据,这叫回表。
比如执行
select * from page where user_name = "小白10";
会通过非主键索引去查询user_name为"小白10"的数据,然后在叶子结点里找到"小白10"的数据对应的主键为10。
此时回表到主键索引中做查询,最后定位到主键为10的行数据。
但不管是主键还是非主键索引,他们的叶子结点数据都是有序的。比如在主键索引中,这些数据是根据主键id的大小,从小到大,进行排序的。
基于主键索引的limit执行过程
那么回到文章开头的问题里。
当我们去掉explain,执行这条sql。
select * from page order by id limit 0, 10;
上面select后面带的是星号*,也就是要求获得行数据的所有字段信息。
server层会调用innodb的接口,在innodb里的主键索引中获取到第0到10条完整行数据,依次返回给server层,并放到server层的结果集中,返回给客户端。
而当我们把offset搞离谱点,比如执行的是
select * from page order by id limit 6000000, 10;
server层会调用innodb的接口,由于这次的offset=6000000,会在innodb里的主键索引中获取到第0到(6000000 + 10)条完整行数据,返回给server层之后根据offset的值挨个抛弃,最后只留下最后面的size条,也就是10条数据,放到server层的结果集中,返回给客户端。
可以看出,当offset非0时,server层会从引擎层获取到很多无用的数据,而获取的这些无用数据都是要耗时的。
因此,我们就知道了文章开头的问题的答案,mysql查询中 limit 1000,10 会比 limit 10 更慢。原因是 limit 1000,10 会取出1000+10条数据,并抛弃前1000条,这部分耗时更大
那这种case有办法优化吗?
可以看出,当offset非0时,server层会从引擎层获取到很多无用的数据,而当select后面是*号时,就需要拷贝完整的行信息,拷贝完整数据跟只拷贝行数据里的其中一两个列字段耗时是不同的,这就让原本就耗时的操作变得更加离谱。
因为前面的offset条数据最后都是不要的,就算将完整字段都拷贝来了又有什么用呢,所以我们可以将sql语句修改成下面这样。
select * from page where id >=(select id from page order by id limit 6000000, 1) order by id limit 10;
上面这条sql语句,里面先执行子查询 select id from page order by id limit 6000000, 1
, 这个操作,其实也是将在innodb中的主键索引中获取到6000000+1
条数据,然后server层会抛弃前6000000条,只保留最后一条数据的id。
但不同的地方在于,在返回server层的过程中,只会拷贝数据行内的id这一列,而不会拷贝数据行的所有列,当数据量较大时,这部分的耗时还是比较明显的。
在拿到了上面的id之后,假设这个id正好等于6000000,那sql就变成了
select * from page where id >=(6000000) order by id limit 10;
这样innodb再走一次主键索引,通过B+树快速定位到id=6000000的行数据,时间复杂度是lg(n),然后向后取10条数据。
这样性能确实是提升了,亲测能快一倍左右,属于那种耗时从3s变成1.5s的操作。
这······
属实有些杯水车薪,有点搓,属于没办法中的办法。
基于非主键索引的limit执行过程
上面提到的是主键索引的执行过程,我们再来看下基于非主键索引的limit执行过程。
比如下面的sql语句
select * from page order by user_name limit 0, 10;
server层会调用innodb的接口,在innodb里的非主键索引中获取到第0条数据对应的主键id后,回表到主键索引中找到对应的完整行数据,然后返回给server层,server层将其放到结果集中,返回给客户端。
而当offset>0时,且offset的值较小时,逻辑也类似,区别在于,offset>0时会丢弃前面的offset条数据。
也就是说非主键索引的limit过程,比主键索引的limit过程,多了个回表的消耗。
但当offset变得非常大时,比如600万,此时执行explain。
可以看到type那一栏显示的是ALL,也就是全表扫描。
这是因为server层的优化器,会在执行器执行sql语句前,判断下哪种执行计划的代价更小。
很明显,优化器在看到非主键索引的600w次回表之后,摇了摇头,还不如全表一条条记录去判断算了,于是选择了全表扫描。
因此,当limit offset过大时,非主键索引查询非常容易变成全表扫描。是真·性能杀手。
这种情况也能通过一些方式去优化。比如
select * from page t1, (select id from page order by user_name limit 6000000, 100) t2 WHERE t1.id = t2.id;
通过select id from page order by user_name limit 6000000, 100
。先走innodb层的user_name非主键索引取出id,因为只拿主键id,不需要回表,所以这块性能会稍微快点,在返回server层之后,同样抛弃前600w条数据,保留最后的100个id。然后再用这100个id去跟t1表做id匹配,此时走的是主键索引,将匹配到的100条行数据返回。这样就绕开了之前的600w条数据的回表。
当然,跟上面的case一样,还是没有解决要白拿600w条数据然后抛弃的问题,这也是非常挫的优化。
像这种,当offset变得超大时,比如到了百万千万的量级,问题就突然变得严肃了。
这里就产生了个专门的术语,叫深度分页。
深度分页问题
深度分页问题,是个很恶心的问题,恶心就恶心在,这个问题,它其实无解。
不管你是用mysql还是es,你都只能通过一些手段去"减缓"问题的严重性。
遇到这个问题,我们就该回过头来想想。
为什么我们的代码会产生深度分页问题?
它背后的原始需求是什么,我们可以根据这个做一些规避。
如果你是想取出全表的数据
有些需求是这样的,我们有一张数据库表,但我们希望将这个数据库表里的所有数据取出,异构到es,或者hive里,这时候如果直接执行
select * from page;
这个sql一执行,狗看了都摇头。
因为数据量较大,mysql根本没办法一次性获取到全部数据,妥妥超时报错。
于是不少mysql小白会通过limit offset size
分页的形式去分批获取,刚开始都是好的,等慢慢地,哪天数据表变得奇大无比,就有可能出现前面提到的深度分页问题。
这种场景是最好解决的。
我们可以将所有的数据根据id主键进行排序,然后分批次取,将当前批次的最大id作为下次筛选的条件进行查询。
可以看下伪代码
这个操作,可以通过主键索引,每次定位到id在哪,然后往后遍历100个数据,这样不管是多少万的数据,查询性能都很稳定。
如果是给用户做分页展示
如果深度分页背后的原始需求只是产品经理希望做一个展示页的功能,比如商品展示页,那么我们就应该好好跟产品经理battle一下了。
什么样的翻页,需要翻到10多万以后,这明显是不合理的需求。
是不是可以改一下需求,让它更接近用户的使用行为?
比如,我们在使用谷歌搜索时看到的翻页功能。
一般来说,谷歌搜索基本上都在20页以内,作为一个用户,我就很少会翻到第10页之后。
作为参考。
如果我们要做搜索或筛选类的页面的话,就别用mysql了,用es,并且也需要控制展示的结果数,比如一万以内,这样不至于让分页过深。
如果因为各种原因,必须使用mysql。那同样,也需要控制下返回结果数量,比如数量1k以内。
这样就能勉强支持各种翻页,跳页(比如突然跳到第6页然后再跳到第106页)。
但如果能从产品的形式上就做成不支持跳页会更好,比如只支持上一页或下一页。
这样我们就可以使用上面提到的start_id方式,采用分批获取,每批数据以start_id为起始位置。这个解法最大的好处是不管翻到多少页,查询速度永远稳定。
听起来很挫?
怎么会呢,把这个功能包装一下。
变成像抖音那样只能上划或下划,专业点,叫瀑布流。
是不是就不挫了?
总结
limit offset, size
比limit size
要慢,且offset的值越大,sql的执行速度越慢。当offset过大,会引发深度分页问题,目前不管是mysql还是es都没有很好的方法去解决这个问题。只能通过限制查询数量或分批获取的方式进行规避。
遇到深度分页的问题,多思考其原始需求,大部分时候是不应该出现深度分页的场景的,必要时多去影响产品经理。
如果数据量很少,比如1k的量级,且长期不太可能有巨大的增长,还是用
limit offset, size
的方案吧,整挺好,能用就行。
完
我的新书《深入理解Java核心技术》已经上市了,上市后一直蝉联京东畅销榜中,目前正在6折优惠中,想要入手的朋友千万不要错过哦~长按二维码即可购买~
长按扫码享受6折优惠
往期推荐
进入 SpringBoot2.7,有一个重要的类过期了
几个对程序员的误解,害人不浅!
恕我直言:程序员大部分时间不是在写代码,而是。。。
有道无术,术可成;有术无道,止于术
欢迎大家关注Java之道公众号
好文章,我在看❤️
MySQL 查询 limit 1000,10 和 limit 10 速度一样快吗? 深度分页如何破解相关推荐
- C语言实验——逆置正整数 Time Limit: 1000 ms Memory Limit: 65536 KiB 1189
C语言实验--逆置正整数 Time Limit: 1000 ms Memory Limit: 65536 KiB Problem Description 输入一个三位正整数,将它反向输出. Input ...
- 团战可以输、提莫必须死 Time Limit: 1000 ms Memory Limit: 65536 KiB
Problem Description 为了一些你们不知道的原因,我们把LOL的地图抽象为一个n×m的矩阵 提莫积攒了k个蘑菇准备种到地图上去,因为提莫的背篓漏了,所以每一个提莫走过的 ...
- MySQL查询 limit 1000,10 和limit 10 速度一样快吗?
刷网站的时候,我们经常会遇到需要分页查询的场景. 比如下图红框里的翻页功能. 我们很容易能联想到可以用mysql实现. 假设我们的建表sql是这样的 mysql建表sql 建表sql大家也不用扣细节, ...
- mysql查询到最新记录就停止_使用Limit参数优化MySQL查询 在找到一个记录后将停止查询...
优化 MySQL 查询的 Limit 参数 我们在做一些查询的时候总希望能避免数据库引擎做全表扫描,因为全表扫描时间长,而且其中大部分扫描对客户端而言是没有意义的.那么在 MySQL 中有那些方式是可 ...
- mysql查询 百万_MySQL百万级数据分页查询优化
前言 当需要从数据库查询的表有上万条记录的时候,一次性查询所有结果会变得很慢,特别是随着数据量的增加特别明显,这时需要使用分页查询.对于数据库分页查询,也有很多种方法和优化的点.下面简单说一下我知道的 ...
- 如何根据分页的当前页数查询数据_数据量很大的情况下,如何分页查询优化方案?...
当需要从数据库查询的表有上万条记录的时候,一次性查询所有结果会变得很慢,特别是随着数据量的增加特别明显,这时需要使用分页查询.对于数据库分页查询,也有很多种方法和优化的点.下面简单说一下我知道的一些方 ...
- db2分页查询语句优化_面试官:数据量很大,分页查询很慢,怎么优化?
当需要从数据库查询的表有上万条记录的时候,一次性查询所有结果会变得很慢,特别是随着数据量的增加特别明显,这时需要使用分页查询.对于数据库分页查询,也有很多种方法和优化的点. 下面简单说一下我知道的一些 ...
- ElasticSearch 分页查询及深度分页原理与实现
查询流程 查询阶段 在初始化查询阶段(query phase),查询被向索引中的每个分片副本(原本或副本)广播.每个分片在本地执行搜索并且建 立了匹配 document 的优先队列(priority ...
- ES深度分页查询详解
一.ES支持的三种分页查询方式 From + Size 查询 Scroll 遍历查询 Search After 查询 说明: 官方已经不再推荐采用Scroll API进行深度分页.如果遇到超过1000 ...
最新文章
- 8、进程通信-匿名管道
- 跳槽季,TurboMail邮件系统支招防员工邮件泄密
- 射频全网通笔记(附全球频段划分及主要运营商对应表)
- 修改element默认样式_ggplot2作图:修改主题元素的外观样式(整体修改)
- ibatis插入正确但查询不出数据的问题
- C语言 有符号字符型输出 面试题
- Editor:实用的在线编辑器(WYSIWYG Editor)
- docker mysql开机自启动_Docker 学会让容器开机自启服务
- 常用配置文件格式比较
- python自顶向下设计步骤_python自底向上的执行单元测试
- unity协程_[C#进阶]C#实现类似Unity的协程
- 如果是自学WEB前端的话,该如何才能找到一份7K实习生工作呢?
- ipad导入pdf_Ipad笔记法①日常笔记篇
- integer为null_走进 JDK 之 Integer
- 【李宏毅2020 ML/DL】P106 More about Life Long Learning
- CCF201604-4 游戏(100分)
- 力扣-62 不同路径
- [Java] 使用HttpClient实现文件下载
- IPV4组播地址解析以及IPV4地址详解
- 域计算机软件安装统计,如何通过SCCM查找客户端计算机已安装的软件清单
热门文章
- Visual Studio 2019下载、安装、使用
- 服务器缓存多会影响网速吗,路由器长时间工作,会导导致网速变慢,那如何才能让网速恢复?...
- 前端 img图片如何 展示 base64 格式(并且下载到本地)
- DB2 OLAP函数的使用
- 入手评测 华为2021款MatePad Pro 10.8和12.6的区别
- 突发!微软亚研CV大牛王井东离职!或将加入百度
- 计算机图形学 第三章 几何造型
- 华为路由器OSPF综合实验
- 一句话简述border-box和content-box的区别
- 关于Ubuntu22.04没有WiFi图标或未找到WiFi适配器