0
  • 聊天消息
  • 系统消息
  • 评论与回复
登录后你可以
  • 下载海量资料
  • 学习在线课程
  • 观看技术视频
  • 写文章/发帖/加入社区
会员中心
创作中心

完善资料让更多小伙伴认识你,还能领取20积分哦,立即完善>

3天内不再提示

为什么分页场景下mysql请求速度非常慢

Android编程精选 来源:掘金 作者:牛牛码特 2021-10-08 14:46 次阅读
加入交流群
微信小助手二维码

扫码添加小助手

加入工程师交流群

来源丨https://juejin.cn/post/6844903939247177741

从一个问题说起五年前在tx的时候,发现分页场景下,mysql请求速度非常慢。数据量只有10w的情况下,select xx from 单机大概2,3秒。我就问我导师为什么,他反问“索引场景,mysql中获得第n大的数,时间复杂度是多少?”

答案的追寻确认场景假设status上面有索引。select * from table where status = xx limit 10 offset 10000。会非常慢。数据量不大的情况就有几秒延迟。

小白作答瞎猜了个log(N),心想找一个节点不就是log(N)。自然而然,导师让我自己去研究。

这一阶段,用了10分钟。

继续解答仔细分析一下,会发现通过索引去找很别扭。因为你不知道前100个数在左子树和右子数的分布情况,所以其是无法利用二叉树的查找特性。通过学习,了解到mysql的索引是b+树。

0c76bb4e-23df-11ec-82a8-dac502259ad0.png

看了这个图,就豁然开朗了。可以直接通过叶子节点组成的链表,以o(n)的复杂度找到第100大的树。但是即使是o(n),也不至于慢得令人发指,是否还有原因。

这一阶段,主要是通过网上查资料,断断续续用了10天。

系统学习这里推荐两本书,一本《MySQL技术内幕 InnoDB存储引擎》,通过他可以对InnoDB的实现机制,如mvcc,索引实现,文件存储会有更深理解。

第二本是《高性能MySQL》,这本书从着手使用层面,但讲得比较深入,而且提到了很多设计的思路。

两本书相结合,反复领会,mysql就勉强能登堂入室了。

这里有两个关键概念:

聚簇索引:包含主键索引和对应的实际数据,索引的叶子节点就是数据节点

辅助索引:可以理解为二级节点,其叶子节点还是索引节点,包含了主键id。

即使前10000个会扔掉,mysql也会通过二级索引上的主键id,去聚簇索引上查一遍数据,这可是10000次随机io,自然慢成哈士奇。这里可能会提出疑问,为什么会有这种行为,这是和mysql的分层有关系,limit offset 只能作用于引擎层返回的结果集。换句话说,引擎层也很无辜,他并不知道这10000个是要扔掉的。以下是mysql分层示意图,可以看到,引擎层和server层,实际是分开的。

直到此时,大概明白了慢的原因。这一阶段,用了一年。

触类旁通此时工作已经3年了,也开始看一些源码。在看完etcd之后,看了些tidb的源码。无论哪种数据库,其实一条语句的查询,是由逻辑算子组成。

逻辑算子介绍 在写具体的优化规则之前,先简单介绍查询计划里面的一些逻辑算子。

DataSource 这个就是数据源,也就是表,select * from t 里面的 t。

Selection 选择,例如 select xxx from t where xx = 5 里面的 where 过滤条件。

Projection 投影, select c from t 里面的取 c 列是投影操作。

Join 连接, select xx from t1, t2 where t1.c = t2.c 就是把 t1 t2 两个表做 Join。

选择,投影,连接(简称 SPJ) 是最基本的算子。其中 Join 有内连接,左外右外连接等多种连接方式。

select b from t1, t2 where t1.c = t2.c and t1.a 》 5 变成逻辑查询计划之后,t1 t2 对应的 DataSource,负责将数据捞上来。上面接个 Join 算子,将两个表的结果按 t1.c = t2.c连接,再按t1.a 》 5做一个 Selection 过滤,最后将 b 列投影。下图是未经优化的表示:

所以说不是mysql不想把limit, offset传递给引擎层,而是因为划分了逻辑算子,所以导致无法直到具体算子包含了多少符合条件的数据。

怎么解决《高性能MySQL》提到了两种方案

方案一

根据业务实际需求,看能否替换为下一页,上一页的功能,特别在iosandroid端,以前那种完全的分页是不常见的。这里是说,把limit, offset,替换为》辅助索引(即搜索条件)id的方式。该id再调用时,需要返回给前端。

方案二

正面刚。这里介绍一个概念:索引覆盖:当辅助索引查询的数据,只有id和辅助索引本身,那么就不必再去查聚簇索引。

思路如下:select xxx,xxx from in (select id from table where second_index = xxx limit 10 offset 10000) 这句话是说,先从条件查询中,查找数据对应的数据库唯一id值,因为主键在辅助索引上就有,所以不用回归到聚簇索引的磁盘去拉取。再通过这些已经被limit出来的10个主键id,去查询聚簇索引。这样只会十次随机io。在业务确实需要用分页的情况下,使用该方案可以大幅度提高性能。通常能满足性能要求。

责任编辑:haq

声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉
  • 数据
    +关注

    关注

    8

    文章

    7378

    浏览量

    95290
  • SQL
    SQL
    +关注

    关注

    1

    文章

    810

    浏览量

    47097

原文标题:分页场景(limit,offset)为什么会慢?

文章出处:【微信号:AndroidPush,微信公众号:Android编程精选】欢迎添加关注!文章转载请注明出处。

收藏 人收藏
加入交流群
微信小助手二维码

扫码添加小助手

加入工程师交流群

    评论

    相关推荐
    热点推荐

    系统讲解MySQL数据库查询优化思路

    MySQL 是业务系统最常用的数据库,跑着跑着突然接口超时、数据库 CPU 飙升、连接数打满,这些问题排查思路是什么?本文从运维角度出发,讲清楚 MySQL 查询的分析方法、索引优化思路、配置参数
    的头像 发表于 05-30 13:53 155次阅读

    系统讲解MySQL查询的完整排查流程

    MySQL 查询是影响业务响应速度的最常见根因。业务高峰期一次看似简单的 SELECT 查询,可能拖整个系统——前端页面加载转圈、API 超时、后台任务堆积、数据库连接池耗尽。更要
    的头像 发表于 05-11 16:50 362次阅读

    MySQL数据库查询的排查思路和最佳实践

    数据库查询是导致应用响应缓慢最常见的原因之一。当业务人员反馈“页面加载”、“查询超时”、“系统卡顿”时,很多运维人员的第一反应是让开发人员“加个索引”。但加索引只是优化查询的众多手段之一,盲目加索引不仅可能无效,还可能适得其反。
    的头像 发表于 04-24 14:40 254次阅读

    华益精点亮相CMEF 病管理全场景方案惊艳焕新

    华益精点亮相CMEF 病管理全场景方案惊艳焕新
    的头像 发表于 04-14 14:31 272次阅读
    华益精点亮相CMEF <b class='flag-5'>慢</b>病管理全<b class='flag-5'>场景</b>方案惊艳焕新

    MySQL查询调优指南

    MySQL查询是数据库性能问题的最常见原因。当一条SQL语句执行超过1秒时,就可能影响用户体验;超过10秒时,通常会收到用户投诉;而超过30秒的查询,往往意味着系统存在严重的性能问题。本文从实
    的头像 发表于 04-09 10:01 280次阅读

    MySQL数据库查询分析与优化实战

    在讨论MySQL查询之前,需要先明确一个关键前提:什么是查询? 不同业务场景查询的定义
    的头像 发表于 04-02 09:38 345次阅读

    MESA 重新编译后 GUI 非常,如何恢复?

    编译它。 但是,在安装 MESA 库并重新启动后,所有 GUI 都非常,所以我认为我在某个时候错过了一些加速驱动程序(从那里开始我不清楚)。从我安装的 MESA 库中,我只在 /usr/local
    发表于 03-31 08:11

    哪些人更适合用 NineData 社区版的 SQL 功能:DBA、后端、SRE,还是技术负责人?

    本文只讨论在 MySQL SQL 场景的使用边界。NineData 社区版支持离线部署、Docker 单机部署,数据库 DevOps 提供 10 个数据源可用额度,核心功能与专业
    的头像 发表于 03-19 23:15 468次阅读

    NineData 社区版的SQL分析,比查看日志+看EXPLAIN适合中小团队

    本文探讨 NineData 社区版在 MySQL SQL 场景对中小团队的适用性。与 “查看日志 + 看 EXPLAIN” 传统方式不同,它将 SQL 按模板聚合,能从大盘、模板
    的头像 发表于 03-17 14:07 206次阅读
    NineData 社区版的<b class='flag-5'>慢</b>SQL分析,比查看日志+看EXPLAIN适合中小团队

    MySQL SQL 排查这件事,NineData 社区VS DBeaver/ Navicat 技术分析

    社区版的定位不同,它是免费、本地化部署的数据管理平台,将数据库 DevOps、数据复制、数据库对比三大能力整合于一体。 在 MySQL SQL 这条链路里,它用到的是 DevOps 中的查询分析
    的头像 发表于 03-17 11:53 239次阅读
    <b class='flag-5'>MySQL</b> <b class='flag-5'>慢</b> SQL 排查这件事,NineData 社区VS DBeaver/ Navicat 技术分析

    MySQL查询分析与索引调优全流程

    MySQL 性能问题在生产环境中的表现通常是渐进式的:业务量增长、数据量膨胀,某天突然发现 P99 响应时间从 50ms 涨到 2s。查询是最常见的根因,而索引设计不合理又是查询的主要来源。
    的头像 发表于 03-06 15:56 357次阅读

    MySQL查询终极优化指南

    作为一名在生产环境摸爬滚打多年的运维工程师,我见过太多因为查询导致的线上故障。今天分享一套经过实战检验的MySQL查询分析与索引优化方法论,帮你彻底解决数据库性能瓶颈。
    的头像 发表于 08-13 15:55 1048次阅读

    NVMe高速传输之摆脱XDMA设计13:PCIe请求模块设计(

    在接收到请求总线接口的请求事务后,当请求类型的值为0时,表示通过PCIE硬核的配置管理接口发送请求,由于请求接口的接口和时序与配置管理接口基
    的头像 发表于 08-04 16:35 705次阅读
    NVMe高速传输之摆脱XDMA设计13:PCIe<b class='flag-5'>请求</b>模块设计(<b class='flag-5'>下</b>)

    MySQL配置调优技巧

    上个月,我们公司的核心业务系统突然出现大面积超时,用户投诉电话不断。经过紧急排查,发现是MySQL服务器CPU飙升到99%,大量查询堆积。通过一系列配置调优和SQL优化,最终在30分钟内恢复了服务。
    的头像 发表于 07-31 10:27 908次阅读

    云网络访问卡怎么办?

    一次完整的 HTTP 请求包括:域名解析、建立 TCP 连接、发起请求、服务器接收请求并返回处理结果、浏览器对 HTML 代码进行解析并请求其他资源,以及对页面进行渲染呈现。其中,HT
    的头像 发表于 06-28 14:51 935次阅读