小分页引起的超时事件问题分析通过上面的对话，作为程序员的你有没有遇到过这样的女生问题呢？这是互联网上随处可见的传统方法。客户端根据自己的滚动不断更新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妹造成超时的原因。分页操作是基于动态数据解决问题的操作。分页操作的数据源是动态变化的。有时变化的部分恰好在你得到的数据范围内，就会出现数据重复或错误。如何解决？客户端作为数据的需求者和展示者，需要记住加载数据的主键列表。如果一条数据已经展示过，根据业务需求决定是否重复展示。一般需要去重。如果数据量很大，客户端维护一个数据池的方案并不理想。服务端分页接口参数添加上一页的最后一个数据id参数lastId，去掉pageindex参数，因为大多数情况下pageindex参数是在服务端的作用是确定数据的起始点。如果有lastid，其实很多时候pageinde是不需要的。服务器缓存所有的数据，让动态的数据在一定时间内是静态的，但这是治标不治本的办法。如果业务中没有排序的需求，服务端可以采用顺序分页的方式，将获取到的数据放在不会变化的数据段上。服务器很难将动态数据静态化。然而，数据的性质是不断变化的。如果业务方（产品、运营）能够接受数据偶尔会重复的现象，可以大大减少程序员的工作量。有时您认为是数据错误的问题在其他业务部门可能不是主要问题
