深度分页 - MySQL limit 200000会有什么问题

后端开发中最场景的需求就是分页查询了,那无脑分页就万事大吉了吗?当大数据量查询场景下,如果 limit 200000, 10 会不会有问题呢?

深度分页

limit 200000, 10 到底会不会有问题呢?光说不练假把式,来,操作起来先!

mysql> CREATE TABLE `order_detail` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `user_id` varchar(50) NOT NULL DEFAULT '' COMMENT '用户ID',
  `order_id` bigint(20) DEFAULT NULL COMMENT '订单id',
  `sku_id` bigint(20) unsigned NOT NULL COMMENT '商品ID',
  `order_time` datetime DEFAULT NULL COMMENT '下单时间,格式yyyy-MM-dd HH:mm:ss',
  PRIMARY KEY (`id`),
  KEY `idx_time_user` (`order_time`,`user_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin COMMENT='订单详情';

执行计划Extra列可能出现的值

  1. Using where:优化器需要通过索引回表查询
  2. Using Index:覆盖索引,即根据索引树可直接检索列信息,无需额外的操作来读取实际的行
  3. Using index condition:索引下推,在MySQL5.6后出现,充分利用了索引中的数据,尽量在查询出整行数据之前过滤掉无效的数据
  4. Backward index scan:对索引列使用了降序操作
  5. Using index for group_by:只查索引列,对索引列使用了 group by
  6. Using filesort:文件排序,一般在 order by 数据量多大时出现,MySQL会将所有数据召回内存中排序,比较消耗资源
  7. using temporary:使用了临时表,一般在使用group by、order by时会遇到

针对limit 100 和 limit 200000 分别执行查询及执行计划(mysql版本:8.0.26):
limit优化前

结合上图,同样的语句,不同的偏移量,结果执行计划相差巨大。

  • limit 100, 10时,type列为range,表示范围扫描,性能比ref差一个级别,但是走了索引,使用了索引下推;
  • limit 200000, 10时,type列为all,做了全表扫描,Extra里Using where发生了回表,Using filesort表示order by时发生了文件排序。

这里limit 200000, 10由于limit偏移量过大,引起以下两个问题,进而影响查询性能:

  • 文件排序耗时过大
  • 根据条件筛选了相关的数据之后,需要根据偏移量回表获取全部值

对比上面两个sql的查询时间可知,分页深度越深,就越耗时。第2条sql,每次至少要查询9w多条数据,取其中的1条数据,其余的数据丢失掉,非常耗时,这就是深度分页的问题。

优化方案

针对主键自增型的分页查询优化

限制id法:取上页中最大id,然后根据最大id进行分页查询

mysql> select * from order_detail where id > 200000 limit 10;

优化后的sql执行耗时降低了很多,有明显的效率提升的。
这种方案的限制条件

  • id单调性且无重复数据
  • 不支持随机跳页
    limit优化后

针对主键非自增型的分页查询优化

很多业务场景,不是通过主键id分页查询的,而是由多个组合条件构成分页查询条件,这种情况下我们可以通过延迟关联来处理。
延迟关联:通过子查询查询出当前页的id,然后再根据当前页id回表查询所需字段。查询当前页id用到了索引,遍历索引树还是很快的。该方案很好的避免了限制id法的使用条件,经常被用于后端的管理平台,来看个具体sql和执行计划:

mysql> select od.id,user_id,order_id,sku_id,order_time from order_detail as od inner join (select id FROM order_detail limit 200000, 10) as b on od.id = b.id;

从执行计划上能看出,子查询用到了覆盖索引,整个过程遍历索引还是很快的。

从业务角度规避深度分页

我们也可以换个角度,既然问题不好解决,那是不是也可以提前规避问题呢?
方法肯定是有的,技术上不好解决,那就通过业务来规避问题。比如,可以采用如下措施:

  • 增加默认筛选条件,来减少展示的数据量。
  • 滚动展示,避免跳页,例如:限制id法。
    必应分页示例

    如上图,必应搜索就默认展示5页,屏蔽掉了跳页功能(虽然底层实现不同,但是逻辑类似)。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,542评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,596评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 158,021评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,682评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,792评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,985评论 1 291
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,107评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,845评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,299评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,612评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,747评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,441评论 4 333
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,072评论 3 317
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,828评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,069评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,545评论 2 362
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,658评论 2 350