实战!聊聊如何解决MySQL深分页问题

我们日常做分页需求时,一般会用 limit 实现,但是当偏移量特别大的时候,查询效率就变得低下。本文将分四个方案,讨论如何优化 MySQL 百万数据的深分页问题,并附上最近优化生产慢 SQL 的实战案例。

limit 深分页为什么会变慢?
CREATE TABLE account (
id int(11) NOT NULL AUTO_INCREMENT COMMENT ‘主键Id’,
name varchar(255) DEFAULT NULL COMMENT ‘账户名’,
balance int(11) DEFAULT NULL COMMENT ‘余额’,
create_time datetime NOT NULL COMMENT ‘创建时间’,
update_time datetime NOT NULL ON UPDATE CURRENT_TIMESTAMP COMMENT ‘更新时间’,
PRIMARY KEY (id),
KEY idx_name (name),
KEY idx_update_time (update_time) //索引
) ENGINE=InnoDB AUTO_INCREMENT=1570068 DEFAULT CHARSET=utf8 ROW_FORMAT=REDUNDANT COMMENT=‘账户表’;
假设深分页的执行 SQL 如下:

select id,name,balance from account where update_time> ‘2020-09-19’ limit 100000,10;
这个 SQL 的执行时间如下:

执行完需要 0.742 秒,深分页为什么会变慢呢?如果换成 limit 0,10,只需要 0.006 秒哦

我们先来看下这个 SQL 的执行流程:

通过普通二级索引树 idx_update_time,过滤 update_time 条件,找到满足条件的记录 ID。

通过 ID,回到主键索引树,找到满足记录的行,然后取出展示的列(回表)

扫描满足条件的 100010 行,然后扔掉前 100000 行,返回。

上图为 SQL 的执行流程
执行计划如下:

SQL 变慢原因有两个:

limit 语句会先扫描 offset+n 行,然后再丢弃掉前 offset 行,返回后 n 行数据。也就是说 limit 100000,10,就会扫描 100010 行,而 limit 0,10,只扫描 10 行。

limit 100000,10 扫描更多的行数,也意味着回表更多的次数。

通过子查询优化
因为以上的 SQL,回表了 100010 次,实际上,我们只需要 10 条数据,也就是我们只需要 10 次回表其实就够了。因此,我们可以通过减少回表次数来优化。

回顾 B+ 树结构
那么,如何减少回表次数呢?我们先来复习下 B + 树索引结构哈~

InnoDB 中,索引分主键索引(聚簇索引)和二级索引

主键索引,叶子节点存放的是整行数据

二级索引,叶子节点存放的是主键的值。

把条件转移到主键索引树
如果我们把查询条件,转移回到主键索引树,那就可以减少回表次数啦。转移到主键索引树查询的话,查询条件得改为主键id 了,之前 SQL 的 update_time 这些条件咋办呢?抽到子查询那里嘛~

子查询那里怎么抽的呢?因为二级索引叶子节点是有主键 ID 的,所以我们直接根据 update_time 来查主键 ID 即可,同时我们把 limit 100000 的条件,也转移到子查询,完整 SQL 如下:

select id,name,balance FROM account where id >= (select a.id from account a where a.update_time >= ‘2020-09-19’ limit 100000, 1) LIMIT 10;写漏了,可以补下时间条件在外面
查询效果一样的,执行时间只需要 0.038 秒!

我们来看下执行计划

由执行计划得知,子查询 table a 查询是用到了 idx_update_time 索引。首先在索引上拿到了聚集索引的主键 ID, 省去了回表操作,然后第二查询直接根据第一个查询的 ID 往后再去查 10 个就可以了!

因此,这个方案是可以的~

INNER JOIN 延迟关联
延迟关联的优化思路,跟子查询的优化思路其实是一样的:都是把条件转移到主键索引树,然后减少回表。不同点是,延迟关联使用了 inner join 代替子查询。
优化后的 SQL 如下:

SELECT acct1.id,acct1.name,acct1.balance FROM account acct1 INNER JOIN (SELECT a.id FROM account a WHERE a.update_time >= ‘2020-09-19’ ORDER BY a.update_time LIMIT 100000, 10) AS acct2 on acct1.id= acct2.id;
查询效果也是杠杆的,只需要 0.034 秒

执行计划如下:

查询思路就是,先通过 idx_update_time 二级索引树查询到满足条件的主键 ID,再与原表通过主键 ID 内连接,这样后面直接走了主键索引了,同时也减少了回表。

标签记录法
limit 深分页问题的本质原因就是:偏移量(offset)越大,mysql 就会扫描越多的行,然后再抛弃掉。这样就导致查询性能的下降。

其实我们可以采用标签记录法,就是标记一下上次查询到哪一条了,下次再来查的时候,从该条开始往下扫描。就好像看书一样,上次看到哪里了,你就折叠一下或者夹个书签,下次来看的时候,直接就翻到啦。

假设上一次记录到 100000,则 SQL 可以修改为:

select id,name,balance FROM account where id > 100000 order by id limit 10;
这样的话,后面无论翻多少页,性能都会不错的,因为命中了 id 索引。但是这种方式有局限性:需要一种类似连续自增的字段。

使用 between…and…
很多时候,可以将 limit 查询转换为已知位置的查询,这样 MySQL 通过范围扫描 between…and,就能获得到对应的结果。

如果知道边界值为 100000,100010 后,就可以这样优化:

select id,name,balance FROM account where id between 100000 and 100010 order by id;

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
MySQL分页问题指的是在查询大量数据时,需要获取结果集中某一页的数据,而这个页数非常靠后,会导致查询性能下降和资源消耗过大的情况。 解决MySQL分页问题可以尝试以下几种方法: 1. 使用索引:确保查询涉及到的列有合适的索引。使用合适的索引可以提高查询的效率,减少扫描的数据量。根据查询条件和排序需求,创建适当的索引,以加速分页查询。 2. 使用游标分页:通过使用游标(Cursor)来获取分页数据,而不是传统的LIMIT和OFFSET语句。游标分页可以避免MySQL在每次查询时都重新扫描和跳过前面的记录,提高查询性能。 3. 使用分页缓存:将查询结果缓存在应用程序的内存中,避免每次都向数据库发送分页查询请求。可以使用缓存技术如Redis、Memcached等,将结果集按页缓存,并根据需要从缓存中获取数据。 4. 使用预取技术:通过一次性获取多页数据,而不仅仅是当前需要的一页。可以通过增加查询范围,一次性获取多个页面的数据,并在应用程序中进行缓存和管理,以提高后续分页查询的效率。 5. 数据分片:如果可能,将数据进行分片(Sharding),将数据分散存储在多个数据库中。这样可以将大量数据分散到不同的数据库中,从而减轻单个数据库的负载,提高查询性能。 需要根据具体的应用场景和需求选择合适的解决方案。同时,注意评估和测试每种解决方案的效果,以确保其适用性和性能提升。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值