本文由 发布，转载请注明出处，如有问题请联系我们！ 发布时间: 2021-08-01mysql分页查询语句-mysql的三种分页方法

方式1:立即应用数据库查询给予的SQL句子。

句子款式: MySQL中,可以用如下所示方式: SELECT * FROM 表名字 LIMIT M,N融入情景: 适用信息量较少的状况(元组百/百级)缘故/缺陷: 全表扫描仪,速率会比较慢 且 有的数据库查询結果集回到不稳定(如一次回到1,2,3,此外的一次回到2,1,3). Limit限定的是以結果集的M部位处取下N条輸出,其他抛下.

方式2:创建外键约束或唯一索引，并应用该数据库索引(假定每张10项)。

句子款式: MySQL中,可以用如下所示方式: SELECT * FROM 表名字 WHERE id_pk > (pageNum*10) LIMIT M融入情景: 适用信息量多的状况(元组数过万)缘故: 数据库索引扫描仪,速率会迅速. 有好朋友明确提出: 由于数据统计出去并并不是依照pk_id排列的，因此会出现跳开数据信息的状况，只有方式3

方式3:根据数据库索引再次排列。

句子款式: MySQL中,可以用如下所示方式: SELECT * FROM 表名字 WHERE id_pk > (pageNum*10) ORDER BY id_pk ASC LIMIT M融入情景: 适用信息量多的状况(元组数过万). 最好是ORDER BY后的列目标是外键约束或唯一因此,促使ORDERBY实际操作能运用数据库索引被清除但結果集是平稳的(平稳的含意,参照方式1)缘故: 数据库索引扫描仪,速率会迅速. 但MySQL的排列实际操作,仅有ASC沒有DESC(DESC是假的,将来会做真真正正的DESC,希望…).

方式4:应用根据数据库索引的提前准备。

第一个疑问表明pageNum，第二个？表明每张元组的总数。

句子款式: MySQL中,可以用如下所示方式: PREPARE stmt_name FROM SELECT * FROM 表名字 WHERE id_pk > (？* ？) ORDER BY id_pk ASC LIMIT M融入情景: 大信息量缘故: 数据库索引扫描仪,速率会迅速. prepare句子又比一般的搜索句子快一点。

方式五:应用MySQL适用ORDER实际操作，能够根据数据库索引迅速精准定位一些元组，防止扫描仪全部表。

比如，从第1000行至第1019行载入元组(pk是外键约束/唯一键)。

1SELECT * FROM your_table WHERE pk>=1000 ORDER BY pk ASC LIMIT 0,20

方式6:应用子查询/联接 数据库索引迅速精准定位元组，随后载入元组。

比如(id是外键约束/唯一键，深蓝色字体样式是自变量)。

应用子查询实例:

123SELECT * FROM your_table WHERE id =(select id from product limit 866613, 1) limit 20

查看時间为0.2秒！

另一种创作方法。

1SELECT * FROM product a JOIN (select id from product limit 866613, 20) b ON a.ID = b.id

查看時间也很短！

3.综合性指数值优化方法。

MySql能主要表现多大？这一MySql数据库查询肯定合适dba级大神玩。一般能够写一个一万篇新闻报道稿件的小系统软件，用xx架构完成快速开发。可是当数据做到10万，上百万到上百万的情况下，他的特性还能那么高吗？一个小小不正确就有可能造成整体系统软件被改变，乃至让系统软件不能正常的运作！好啦，不要说那么多屁话了。

用事实说话，看事例:

一个数据分析表结合(id，title，info，vtype)包含了这四个字段，在其中title应用固定不动长短，info应用文字，id是渐变色的，vtype是tinyint，而vtype是index。这是一个基本上新闻系统的简易实体模型。如今用数据信息和10万条新闻报道铺满它。最终，collect是10万条纪录，数据库表占有1.6G电脑硬盘。

好的，请看下面的sql语句:

1select id,title from collect limit 1000,10;

迅速；大部分0.01秒就可以了，随后看下面。

1select id,title from collect limit 90000,10;

从9万一篇文章中分页查询，结果呢？

8-9秒进行，我的天哪怎么啦？实际上提升这一数据信息，回答能够在网络上寻找。请看下面的阐述:

1select id from collect order by id limit 90000,10;

迅速，0.04秒就可以了。为什么呢？由于应用id外键约束做为数据库索引毫无疑问迅速。线上变更包含:

1select id,title from collect where id>=(select id from collect order by id limit 90000,1) limit 10;

这也是用id数据库索引的結果。但假如难题略微繁杂一点，就结束了。请看下面的阐述。

1select id from collect where vtype=1 order by id limit 90000,10;

十分慢，花了8-9秒！

到这儿，坚信很多人都是会有与我一样的奔溃感！vtype有数据库索引吗？为什么会慢？非常好，vtype早已被数据库索引了，你立即。

1select id from collect where vtype=1 limit 1000,10;

迅速，大部分是0.05秒，可是提升了90倍，从9万逐渐，也就是0.05*90=4.5秒的速率。检测結果在8-9秒内做到一个量级。

从这儿，有些人谈到了分桌的念头，和dis #cuz Forum一样。念头如下所示:

创建一个数据库索引表:t (id，title，vtype)并将其设定为固定不动长短，随后开展分页查询，将結果分页查询出去并前去collect搜索信息内容。行得通吗？试验后咱们就知道。

10万条纪录以t(id，title，vtype)纪录，数据分析表尺寸约为20M。应用

1select id from collect where vtype=1 limit 1000,10;

迅速。大部分0.1-0.2秒就能进行。怎么会那样？我想是由于搜集的数据信息过多，因此分页查询要跑较长一段路。限定彻底与数据分析表的尺寸相关。实际上或是全表扫描仪，仅仅由于信息量小，仅有10万快。好，大家来做一个瘋狂的试验，提升到100万，检测特性。提升10倍数据信息后，T米会一下子做到200 m之上，长短固定不动。是刚刚的搜索句子，时间0.1-0.2秒进行！子表主要表现还行吧？

不对！由于大家的额度或是9万，因此赶快。给个大的，从90万逐渐。

1select id from t where vtype=1 order by id limit 900000,10;

看結果，时间1-2秒！为什么呢？

或是那麼长，很压抑感！有些人说固定不动长短会提升極限的特性。一开始我还以为mysql应当能够计算90万的部位，由于一条数据的长短是确定的。殊不知，大家虚高了mysql的智能化，它并不是一个商业服务数据库查询。事实上，定长度非定长对極限危害并不大？怪不得有些人说Discuz做到100引马镇的过程中会比较慢。我坚信是确实。这和概念模型设计相关！

MySQL不可以提升100万的限定吗？？？如果你做到100万页的情况下，你确实做到極限了没有？

回答是:为何NO不可以超出100万是由于它不可以设计方案mysql。来介绍一下非子表法，再来一个瘋狂的检测！一张表能够解决100万条纪录，而10G数据库查询，怎么才能换页！

好啦，大家的检测返回搜集表，检测的结果是:

30万数据信息，应用子表法是有效的。假如超出30万，它的效率会减缓，你能承受不住的！自然，应用“子表 我”的办法是肯定极致的。可是用了我的方式后，无需数据透析表就能极致处理！

回答是:综合性指数值！有一次设计方案mysql索引的情况下，偶然发现数据库索引名能够随便取，因此能够挑选几个字段进去。有什么作用？

最开始的

1select id from collect order by id limit 90000,10;

它往往这么快，是由于大家离开指数值，但如果我们再加上where，大家就不会离开指数值。秉着试一试的念头，我加上了一个相近search的数据库索引(vtype，id)。

随后检测。

1select id from collect where vtype=1 limit 90000,10;

十分快！0.04秒进行！

再度检测:

1select id ,title from collect where vtype=1 limit 90000,10;

遗憾8-9秒就错过检索数据库索引！

再度检测:检索(id，vtype)，或是挑选id，这也很遗憾，0.5秒。

总的来说，如果有where标准，又想引入limit，就务必设计方案一个数据库索引，先放where，再放limit应用的外键约束，只挑选外键约束！

它极致地解决了分页查询难题。假如你能迅速回到id，你将有期待提升限定。依照这一逻辑性，上百万極限应当在0.0x秒内进行。看来mysql语句的改善和数据库索引是十分关键的！