• GreatSQL社区原创内容未经授权不得随意使用,转载请联系小编并注明来源。
  • GreatSQL是MySQL的国产分支版本,使用上与MySQL一致。

前言

之前的大多数人分页采用的都是这样:

SELECT * FROM table LIMIT 20 OFFSET 50

可能有的小伙伴还是不太清楚LIMIT和OFFSET的具体含义和用法,我介绍一下:

  • LIMIT X 表示: 读取 X 条数据
  • LIMIT X, Y 表示: 跳过 X 条数据,读取 Y 条数据
  • LIMIT Y OFFSET X 表示: 跳过 X 条数据,读取 Y 条数据

对于简单的小型应用程序数据量不是很大的场景,这种方式还是没问题的。

但是你想构建一个可靠且高效的系统,一定要一开始就要把它做好。

今天我们将探讨已经被广泛使用的分页方式存在的问题,以及如何实现高性能分页

LIMIT和OFFSET有什么问题

OFFSET 和 LIMIT 对于数据量少的项目来说是没有问题的,但是,当数据库里的数据量超过服务器内存能够存储的能力,并且需要对所有数据进行分页,问题就会出现,为了实现分页,每次收到分页请求时,数据库都需要进行低效的全表遍历

全表遍历就是一个全表扫描的过程,就是根据双向链表把磁盘上的数据页加载到磁盘的缓存页里去,然后在缓存页内部查找那条数据。这个过程是非常慢的,所以说当数据量大的时候,全表遍历性能非常低,时间特别长,应该尽量避免全表遍历。

这意味着,如果你有 1 亿个用户,OFFSET 是 5 千万,那么它需要获取所有这些记录 (包括那么多根本不需要的数据),将它们放入内存,然后获取 LIMIT 指定的 20 条结果。

为了获取一页的数据:10万行中的第5万行到第5万零20行需要先获取 5 万行,这么做非常低效!

初探LIMIT查询效率

数据准备

  • 本文测试使用的环境:
[root@zhyno1 ~]# cat /etc/system-release
CentOS Linux release 7.9.2009 (Core) [root@zhyno1 ~]# uname -a
Linux zhyno1 3.10.0-1160.62.1.el7.x86_64 #1 SMP Tue Apr 5 16:57:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
  • 测试数据库采用的是(存储引擎采用InnoDB,其它参数默认):
mysql> select version();
+-----------+
| version() |
+-----------+
| 8.0.25-16 |
+-----------+
1 row in set (0.00 sec)

表结构如下:

CREATE TABLE `limit_test` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`column1` decimal(11,2) NOT NULL DEFAULT '0.00',
`column2` decimal(11,2) NOT NULL DEFAULT '0.00',
`column3` decimal(11,2) NOT NULL DEFAULT '0.00',
PRIMARY KEY (`id`)
)ENGINE=InnoDB mysql> DESC limit_test;
+---------+---------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------+---------------+------+-----+---------+----------------+
| id | int | NO | PRI | NULL | auto_increment |
| column1 | decimal(11,2) | NO | | 0.00 | |
| column2 | decimal(11,2) | NO | | 0.00 | |
| column3 | decimal(11,2) | NO | | 0.00 | |
+---------+---------------+------+-----+---------+----------------+
4 rows in set (0.00 sec)

插入350万条数据作为测试:

mysql> SELECT COUNT(*) FROM limit_test;
+----------+
| COUNT(*) |
+----------+
| 3500000 |
+----------+
1 row in set (0.47 sec)

开始测试

首先偏移量设置为0,取20条数据(中间输出省略):

mysql> SELECT * FROM limit_test LIMIT 0,20;
+----+----------+----------+----------+
| id | column1 | column2 | column3 |
+----+----------+----------+----------+
| 1 | 50766.34 | 43459.36 | 56186.44 |
#...中间输出省略
| 20 | 66969.53 | 8144.93 | 77600.55 |
+----+----------+----------+----------+
20 rows in set (0.00 sec)

可以看到查询时间基本忽略不计,于是我们要一步一步的加大这个偏移量然后进行测试,先将偏移量改为10000(中间输出省略):

mysql> SELECT * FROM limit_test LIMIT 10000,20;
+-------+----------+----------+----------+
| id | column1 | column2 | column3 |
+-------+----------+----------+----------+
| 10001 | 96945.17 | 33579.72 | 58460.97 |
#...中间输出省略
| 10020 | 1129.85 | 27087.06 | 97340.04 |
+-------+----------+----------+----------+
20 rows in set (0.00 sec)

可以看到查询时间还是非常短的,几乎可以忽略不计,于是我们将偏移量直接上到340W(中间输出省略):

mysql> SELECT * FROM limit_test LIMIT 3400000,20;
+---------+----------+----------+----------+
| id | column1 | column2 | column3 |
+---------+----------+----------+----------+
| 3400001 | 5184.99 | 67179.02 | 56424.95 |
#...中间输出省略
| 3400020 | 8732.38 | 71035.71 | 52750.14 |
+---------+----------+----------+----------+
20 rows in set (0.73 sec)

这个时候就可以看到非常明显的变化了,查询时间猛增到了0.73s。

分析耗时的原因

根据下面的结果可以看到三条查询语句都进行了全表扫描:

mysql> EXPLAIN SELECT * FROM limit_test LIMIT 0,20;
+----+-------------+------------+------------+------+---------------+------+---------+------+---------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+------------+------+---------------+------+---------+------+---------+----------+-------+
| 1 | SIMPLE | limit_test | NULL | ALL | NULL | NULL | NULL | NULL | 3491695 | 100.00 | NULL |
+----+-------------+------------+------------+------+---------------+------+---------+------+---------+----------+-------+
1 row in set, 1 warning (0.00 sec) mysql> EXPLAIN SELECT * FROM limit_test LIMIT 10000,20;
+----+-------------+------------+------------+------+---------------+------+---------+------+---------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+------------+------+---------------+------+---------+------+---------+----------+-------+
| 1 | SIMPLE | limit_test | NULL | ALL | NULL | NULL | NULL | NULL | 3491695 | 100.00 | NULL |
+----+-------------+------------+------------+------+---------------+------+---------+------+---------+----------+-------+
1 row in set, 1 warning (0.00 sec) mysql> EXPLAIN SELECT * FROM limit_test LIMIT 3400000,20;
+----+-------------+------------+------------+------+---------------+------+---------+------+---------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+------------+------+---------------+------+---------+------+---------+----------+-------+
| 1 | SIMPLE | limit_test | NULL | ALL | NULL | NULL | NULL | NULL | 3491695 | 100.00 | NULL |
+----+-------------+------------+------------+------+---------------+------+---------+------+---------+----------+-------+
1 row in set, 1 warning (0.00 sec)

此时就可以知道的是,在偏移量非常大的时候,就像案例中的LIMIT 3400000,20这样的查询。

此时MySQL就需要查询3400020行数据,然后在返回最后20条数据。

前边查询的340W数据都将被抛弃,这样的执行结果可不是我们想要的。

接下来就是优化大偏移量的性能问题

优化

你可以这样做:

SELECT * FROM limit_test WHERE id>10 limit 20

这是一种基于指针的分页。

你要在本地保存上一次接收到的主键 (通常是一个 ID) 和 LIMIT,而不是 OFFSET 和 LIMIT,那么每一次的查询可能都与此类似。

为什么?因为通过显式告知数据库最新行,数据库就确切地知道从哪里开始搜索(基于有效的索引),而不需要考虑目标范围之外的记录。

我们再来一次测试(中间输出省略):

mysql> SELECT * FROM limit_test WHERE id>3400000 LIMIT 20;
+---------+----------+----------+----------+
| id | column1 | column2 | column3 |
+---------+----------+----------+----------+
| 3400001 | 5184.99 | 67179.02 | 56424.95 |
#...中间输出省略
| 3400020 | 8732.38 | 71035.71 | 52750.14 |
+---------+----------+----------+----------+
20 rows in set (0.00 sec) mysql> EXPLAIN SELECT * FROM limit_test WHERE id>3400000 LIMIT 20;
+----+-------------+------------+------------+-------+---------------+---------+---------+------+--------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+------------+------------+-------+---------------+---------+---------+------+--------+----------+-------------+
| 1 | SIMPLE | limit_test | NULL | range | PRIMARY | PRIMARY | 4 | NULL | 185828 | 100.00 | Using where |
+----+-------------+------------+------------+-------+---------------+---------+---------+------+--------+----------+-------------+
1 row in set, 1 warning (0.00 sec)

返回同样的结果,第一个查询使用了0.73 sec,而第二个仅用了0.00 sec

注意:

如果我们的表没有主键,比如是具有多对多关系的表,那么就使用传统的 OFFSET/LIMIT 方式,只是这样做存在潜在的慢查询问题。所以建议在需要分页的表中使用自动递增的主键,即使只是为了分页。

再优化

类似于查询 SELECT * FROM table_name WHERE id > 3400000 LIMIT 20; 这样的效率非常快,因为主键上是有索引的,但是这样有个缺点,就是ID必须是连续的,并且查询不能有WHERE语句,因为WHERE语句会造成过滤数据。那使用场景就非常的局限了,于是我们可以这样:

使用覆盖索引优化

MySQL的查询完全命中索引的时候,称为覆盖索引,是非常快的,因为查询只需要在索引上进行查找,之后可以直接返回,而不用再回数据表拿数据。因此我们可以先查出索引的 ID,然后根据 Id 拿数据。

SELECT * FROM (SELECT id FROM table_name LIMIT 3400000,20) a LEFT JOIN table_name b ON a.id = b.id;

#或者是

SELECT * FROM table_name a INNER JOIN (SELECT id FROM table_name LIMIT 3400000,20) b USING (id);

总结

  • 数据量大的时候不能使用OFFSET/LIMIT来进行分页,因为OFFSET越大,查询时间越久。
  • 当然不能说所有的分页都不可以,如果你的数据就那么几千、几万条,那就很无所谓,随便使用。
  • 如果我们的表没有主键,比如是具有多对多关系的表,那么就使用传统的 OFFSET/LIMIT 方式。
  • 这种方法适用于要求ID为数值类型,并且查出的数据ID连续的场景且不能有其他字段的排序。

Enjoy GreatSQL

关于 GreatSQL

GreatSQL是由万里数据库维护的MySQL分支,专注于提升MGR可靠性及性能,支持InnoDB并行查询特性,是适用于金融级应用的MySQL分支版本。

相关链接: GreatSQL社区 Gitee GitHub Bilibili

GreatSQL社区:

欢迎来GreatSQL社区发帖提问

https://greatsql.cn/

技术交流群:

微信:扫码添加GreatSQL社区助手微信好友,发送验证信息加群

LIMIT和OFFSET分页性能差!今天来介绍如何高性能分页的更多相关文章

  1. 优化Laravel的分页LIMIT和OFFSET调用

    在分页系统中使用limit和offset是很常见的,它们通常也会和ORDER BY一起使用.索引对排序较有帮助,如果没有索引就需要大量的文件排序. 一个常见的问题是偏移量很大,比如查询使用了LIMIT ...

  2. jdk8 stream实现sql单表select a,b,sum(),avg(),max() from group by a,b order by a,b limit M offset N及其性能

    之所以要测该场景,是因为merge多数据源结果的时候,有时候只是单个子查询结果了,而此时采用sql数据库处理并不一定能够合理(网络延迟太大). 测试数据10万行,结果1000行 limit 20 of ...

  3. 【MYSQL】mysql大数据量分页性能优化

    转载地址: http://www.cnblogs.com/lpfuture/p/5772055.html https://www.cnblogs.com/shiwenhu/p/5757250.html ...

  4. MySQL— 索引,视图,触发器,函数,存储过程,执行计划,慢日志,分页性能

    一.索引,分页性能,执行计划,慢日志 (1)索引的种类,创建语句,名词补充(最左前缀匹配,覆盖索引,索引合并,局部索引等): import sys # http://www.cnblogs.com/w ...

  5. Sql Server多种分页性能的比较

    一.前言 因为工作关系,遇到了非常大的数据量的分页问题,数据总共有8000万吧,这个显然不是简单的分页能够解决的,需要从多多方面考虑,从分表.分库等等.但是这个也让我考虑到了分页性能的问题,在不同数据 ...

  6. mysql limit和offset用法

    limit和offset用法 mysql里分页一般用limit来实现 1. select* from article LIMIT 1,3 2.select * from article LIMIT 3 ...

  7. mysql中limit 和 limit 与 offset 的用法(效果相同,用法不通过)

    例1,假设数据库表student存在13条数据. 代码示例: 语句1:select * from student limit 9,4 语句2:slect * from student limit 4 ...

  8. day05 mysql pymysql的使用 (前端+flask+pymysql的使用) 索引 解释执行 慢日志 分页性能方案

    day05 mysql pymysql   一.pymysql的操作     commit(): 在数据库里增删改的时候,必须要进行提交,否则插入的数据不生效       1.增, 删, 改  #co ...

  9. LIMIT与OFFSET的使用

    limit 与 offset:从下标0开始 offset X   是跳过X个数据 limit Y      是选取Y个数据 limit  X,Y  中X表示跳过X个数据,读取Y个数据 例如: sele ...

随机推荐

  1. jdbc连接数据库问题

    ### Error querying database.  Cause: org.springframework.jdbc.CannotGetJdbcConnectionException: Fail ...

  2. js 表面学习 - 认识函数

    JavaScript 函数语法 JavaScript 函数通过 function 关键词进行定义,其后是函数名和括号 (). 函数名可包含字母.数字.下划线和美元符号(规则与变量名相同). 圆括号可包 ...

  3. Sentinel-流量防卫兵

    1.背景 1.1 简介 Sentinel 以流量为切入点,从流量控制.熔断降级.系统负载保护等多个维度保护服务的稳定性. Sentinel 具有以下特征 丰富的应用场景:Sentinel 承接了阿里巴 ...

  4. java--运算符和表达式

    运算符:就是对常量或者遍历进行操作的符号: 表达式:用运算符把常量或者变量连接起来符合java语法的式子称为表达式,不同运算符连接的表达式体现的是不同类型的表达式. 一.算术运算符 1.使用%运算符: ...

  5. 5-18 Nacos配置中心 | RestTemplate

    配置中心 什么是配置中心 所谓配置中心:将项目需要的配置信息保存在配置中心,需要读取时直接从配置中心读取,方便配置管理的微服务工具 我们可以将部分yml文件的内容保存在配置中心 一个微服务项目有很多子 ...

  6. JavaScript进阶内容——DOM详解

    JavaScript进阶内容--DOM详解 当我们已经熟练掌握JavaScript的语法之后,我们就该进入更深层次的学习了 首先我们思考一下:JavaScript是用来做什么的? JavaScript ...

  7. Linux(Centos7) 实例搭建 FTP 服务

    本文以 CentOS 7.2 64位系统为例,使用 vsftpd 作为 FTP 服务端,FileZilla 作为客户端.指导您如何在 Linux 云服务器上搭建 FTP 服务. 操作步骤 安装 vsf ...

  8. 【Java线程池】 java.util.concurrent.ThreadPoolExecutor 分析

    线程池概述 线程池,是指管理一组同构工作线程的资源池. 线程池在工作队列(Work Queue)中保存了所有等待执行的任务.工作者线程(Work Thread)会从工作队列中获取一个任务并执行,然后返 ...

  9. linux学习随笔

    date +%Y-%m-%d\ %H:%M:%S cal 10 2009 yum install bc //计算器 bc 安装thefuck yum install gcc gcc++ python ...

  10. Mybatis 缓存原理

    Mybatis 缓存原理 本文来自拉钩 java 高薪训练营,如果文章写的不好,看不懂可以找我要课程视频,不收费. 只愿在编程道路上,寻求志同道合的码友.v:15774135883 1 Mybatis ...