Mysql 分页语句 Limit原理
在我们使用查询语句的时候，经常要返回前几条或者中间某几行数据，这个时候怎么办呢？不用担心，mysql已经为我们提供了这样一个功能。MySql分页sql语句，如果和MSSQL的TOP语法相比，那么MySQL的LIMIT语法要显得优雅了许多。使用它来分页是再自然不过的事情了。Mysql的分页查询语句的性能优化
·
(1)、Mysql的limit用法
- 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。
(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分页方式
经过我的测试，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
为什么会这样呢？因为子查询是在索引上完成的，而普通的查询时在数据文件上完成的，通常来说，索引文件要比数据文件小得多，所以操作起来也会更有效率。
实际可以利用类似策略模式的方式去处理分页，比如判断如果是一百页以内，就使用最基本的分页方式，大于一百页，则使用子查询的分页方式。
(3)、Mysql的分页查询语句的性能优化
mysql limit原理优化
1、offset比较小的时候。
select * from yanxue8_visit limit 10,10
多次运行，时间保持在0.0004-0.0005之间
s
elect * From yanxue8_visit where vid >=(s
elect 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左右
s
elect * From yanxue8_visit where vid >=(s
elect vid From yanxue8_visit Order By vid limit 10000,1
) limit 10
多次运行，时间保持在0.0061左右，只有前者的1/3。可以预计offset越大，后者越优。
3、性能优化：
基于MySQL5.0中limit的高性能,我对数据分页也重新有了新的认识.
方案一1)、
s
elect * from cyclopedia where ID >= (s
elect max(ID) from ( s
elect ID from cyclopedia order by ID limit 90001
) as tmp
) limit 100;
方案二2)、
s
elect * from cyclopedia where ID>=(s
elect 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句完全可以简化成
s
elect * from cyclopedia where ID>=(s
elect 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>=(s
elect top 90001 max(ID) from (s
elect ID from cyclopedia order by ID
) as tmp
)
但不管是实现方式是存贮过程还是直接代码中,瓶颈始终在于MS-SQL的TOP总是要返回前N个记录,这种情况在数据量不大时感受不深,但如果成百上千万,效率肯定会低下的. 相比之下MySQL的limit就有优势的多,执行:
s
elect ID From cyclopedia limit 90000
s
elect 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数据总量的表中测试，效果非常明显。
其他数据库的分页优化，请参考：
2） https://www.2cto.com/database/201109/106128.html
无需安装部署，在线快速体验 Byzer
更多推荐
12
0- 0
已为社区贡献17条内容
所有评论(0)