商城项目中，如果进行分页的话，在跳转页面的过程中，肯定要带多个参数条件进行数据库查询，那URL请求参数

其实可以在文件开头把页面URL所带的参数先读取，并赋值给一个变量。这个变量一直不参与运算。除非中途参数有变，则以数组的方式把参数分析修改。之后再重新赋值给这个变量 。

在文件中引用时，都把这个变量的值引过去，这样就方便很多了。平时用到的参数引用，还有用表单元素来引用的。看个人喜好了。至于用aJax……我没试过。不过感觉比较复杂，毕竟要用两种语言来描述一个页面，对服务器也是有压力的。

在这些控件里要达到分页的效果，一般都会传2个参数，第一个是表示当前页的索 引（一般从0开始），第二个表示当前页展示多少条业务记录，然后将相应的参数传递给List getList(PagenateArgs args)方法，最终实现数据库中的分页时候可以使用

最简单的方法就是把条件放到URL里面、第一个参数要用取、第二个和第一个之间要加&

下个页面 用 requestgetParameter("a")取

比如：

windowlocation = >

Elasticsearch 是一个实时的分布式搜索与分析引擎，在使用过程中，有一些典型的使用场景，比如分页、遍历等。

在使用关系型数据库中，我们被告知要注意甚至被明确禁止使用深度分页，同理，在 Elasticsearch 中，也应该尽量避免使用深度分页。

这篇文章主要介绍 Elasticsearch 中分页相关内容！

在ES中，分页查询默认返回最顶端的10条匹配hits。

如果需要分页，需要使用from和size参数。

一个基本的ES查询语句是这样的：

上面的查询表示从搜索结果中取第100条开始的10条数据。

「那么，这个查询语句在ES集群内部是怎么执行的呢？」

在ES中，搜索一般包括两个阶段，query 和 fetch 阶段，可以简单的理解，query 阶段确定要取哪些doc，fetch 阶段取出具体的 doc。

如上图所示，描述了一次搜索请求的 query 阶段：·

在上面的例子中，coordinating node 拿到 (from + size) 6 条数据，然后合并并排序后选择前面的 from + size 条数据存到优先级队列，以便 fetch 阶段使用。

另外，各个分片返回给 coordinating node 的数据用于选出前 from + size 条数据，所以，只需要返回唯一标记 doc 的 _id 以及用于排序的 _score 即可，这样也可以保证返回的数据量足够小。

coordinating node 计算好自己的优先级队列后，query 阶段结束，进入 fetch 阶段。

query 阶段知道了要取哪些数据，但是并没有取具体的数据，这就是 fetch 阶段要做的。

上图展示了 fetch 过程：

coordinating node 的优先级队列里有 from + size 个 _doc _id ，但是，在 fetch 阶段，并不需要取回所有数据，在上面的例子中，前100条数据是不需要取的，只需要取优先级队列里的第101到110条数据即可。

需要取的数据可能在不同分片，也可能在同一分片，coordinating node 使用 「multi-get」 来避免多次去同一分片取数据，从而提高性能。

「这种方式请求深度分页是有问题的：」

我们可以假设在一个有 5 个主分片的索引中搜索。当我们请求结果的第一页（结果从 1 到 10 ），每一个分片产生前 10 的结果，并且返回给 协调节点 ，协调节点对 50 个结果排序得到全部结果的前 10 个。

现在假设我们请求第 1000 页—结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前10010个结果以外。然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。

「对结果排序的成本随分页的深度成指数上升。」

「注意1：」

size的大小不能超过 indexmax_result_window 这个参数的设置，默认为10000。

如果搜索size大于10000，需要设置 indexmax_result_window 参数

「注意2：」

_doc 将在未来的版本移除，详见：

Elasticsearch 的From/Size方式提供了分页的功能，同时，也有相应的限制。

举个例子，一个索引，有10亿数据，分10个 shards，然后，一个搜索请求，from=1000000，size=100，这时候，会带来严重的性能问题：CPU，内存，IO，网络带宽。

在 query 阶段，每个shards需要返回 1000100 条数据给 coordinating node，而 coordinating node 需要接收 10 1000 ，100 条数据，即使每条数据只有 _doc _id 和 _score ，这数据量也很大了？

「在另一方面，我们意识到，这种深度分页的请求并不合理，因为我们是很少人为的看很后面的请求的，在很多的业务场景中，都直接限制分页，比如只能看前100页。」

比如，有1千万粉丝的微信大V，要给所有粉丝群发消息，或者给某省粉丝群发，这时候就需要取得所有符合条件的粉丝，而最容易想到的就是利用 from + size 来实现，不过，这个是不现实的，这时，可以采用 Elasticsearch 提供的其他方式来实现遍历。

深度分页问题大致可以分为两类：

「下面介绍几个官方提供的深度分页方法」

我们可以把scroll理解为关系型数据库里的cursor，因此，scroll并不适合用来做实时搜索，而更适合用于后台批处理任务，比如群发。

这个分页的用法， 「不是为了实时查询数据」 ，而是为了 「一次性查询大量的数据（甚至是全部的数据」 ）。

因为这个scroll相当于维护了一份当前索引段的快照信息，这个快照信息是你执行这个scroll查询时的快照。在这个查询后的任何新索引进来的数据，都不会在这个快照中查询到。

但是它相对于from和size，不是查询所有数据然后剔除不要的部分，而是记录一个读取的位置，保证下一次快速继续读取。

不考虑排序的时候，可以结合 SearchTypeSCAN 使用。

scroll可以分为初始化和遍历两部，初始化时将 「所有符合搜索条件的搜索结果缓存起来（注意，这里只是缓存的doc_id，而并不是真的缓存了所有的文档数据，取数据是在fetch阶段完成的）」 ，可以想象成快照。

在遍历时，从这个快照里取数据，也就是说，在初始化后，对索引插入、删除、更新数据都不会影响遍历结果。

「基本使用」

初始化指明 index 和 type，然后，加上参数 scroll，表示暂存搜索结果的时间，其它就像一个普通的search请求一样。

会返回一个 _scroll_id ， _scroll_id 用来下次取数据用。

「遍历」

这里的 scroll_id 即 上一次遍历取回的 _scroll_id 或者是初始化返回的 _scroll_id ，同样的，需要带 scroll 参数。

重复这一步骤，直到返回的数据为空，即遍历完成。

「注意，每次都要传参数 scroll，刷新搜索结果的缓存时间」 。另外， 「不需要指定 index 和 type」 。

设置scroll的时候，需要使搜索结果缓存到下一次遍历完成， 「同时，也不能太长，毕竟空间有限。」

「优缺点」

缺点：

「优点：」

适用于非实时处理大量数据的情况，比如要进行数据迁移或者索引变更之类的。

ES提供了scroll scan方式进一步提高遍历性能，但是scroll scan不支持排序，因此scroll scan适合不需要排序的场景

「基本使用」

Scroll Scan 的遍历与普通 Scroll 一样，初始化存在一点差别。

需要指明参数：

「Scroll Scan与Scroll的区别」

如果你数据量很大，用Scroll遍历数据那确实是接受不了，现在Scroll接口可以并发来进行数据遍历了。

每个Scroll请求，可以分成多个Slice请求，可以理解为切片，各Slice独立并行，比用Scroll遍历要快很多倍。

上边的示例可以单独请求两块数据，最终五块数据合并的结果与直接scroll scan相同。

其中max是分块数，id是第几块。

Search_after 是 ES 5 新引入的一种分页查询机制，其原理几乎就是和scroll一样，因此代码也几乎是一样的。

「基本使用：」

第一步：

返回出的结果信息 ：

上面的请求会为每一个文档返回一个包含sort排序值的数组。

这些sort排序值可以被用于 search_after 参数里以便抓取下一页的数据。

比如，我们可以使用最后的一个文档的sort排序值，将它传递给 search_after 参数：

若我们想接着上次读取的结果进行读取下一页数据，第二次查询在第一次查询时的语句基础上添加 search_after ，并指明从哪个数据后开始读取。

「基本原理」

es维护一个实时游标，它以上一次查询的最后一条记录为游标，方便对下一页的查询，它是一个无状态的查询，因此每次查询的都是最新的数据。

由于它采用记录作为游标，因此 「SearchAfter要求doc中至少有一条全局唯一变量（每个文档具有一个唯一值的字段应该用作排序规范）」

「优缺点」

「优点：」

「缺点：」

SEARCH_AFTER 不是自由跳转到任意页面的解决方案，而是并行滚动多个查询的解决方案。

分页方式性能优点缺点场景 from + size低灵活性好，实现简单深度分页问题数据量比较小，能容忍深度分页问题 scroll中解决了深度分页问题无法反应数据的实时性（快照版本）维护成本高，需要维护一个 scroll_id海量数据的导出需要查询海量结果集的数据 search_after高性能最好不存在深度分页问题能够反映数据的实时变更实现复杂，需要有一个全局唯一的字段连续分页的实现会比较复杂，因为每一次查询都需要上次查询的结果，它不适用于大幅度跳页查询海量数据的分页

参照：>

以上就是关于商城项目中，如果进行分页的话，在跳转页面的过程中，肯定要带多个参数条件进行数据库查询，那URL请求参数全部的内容，包括:商城项目中，如果进行分页的话，在跳转页面的过程中，肯定要带多个参数条件进行数据库查询，那URL请求参数、mybaties获取列表信息 怎样传入分页参数、tp5分页怎么添加参数，搜索的时候第二页没有参数了等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！