13518219792
很多应用往往只展示最新或最热门的几条记录，但为了旧记录仍然可访问，所以就需要个分页的导航栏。然而，如何通过MySQL更好的实现分页，始终是比较令人头疼的问题。虽然没有拿来就能用的解决办法，但了解数据库的底层或多或少有助于优化分页查询。
10多年的东港网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。成都全网营销的优势是能够根据用户设备显示端的尺寸不同，自动调整东港建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联从事“东港网站设计”,“东港网站推广”以来，每个客户项目都认真落实执行。
我们先从一个常用但性能很差的查询来看一看。
SELECT *
FROM city
ORDER BY id DESC
LIMIT 0, 15
这个查询耗时0.00sec。So，这个查询有什么问题呢？实际上，这个查询语句和参数都没有问题，因为它用到了下面表的主键，而且只读取15条记录。
CREATE TABLE city (
id int(10) unsigned NOT NULL AUTO_INCREMENT,
city varchar(128) NOT NULL,
PRIMARY KEY (id)
) ENGINE=InnoDB;
真正的问题在于offset(分页偏移量)很大的时候，像下面这样：
SELECT *
FROM city
ORDER BY id DESC
LIMIT 100000, 15;
上面的查询在有2M行记录时需要0.22sec，通过EXPLAIN查看SQL的执行计划可以发现该SQL检索了100015行，但最后只需要15行。大的分页偏移量会增加使用的数据，MySQL会将大量最终不会使用的数据加载到内存中。就算我们假设大部分网站的用户只访问前几页数据，但少量的大的分页偏移量的请求也会对整个系统造成危害。Facebook意识到了这一点，但Facebook并没有为了每秒可以处理更多的请求而去优化数据库，而是将重心放在将请求响应时间的方差变小。
对于分页请求，还有一个信息也很重要，就是总共的记录数。我们可以通过下面的查询很容易的获取总的记录数。
SELECT COUNT(*)
FROM city;
然而，上面的SQL在采用InnoDB为存储引擎时需要耗费9.28sec。一个不正确的优化是采用 SQL_CALC_FOUND_ROWS,SQL_CALC_FOUND_ROWS 可以在能够在分页查询时事先准备好符合条件的记录数，随后只要执行一句 select FOUND_ROWS(); 就能获得总记录数。但是在大多数情况下，查询语句简短并不意味着性能的提高。不幸的是，这种分页查询方式在许多主流框架中都有用到，下面看看这个语句的查询性能。
SELECT SQL_CALC_FOUND_ROWS *
FROM city
ORDER BY id DESC
LIMIT 100000, 15;
这个语句耗时20.02sec，是上一个的两倍。事实证明使用 SQL_CALC_FOUND_ROWS 做分页是很糟糕的想法。
下面来看看到底如何优化。文章分为两部分，第一部分是如何获取记录的总数目，第二部分是获取真正的记录。
高效的计算行数
如果采用的引擎是MyISAM，可以直接执行COUNT(*)去获取行数即可。相似的，在堆表中也会将行数存储到表的元信息中。但如果引擎是InnoDB情况就会复杂一些，因为InnoDB不保存表的具体行数。
我们可以将行数缓存起来，然后可以通过一个守护进程定期更新或者用户的某些操作导致缓存失效时，执行下面的语句：
SELECT COUNT(*)
FROM city
USE INDEX(PRIMARY);
获取记录
下面进入这篇文章最重要的部分，获取分页要展示的记录。上面已经说过了，大的偏移量会影响性能，所以我们要重写查询语句。为了演示，我们创建一个新的表“news”，按照时事性排序(最新发布的在最前面)，实现一个高性能的分页。为了简单，我们就假设最新发布的新闻的Id也是最大的。
CREATE TABLE news(
id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(128) NOT NULL
) ENGINE=InnoDB;
一个比较高效的方式是基于用户展示的最后一个新闻Id。查询下一页的语句如下，需要传入当前页面展示的最后一个Id。
SELECT *
FROM news WHERE id $last_id
ORDER BY id DESC
LIMIT $perpage
查询上一页的语句类似，只不过需要传入当前页的第一个Id，并且要逆序。
SELECT *
FROM news WHERE id $last_id
ORDER BY id ASC
LIMIT $perpage
上面的查询方式适合实现简易的分页，即不显示具体的页数导航，只显示“上一页”和“下一页”，例如博客中页脚显示“上一页”，“下一页”的按钮。但如果要实现真正的页面导航还是很难的,下面看看另一种方式。
SELECT id
FROM (
SELECT id, ((@cnt:= @cnt + 1) + $perpage - 1) % $perpage cnt
FROM news
JOIN (SELECT @cnt:= 0)T
WHERE id $last_id
ORDER BY id DESC
LIMIT $perpage * $buttons
)C
WHERE cnt = 0;
通过上面的语句可以为每一个分页的按钮计算出一个offset对应的id。这种方法还有一个好处。假设，网站上正在发布一片新的文章，那么所有文章的位置都会往后移一位，所以如果用户在发布文章时换页，那么他会看见一篇文章两次。如果固定了每个按钮的offset Id，这个问题就迎刃而解了。Mark Callaghan发表过一篇类似的博客，利用了组合索引和两个位置变量，但是基本思想是一致的。
如果表中的记录很少被删除、修改，还可以将记录对应的页码存储到表中，并在该列上创建合适的索引。采用这种方式，当新增一个记录的时候，需要执行下面的查询重新生成对应的页号。
SET p:= 0;
UPDATE news SET page=CEIL((p:= p + 1) / $perpage) ORDER BY id DESC;
当然，也可以新增一个专用于分页的表，可以用个后台程序来维护。
UPDATE pagination T
JOIN (
SELECT id, CEIL((p:= p + 1) / $perpage) page
FROM news
ORDER BY id
)C
ON C.id = T.id
SET T.page = C.page;
现在想获取任意一页的元素就很简单了：
SELECT *
FROM news A
JOIN pagination B ON A.id=B.ID
WHERE page=$offset;
还有另外一种与上种方法比较相似的方法来做分页，这种方式比较试用于数据集相对小，并且没有可用的索引的情况下—比如处理搜索结果时。在一个普通的服务器上执行下面的查询，当有2M条记录时，要耗费2sec左右。这种方式比较简单，创建一个用来存储所有Id的临时表即可(这也是最耗费性能的地方)。
CREATE TEMPORARY TABLE _tmp (KEY SORT(random))
SELECT id, FLOOR(RAND() * 0x8000000) random
FROM city;
ALTER TABLE _tmp ADD OFFSET INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, DROP INDEX SORT,ORDER BY random;
接下来就可以向下面一样执行分页查询了。
SELECT *
FROM _tmp
WHERE OFFSET = $offset
ORDER BY OFFSET
LIMIT $perpage;
简单来说，对于分页的优化就是。。。避免数据量大时扫描过多的记录。
一、mysql 使用limit 子句来实现数据库的物理分页，limit 子句接受 一个或两个参数，第一个参数指定第一个返回记录行的偏移量，第二个参数指定返回记录行的最大数量。在mybatis 中，只需要在相 应的查询语句后，加上limit 子句，即可实现物理分页。如下，以 一个只有字段id，name，age 的表为例。该配置会根据传入的 hashmap，如果含有键start 和键end，那么即通过mybatis 强大的 动态sql，生成含有mysql 分页的sql语句。 select * from users limit #{start},#{end}
二、mybaits 简介
mybatis，前称ibatis，后改名为mybatis，截止本文成文，最新 版本是3.0.6。它和hibernate 是java世界使用最多的两种orm 框 架。hibernate 理念最为先进，完全实现面向对象的数据库编程，不需要掌握sql 语句，即可实现数据库操作，能够节省开发人员编 写大量sql语句的时间。但是，hibernate 在处理多表关联时，可 能会出现n+1 问题，性能会有较大影响，要解决性能问题，需要较 深的hibernate 知识和项目经验。mybatis 需要自己写sql 语句， 开发效率不如hibernate，很难做到底层多数据库的通用。但对程 序员来说有更高的可控性，可以更容易的对sql 语句进行优化，提 高效率。
在开发中直接使用jdbc 一个非常普遍的问题就是动态sql。如果 参数值、参数本身和数据列都是动态sql，通常的解决方法就是写很多if-else 条件语句和字符串连接。而mybatis 通过ognl 提供 了一套非常清晰的方法来解决动态sql 的问题。
语法格式：
SELECT 子句
LIMIT(偏移量，行数);
注意：偏移量从0开始。
例：查询前10条产品记录
SELECT * FROM Product LIMIT(0,10);
例：查询第21-30条产品记录
SELECT * FROM Product LIMIT(29,10);
在 Web 应用程序中跨大型数据集分页记录似乎是一个简单的问题，但实际上很难扩展。两种主要的分页策略是偏移/限制和游标。
我们将首先看一下这两种方法，然后稍作修改，可以使偏移/限制非常高效。
偏移/限制分页
偏移/限制方法是迄今为止最常见的方法，它通过跳过一定数量的记录（页）并将结果限制为一页来工作。
例如，假设您的应用程序配置为每页显示 15 条记录。您的 SQL 将如下所示：
这是最常见的，因为它非常简单，易于推理，并且几乎每个框架都支持它。
除了易于实现之外，它还具有页面可直接寻址的优点。例如，如果您想直接导航到第 20 页，您可以这样做，因为该偏移量很容易计算。
但是有一个主要的缺点，它潜伏在数据库处理偏移量的方式中。偏移量告诉数据库放弃从查询中返回的前N个结果。不过数据库仍然要从磁盘上获取这些行。
如果你丢弃的是100条记录，这并不重要，但如果你丢弃的是100,000条记录，数据库就会为了丢弃这些结果而做大量的工作。
在实践中，这意味着第一个页面会快速加载，之后的每一个页面都会变得越来越慢，直到你达到一个点，网络请求可能会直接超时。
基于游标的分页
基于游标的分页弥补了偏移/限制的一些不足，同时引入了一些自己的不足。
基于游标的分页是通过存储一些关于最后呈现给用户的记录的状态，然后根据这个状态来进行下一次查询。
因此，它不是按顺序获取所有的记录并丢弃前N条，而是只获取最后一个位置N之后的记录。
如果按ID排序，SQL可能看起来像这样。
你可能已经看到了其中的好处。因为我们知道上次向用户展示的ID，我们知道下一个页面将以一个更高的ID开始。我们甚至不需要检查ID较低的行，因为我们百分之百肯定地知道那些行不需要被显示。
在上面的例子中，我特别说明了ID可能不是连续的，也就是说，可能有缺失的记录。这使得我们无法计算出哪些记录会出现在某一页面上，你必须跟踪之前那一页面上的最后一条记录是什么。
与偏移/限制分页不同，使用游标分页时，页面不能直接寻址，你只能导航到 "下一页 "或 "上一页"。
不过光标分页的好处是在任何数量的页面上都很迅速。它也很适合无限滚动，在这种情况下，页面首先不需要可以直接寻址。
Laravel文档中有一些关于偏移量和游标之间的权衡的好的背景。
cursor -vs-offset-pagination
考虑到所有这些，让我们来看看一个偏移/限制优化，可以使它的性能足以在成千上万的页面上使用。
使用递延join的Offset/Limit
递延连接（deferred join ）是一种技术，它将对要求的列的访问推迟到应用了偏移量和限制之后。
使用这种技术，我们创建一个内部查询，可以用特定的索引进行优化，以获得最大的速度，然后将结果连接到同一个表，以获取完整的行。
它看起来像这样：
这种方法的好处可以根据你的数据集有很大的不同，但是这种方法允许数据库尽可能少地检查数据，以满足用户的意图。
查询中 "昂贵的 "select *部分只在与内部查询相匹配的15条记录上运行。所有数据的Select都被推迟了，因此被称为推迟join。
这种方法不太可能比传统的偏移/限制性能差，尽管它是可能的，所以一定要在你的数据上进行测试!
Laravel实现
我们如何把这一点带到我们最喜欢的网络框架，如Laravel和Rails？
让我们具体看看Laravel，因为我不知道Rails。
感谢Laravel的macroable特性，我们可以扩展Eloquent Query Builder来添加一个新的方法，叫做deferredPaginate。为了保持一致性，我们将模仿常规分页的签名。
我们将尝试做尽可能少的自定义工作，并将大部分工作留给 Laravel。
这是我们要做的：
这应该为我们提供 LaravelLengthAwarePaginator 和延迟连接的所有好处！
一个Github仓库
递延Join和覆盖索引
还没有完成...
使用递延Join的主要好处是减少了数据库必须检索然后丢弃的数据量。我们可以通过帮助数据库获得它需要的数据而更进一步，而无需获取底层行。
这样做的方法称为“覆盖索引covering index”，它是确保快速偏移/限制分页的最终解决方案。
覆盖索引是一个索引，在这个索引中，查询的所有需要的字段都包含在索引本身中。当一个查询的所有部分都能被一个索引 "覆盖 "时，数据库根本不需要读取该行，它可以从索引中获得它需要的一切。
请注意，覆盖索引并不是以任何特殊方式创建的。它只是指一个索引满足了一个查询所需要的一切的情况。一个查询上的覆盖索引很可能不是另一个查询上的覆盖索引。
在接下来的几个例子中，我们将使用这个基本的表，我把它填满了~1000万条记录。
让我们看一个仅select索引列的简单查询。在这种情况下，我们将从email表中进行select contacts。
在这种情况下，数据库根本不需要读取基础行。在MySQL中，我们可以通过运行一个解释并查看额外的列来验证这一点：
extra: using index告诉我们，MySQL能够只使用索引来满足整个查询，而不看基础行。
如果尝试select name from contacts limit 10， 我们将期望MySQL必须到该行去获取数据，因为名字name没有被索引。这正是发生的情况，由下面的解释显示。
extra不再显示 using index，所以我们没有使用覆盖索引。
假设你每页有15条记录，你的用户想查看第1001页，你的内部查询最终会是这样的。
select id from contacts order by id limit 15 OFFSET 150000
explain结果显示：
MySQL能够单看索引来执行这个查询。它不会简单地跳过前15万行，在使用offset是没有办法的，但它不需要读取15万行。(只有游标分页可以让你跳过所有的行）。
即使使用覆盖索引和延迟连接，当你到达后面的页面时，结果也会变慢，尽管与传统的偏移/限制相比，它应该是最小的。使用这些方法，你可以轻易地深入到数千页。
更好的覆盖索引
这里的很多好处取决于拥有良好的覆盖索引，所以让我们稍微讨论一下。一切都取决于您的数据和用户的使用模式，但是您可以采取一些措施来确保查询的最高命中率。
这将主要与 MySQL 对话，因为那是我有经验的地方。其他数据库中的情况可能会有所不同。
大多数开发人员习惯于为单列添加索引，但没有什么能阻止您向多列添加索引。事实上，如果您的目标是为昂贵的分页查询创建覆盖索引，您几乎肯定需要一个多列索引。
当你试图为分页优化一个索引时，一定要把按列排序放在最后。如果你的用户要按update_at排序，这应该是你复合索引中的最后一列。
看看下面这个包括三列的索引。
在MySQL中，复合索引是从左到右访问的，如果一个列缺失，或者在第一个范围条件之后，MySQL会停止使用一个索引。
MySQL 将能够在以下场景中使用该索引：
如果你跳过is_archived，MySQL将无法访问update_at，将不得不诉诸于没有该索引的排序，或者根本不使用该索引，所以要确保你有相应的计划。
主键始终存在
在MySQL的InnoDB中，所有的索引都附加了主键。这意味着（email）的索引实际上是（email，id）的索引，当涉及到覆盖索引和延迟连接时，这是相当重要的。
查询select email from contacts order by id完全被email上的一个索引所覆盖，因为InnoDB将id附加到了该索引上。
使用我们上面的综合例子，你可以看到这有什么好处。
因为复合索引涵盖了is_deleted, is_archived, updated_at, 和（通过InnoDB的功能）id，整个查询可以仅由索引来满足。
降序索引
大多数时候，用户都在寻找 "最新的 "项目，即最近更新或创建的项目，这可以通过按update_at DESC排序来满足。
如果你知道你的用户主要是以降序的方式对他们的结果进行排序，那么特别将你的索引设为降序索引可能是有意义的。
MySQL 8是第一个支持降序索引的MySQL版本。
如果你在explain的Extra部分看到向后索引扫描，你也许可以配置一个更好的索引。
前向索引扫描比后向扫描快~15%，所以你要按照你认为你的用户最常使用的顺序添加索引，并为少数使用情况承担惩罚。
太阳底下无新事
这种使用偏移/限制分页与延迟连接和覆盖索引的方法并不是银弹。
仅仅是递迟连接就可以让你的速度得到很好的提升，但是需要花一些额外的心思来设计正确的索引以获得最大的好处。
有一种观点认为，递延连接应该是框架中默认的偏移offset/限制limit方法，而任何时候覆盖索引的出现都只是一种奖励。我还没有在足够多的生产环境中测试过，所以还没有强烈主张这样做。
使用MySQL的递延Join连接实现高效分页 - Aaron
分页一般有两种方式，假如你每页只显示20条数据：
一 把所有的结果集都查询出来放到一个集合中，然后在第一页从该集合中取出前20条显示到页面上。点击下一页，再从该集合中取出21--40条显示到页面上。二 就是利用mysql的limit语句，把页码传到底层数据库，用户翻一页就执行一次查询，查出该页要显示的内容。
例如：select * from 表 limit 0,20;取1--20的记录
select * from 表 limit 20,20;取21--40的记录
其中limit后面的第一个参数是偏移量，相当于从哪行记录开始查询
第二个参数是要取出的记录数
我认为第二种方式比较好，因为假设结果集是1万条，如果用第一种方式一下子取到集合里再分页，太浪费资源。
而第二种方式，用户看翻10页它就查200条，看100页就取2000条。比较节省资源，反正用户都比较懒，一般都不会从第一页一直翻到最后一页 :）
这两种方式，网上代码有不少，这里就不多说了，祝你顺利！
pageNow代表当前页面，第一页。
第一部分：看一下分页的基本原理：
对上面的mysql语句说明：limit 10000,20的意思扫描满足条件的10020行，扔掉前面的10000行，返回最后的20行，问题就在这里，如果是limit 100000,100，需要扫描100100行，在一个高并发的应用里，每次查询需要扫描超过10W行，性能肯定大打折扣。文中还提到limit n性能是没问题的，因为只扫描n行。
第二部分：根据雅虎的几位工程师带来了一篇Efficient Pagination Using MySQL的报告内容扩展：在文中提到一种clue的做法，给翻页提供一些线索，比如还是SELECT * FROM message ORDER BY id DESC，按id降序分页，每页20条，当前是第10页，当前页条目id最大的是1020，最小的是1000，如果我们只提供上一页、下一页这样的跳转（不提供到第N页的跳转），那么在处理上一页的时候SQL语句可以是：
处理下一页的时候SQL语句可以是：
不管翻多少页，每次查询只扫描20行。
缺点是只能提供上一页、下一页的链接形式，但是我们的产品经理非常喜欢“上一页 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最大的是2519，最小的是2500;
当是第10页的SQL如下：
比如要跳到第9页，SQL语句可以这样写：
比如要跳到第8页，SQL语句可以这样写：
原理还是一样，记录住当前页id的最大值和最小值，计算跳转页面和当前页相对偏移，由于页面相近，这个偏移量不会很大，这样的话m值相对较小，大大减少扫描的行数。其实传统的limit m,n，相对的偏移一直是第一页，这样的话越翻到后面，效率越差，而上面给出的方法就没有这样的问题。
