Android MySql数据分页查询 mysql分页查询原理

转载

mob64ca1408d5ff 2024-08-20 10:11:06

文章标签 Android MySql数据分页查询分页 SQL mysql 文章分类 Android 移动开发

(1)、Mysql的limit用法

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

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

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

SELECT * FROM table
//为了检索从某一个偏移量到记录集的结束所有的记录行，可以指定第二个参数为 -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

为什么会这样呢？因为子查询是在索引上完成的，而普通的查询时在数据文件上完成的，通常来说，索引文件要比数据文件小得多，所以操作起来也会更有效率。

实际可以利用类似策略模式的方式去处理分页，比如判断如果是一百页以内，就使用最基本的分页方式，大于一百页，则使用子查询的分页方式。

(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数据总量的表中测试，效果非常明显。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。