程序员过关斩将--小小的分页引起的加班血案

问题分析

经过以上的对话，身为程序员的你是否也遇到过妹子这样的问题呢？传统的并且网上处处充斥着的也是这类方式，客户端根据本身的滚动不断的更新pagesize和pageindex两个参数，而后上传给服务端接口获取数据，并且网络上也不多说明这种方式是否有问题，那到底有没有问题呢？

谈到分页，不管程序怎样写，分页这个业务的核心动做是根据开始位置和结束位置来获取一段数据，不管你的排序规则有多复杂，最终的目的老是获取总列表数据中一段连续的数据。不管你是直接用的sql语句分页，还用的搜索引擎（好比es），最终在客户端体现的效果就是下一页的数据展示。

固然体如今客户端的UI上的交互操做能够有不少样式

若是是瀑布流或者app段滚动展现的方式，或者其余不须要数据总个数的状况下，菜菜认为服务端千万不要查询这个总个数数据，展现方彻底能够如下一页有无数据做为是否继续拉取下一页数据的依据。

话题回归，若是客户端依据pagesize和pageindex参数来进行分页需求，有没有问题呢？固然有，要否则菜菜写这篇文章意义何在，我又不是一个喜欢爱扯淡的程序员~~

问题所在

这里以最简单也是最基本的sql 语句分页为例，假如如今数据库现有数据为

1,2,3,4,5,6,7
复制代码

排序的规则是按照大小倒序，即数据的所有列表为：

7,6,5,4,3,2,1
复制代码

假如如今是获取第二页数据，pagesize为2，pageindex为2，正确结果为 “5,4” 。这无可厚非，在数据未发生改变的状况下，正确结果确实如此，那若是数据发生的变化呢，假如如今新加入一条数据 8，列表数据会变为

8,7,6,5,4,3,2,1
复制代码

那依据以上分页原则，第二页获取的数据就变为了“6,5”，聪明的你是否是发现了问题，这也多是D妹子引起加班的缘由。

分页的操做是创建在动态数据上的操做

解决问题

分页操做的数据源是动态变更的，有时候变更的部分正好发生在你获取的数据范围内，就会发生数据重复或者错误的状况。那怎么解决呢？

客户端

做为数据的需求方和展现方，客户端须要记住已经加载的数据的主键列表，若是某条数据已经展现过，根据业务需求来肯定是否要重复展现，通常状况下须要去重。

若是数据量很是大，客户端维护一个数据池的方案其实也不够理想

服务端

1. 服务端分页接口参数新增上一页最后一条数据id参数lastId，去掉pageindex参数，由于在多数状况下，pageindex参数在服务端的做用是肯定数据的起点而已，若是有了lastid，pageinde在不少状况下其实已经不须要了。
2. 服务端把全部的数据作缓存，这样动态数据在必定时间内静态化，可是这样也是治标不治本。
3. 若是业务上对于排序无要求的话，服务端能够采用顺序分页，把获取的数据落在不会变更的数据段上

服务端要想把动态的数据搞成静态有点难度

业务方

不管程序怎么优化也改变不了数据是在不停变更的本质，若是业务方（产品，运营）可以接受数据在偶尔状况下能重复的现象，那能大幅度减小程序员的工做了。

有时候你认为的数据bug，在其余业务部门不必定是什么重大问题

---

添加关注公众号：架构师修行之路，获取更多精彩内容