Gridview实现排序分页，我是用linq去做的~调用Gridview的sort排序也不好使~求源码谢了~

分页可以用第三方控件

或：

1.AllowSorting设为True，aspx代码中是AllowSorting="True"；

2.默认1页10条，如果要修改每页条数，修改PageSize即可，在aspx代码中是PageSize="12"。

3.默认的是单向排序的，右击GridViewd出“属性”，选择AllowSorting为True即可。

如果您需要在Vue表格分页中实现行上移和下移的功能，您需要在后端接口中添加对应的代码逻辑，并在前端中调用相关接口实现 *** 作。下面是实现Vue表格分页行上移和下移接口的一些建议：

1. 在后端接口中添加上移和下移的逻辑：如果您使用的是后端数据接口，您需要在后端代码中添加上移和下移的逻辑，以便在前端调用接口时实现对应的 *** 作。具体实现方式可以根据您的业务逻辑和数据结构来确定。

2. 在前端中调用接口实现上移和下移：在Vue的组件中，您可以通过调用后端接口实现行的上移和下移。您可以在Vue中使用axios等HTTP请求库来调用后端接口，并将接口返回的数据渲染到前端页面中，以实现对表格数据的 *** 作。

3. 实现前端逻辑：除了调用后端接口，您还需要在前端实现上移和下移的逻辑，以便用户可以通过交互 *** 作实现行的上移和下移。具体实现方式可以使用Vue的指令和事件来实现，例如使用v-on指令监听点击事件，并在事件处理函数中调用后端接口实现上移和下移 *** 作。

总之，实现Vue表格分页行上移和下移接口需要在后端中添加相应的代码逻辑，并在前端中调用相关接口实现 *** 作。同时，您还需要在前端实现对应的交互逻辑，以便用户可以通过交互 *** 作实现行的上移和下移。

es实现分页查询，在ES中有三种方式可以实现分页：from+size、scroll、search_after

这种分页方式虽然查询变快了，但滚动上下文代价很高，每一个 scroll_id 不仅会占用大量的资源（特别是排序的请求），而且是生成的历史快照，对于数据的变更不会反映到快照上,那么在实时情况下如果处理深度分页的问题呢？es 给出了 search_after 的方式，这是在 >= 5.0 版本才提供的功能。

searchAfter的方式通过维护一个实时游标来避免scroll的缺点，它可以用于实时请求和高并发场景。

search_after的理念是，=在不同分片上（假设有5个分片），先按照指定顺序排好，根据我们传的search_after值 ，然后仅取这个值之后的size个文档。这 5*size 个文档拿到Es内存中排序后，返回前size个文档即可。避免了浅分页导致的内存爆炸情况，经实际使用性能良好,ES空闲状态下查询耗时稳定在50ms以内，平均10~20ms。

ElasticSearch之Search_After的注意事项

1.搜索时，需要指定sort,并且保证值是唯一的（可以通过加入_id或者文档body中的业务唯一值来保证）；

2.再次查询时，使用上一次最后一个文档的sort值作为search_after的值来进行查询；

3.不能使用随机跳页，只能是下一页或者小范围的跳页（一次查询出小范围内各个页数，利用缓存等技术，来实现小范围分页，比较麻烦，比如从第一页调到第五页，则依次查询出2,3,4页的数据，利用每一次最后一个文档的sort值进行下一轮查询，客户端或服务端都可以进行，如果跳的比较多，则可能该方法并不适用）

它与滚动API非常相似，但与它不同，search_after参数是无状态的，它始终针对最新版本的搜索器进行解析。因此，排序顺序可能会在步行期间发生变化，具体取决于索引的更新和删除

from+ size 分页，如果数据量不大或者from、size不大的情况下，效率还是蛮高的。但是在深度分页的情况下，这种使用方式效率是非常低的，并发一旦过大，还有可能直接拖垮整个ElasticSearch的集群。

scroll 分页通常不会用在客户端，因为每一个 scroll_id 都会占用大量的资源，一般是后台用于全量读取数据使用

search_after通过维护一个实时游标来避免scroll的缺点，它可以用于实时请求和高并发场景，一般用于客户端的分页查询

大体而言就是在这三种分页方式中，from + size不适合数据量很大的场景，scroll不适合实时场景，而search after在es5.x版本之后应运而生，较好的解决了这个问题。

---