不知道你们有没有听说过这样的分页需求：
将每个用户的查询每次的查询情况缓存起来，然后将它查第二页时，直接从缓存中获取，除非其查询第一页。
这样的理由在于，后台的数据在不断地增加中，你现在看到的第一页，或许在下一个时刻，就发生了变化。而如果此时你要看第二页，是需要基于上一次查询的第二页，而不是重新排序的第二页，因为此时，有可能会出现之前看到的第一页数据，或者比之前第一页的数据更靠前（因数据增加得很快，重新排序在上一次第一页前面）。
基于此，当时的其它人说，之前就是将数据缓存起来，有个时间，如果查了，就给显示，不查过期失效，并且，这个缓存是针对Session或内存做的。
我对于此很排斥的，因为这个设计真的很烂。烂到如果客户的数据比较多，可能几个，几十个客户就可能把一台机器查崩。当时也只是问了下，并没有继续做下去。并且，内存资源的极大浪费。
有没有发现一个问题，前面的需求中，出现查第二页时，数据紊乱的情况，是逆序排序的情况下，正序情况下是不可能出现这种情况，除非数据库条目插入时，是逆序的（相当于，我先插入一个id = 10，再插入一个id = 9 ）。
现在重新思考这个问题，发现有其它的方法可以处理该问题。首先先明确几个前提：
1、我们并不是为了性能，即客户响应速度而需要将其放在缓存
2、我们后台数据增加得或许很快，但是不会出现删除数据的情况。比如，交易流水
3、显示的数据，不是以数据库的插入顺序为准的，而是有一定的排序规则
基于此，我们来思考下，有什么什么方案，至少优于前者的方案，来实现这个需求。
我们分页显示的数据，一般都有一个排序规则，有可能是主键id，也有可能是时间戳……那么，我们是否可以将本次查询的最后一条数据的排序规则作为一个参数来上送，进行查询。
即，第一次查询时，走默认查询逻辑，仅提供查询条件及查询条目，后台返回数据及存在的总数据条目。（此时后台执行了两次数据查询，一次计数，一次查询。有些项目将其改为了一次，但是那个执行逻辑就我看，很烂，还不如分开）
非第一次查询时，提供上一次查询最后的一条数据的排序游标，及查询条目。此时后台就会根据这个条件取相应的数据，并且此时后台执行的数据库查询逻辑是一次，不存在计数的逻辑了。
我会在下一篇中，再详细地思考下，这样的执行逻辑及实现方案。以及其优势所在