Mysql 分页语句 Limit原理

Mysql 分页语句 Limit原理
 

(1)、Mysql的limit用法
在我们使用查询语句的时候,经常要返回前几条或者中间某几行数据,这个时候怎么办呢?不用担心,mysql已经为我们提供了这样一个功能。

    SELECT * FROM table LIMIT [offset,] rows | rows OFFSET offset  

LIMIT 子句可以被用于强制 SELECT 语句返回指定的记录数。LIMIT 接受一个或两个数字参数。参数必须是一个整数常量。如果给定两个参数,第一个参数指定第一个返回记录行的偏移量,第二个参数指定返回记录行的最大数目。初始记录行的偏移量是 0(而不是 1): 为了与 PostgreSQL 兼容,MySQL 也支持句法: LIMIT # OFFSET #。

    mysql> SELECT * FROM table LIMIT 5,10; // 检索记录行 6-15  
      
    //为了检索从某一个偏移量到记录集的结束所有的记录行,可以指定第二个参数为 -1:   
    mysql> SELECT * FROM table LIMIT 95,-1; // 检索记录行 96-last.    这个只适用于特定的mysql数据库版本
      
    //如果只给定一个参数,它表示返回最大的记录行数目:   
    mysql> SELECT * FROM table LIMIT 5; //检索前 5 个记录行  
      
    //换句话说,LIMIT n 等价于 LIMIT 0,n。  

    【引用,路人乙:Mysql中limit的用法详解】

(2)、Mysql的分页查询语句的性能分析
     MySql分页sql语句,如果和MSSQL的TOP语法相比,那么MySQL的LIMIT语法要显得优雅了许多。使用它来分页是再自然不过的事情了。
 2.1最基本的分页方式:   

    SELECT ... FROM ... WHERE ... ORDER BY ... LIMIT ...  

 
在中小数据量的情况下,这样的SQL足够用了,唯一需要注意的问题就是确保使用了索引:
举例来说,如果实际SQL类似下面语句,那么在category_id, id两列上建立复合索引比较好:

    SELECT * FROM articles WHERE category_id = 123 ORDER BY id LIMIT 50, 10  

 
2.2子查询的分页方式:
 随着数据量的增加,页数会越来越多,查看后几页的SQL就可能类似:

    SELECT * FROM articles WHERE category_id = 123 ORDER BY id LIMIT 10000, 10  

 
一言以蔽之,就是越往后分页,LIMIT语句的偏移量就会越大,速度也会明显变慢。
此时,我们可以通过子查询的方式来提高分页效率,大致如下:

    SELECT * FROM articles WHERE  id >=  
     (SELECT id FROM articles  WHERE category_id = 123 ORDER BY id LIMIT 10000, 1) LIMIT 10  

2.3JOIN分页方式

    SELECT * FROM `content` AS t1   
    JOIN (SELECT id FROM `content` ORDER BY id desc LIMIT ".($page-1)*$pagesize.", 1) AS t2   
    WHERE t1.id <= t2.id ORDER BY t1.id desc LIMIT $pagesize;   

 
     经过我的测试,join分页和子查询分页的效率基本在一个等级上,消耗的时间也基本一致。
explain SQL语句:
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY <derived2> system NULL NULL NULL NULL 1  
1 PRIMARY t1 range PRIMARY PRIMARY 4 NULL 6264 Using where
2 DERIVED content index NULL PRIMARY 4 NULL 27085 Using index
 
为什么会这样呢?因为子查询是在索引上完成的,而普通的查询时在数据文件上完成的,通常来说,索引文件要比数据文件小得多,所以操作起来也会更有效率。
实际可以利用类似策略模式的方式去处理分页,比如判断如果是一百页以内,就使用最基本的分页方式,大于一百页,则使用子查询的分页方式。
【引用原文,energy1010的空间:MySql分页sql语句】

(3)、Mysql的分页查询语句的性能优化
 mysql limit原理优化
     1、offset比较小的时候。
                select * from yanxue8_visit limit 10,10
                多次运行,时间保持在0.0004-0.0005之间

                select * From yanxue8_visit where vid >=(select vid from yanxue8_visit Order By vid limit 10,1) limit 10
                多次运行,时间保持在0.0005-0.0006之间,主要是0.0006
                结论:偏移offset较小的时候,直接使用limit较优。这个显然是子查询的原因。

    2、offset大的时候。
                select * from yanxue8_visit limit 10000,10
                多次运行,时间保持在0.0187左右

                select * From yanxue8_visit where vid >=(select vid From yanxue8_visit Order By vid limit 10000,1) limit 10
               多次运行,时间保持在0.0061左右,只有前者的1/3。可以预计offset越大,后者越优。
    3、性能优化:
            基于MySQL5.0中limit的高性能,我对数据分页也重新有了新的认识.

        方案一1)、
        select * from cyclopedia where ID >= (select max(ID) from ( select ID from cyclopedia order by ID limit 90001 ) as tmp) limit 100;
        方案二2)、
       select * from cyclopedia where ID>=(select max(ID) from (select ID from cyclopedia order by ID limit 90000,1) as tmp) limit 100;
       结论一:
        同样是取90000条后100条记录,第1句快还是第2句快?
        第1句是先取了前90001条记录,取其中最大一个ID值作为起始标识,然后利用它可以快速定位下100条记录
        第2句择是仅仅取90000条记录后1条,然后取ID值作起始标识定位下100条记录
        第1句执行结果.100 rows in set (0.23) sec
        第2句执行结果.100 rows in set (0.19) sec
        很明显第2句胜出.看来limit好像并不完全像我之前想象的那样做全表扫描返回limit offset+length条记录,这样看来limit比起MS-SQL的Top性能还是要提高不少的.
        结论二:
        其实第2句完全可以简化成select * from cyclopedia where ID>=(select ID from cyclopedia limit 90000,1)limit 100;
        直接利用第90000条记录的ID,不用经过Max运算,这样做理论上效率因该高一些,但在实际使用中几乎看不到效果,因为本身定位ID返回的就是1条记录,Max几乎不用运作就能得到结果,但这样写更清淅明朗,省去了画蛇那一足.
        结论三:
       可是,既然MySQL有limit可以直接控制取出记录的位置,为什么不干脆用select * from cyclopedia limit 90000,1呢?岂不更简洁?
这样想就错了,试了就知道,结果是:1 row in set (8.88) sec,怎么样,够吓人的吧。select * 最好不要随便用,要本着用什么,选什么的原则, select的字段越多,字段数据量越大,速度就越慢. 上面2种分页方式哪种都比单写这一句强多了,虽然看起来好像查询的次数更多一些,但实际上是以较小的代价换取了高效的性能,是非常值得的.
      推而广之:
      第1种方案同样可用于MS-SQL,而且可能是最好的.因为靠主键ID来定位起始段总是最快的.

      select top 100 * from cyclopedia where ID>=(select top 90001 max(ID) from (select ID from cyclopedia order by ID) as tmp)
    
        但不管是实现方式是存贮过程还是直接代码中,瓶颈始终在于MS-SQL的TOP总是要返回前N个记录,这种情况在数据量不大时感受不深,但如果成百上千万,效率肯定会低下的.    相比之下MySQL的limit就有优势的多,执行:
        select ID From cyclopedia limit 90000
        select ID From cyclopedia limit 90000,1
        的结果分别是:
            90000 rows in set (0.36) sec
            1 row in set (0.06) sec
        而MS-SQL只能用select top 90000 ID from cyclopedia 执行时间是390ms,执行同样的操作时间也不及MySQL的360ms.
        结论:MySql 的limit 比 MS SQL的top执行效率要高效
----------------------------------------------------------
    4、LIMIT 思考

    PERCONA PERFORMANCE CONFERENCE 2009上,来自雅虎的几位工程师带来了一篇”Efficient Pagination Using MySQL“的报告,有很多亮点,本文是在原文基础上的进一步延伸。
    1)首先看一下分页的基本原理:
        mysql> explain SELECT * FROM message ORDER BY id DESC LIMIT 10000, 20 \G;
***************** 1. row **************
id: 1
select_type: SIMPLE
table: message
type: index
possible_keys: NULL
key: PRIMARY
key_len: 4
ref: NULL
rows: 10020
Extra:
1 row in set (0.00 sec)
         limit 10000,20的意思扫描满足条件的10020行,扔掉前面的10000行,返回最后的20行,问题就在这里,如果是limit 100000,100,需要扫描100100行,在一个高并发的应用里,每次查询需要扫描超过10W行,性能肯定大打折扣。文中还提到limit n性能是没问题的,因为只扫描n行。

    结论:

        文中提到一种”clue”的做法,给翻页提供一些”线索”,比如还是SELECT * FROM message ORDER BY id DESC,按id降序分页,每页20条,当前是第10页,当前页条目id最大的是9527,最小的是9500,如果我们只提供”上一页”、”下一页”这样 的跳转(不提供到第N页的跳转),那么在处理”上一页”的时候SQL语句可以是:
        SELECT * FROM message WHERE id > 9527 ORDER BY id ASC LIMIT 20;
        处理”下一页”的时候SQL语句可以是:
        SELECT * FROM message WHERE id < 9500 ORDER BY id DESC LIMIT 20;
    不管翻多少页,每次查询只扫描20行。

缺点和mysql limit优化:

    缺点是只能提供”上一页”、”下一页”的链接形式,但是我们的产品经理非常喜欢”<上一页 1 2 3 4 5 6 7 8 9 下一页>”这样的链接方式,怎么办呢?
        如果  LIMIT m,n  不可避免的话,要优化效率,只有尽可能的让m小一下,我们扩展前面的”clue”做法,还是SELECT * FROM message ORDER BY id DESC,按id降序分页,每页20条,当前是第10页,当前页条目id最大的是9527,最小的是9500,比如要跳到第8页,我看的      
        SQL语句可以这 样写:
                    SELECT * FROM message WHERE id > 9527 ORDER BY id ASC LIMIT 20,20;
                    跳转到第13页:
                    SELECT * FROM message WHERE id < 9500 ORDER BY id DESC LIMIT 40,20;
        原理还是一样,记录住当前页id的最大值和最小值,计算跳转页面和当前页相对偏移,由于页面相近,这个偏移量不会很大,这样的话m值相对较小,大大 减少扫描的行数。其实传统的limit m,n,相对的偏移一直是第一页,这样的话越翻到后面,效率越差,而上面给出的方法就没有这样的问题。
        注意SQL语句里面的ASC和DESC,如果是ASC取出来的结果,显示的时候记得倒置一下。已在60W数据总量的表中测试,效果非常明显。

其他数据库的分页优化,请参考:
   1     http://qimo601.iteye.com/blog/1634748
   2) https://www.2cto.com/database/201109/106128.html
————————————————
版权声明:本文为CSDN博主「Data_IT_Farmer」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/helloxiaozhe/article/details/78106709

©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页