数据查询业务中，有时会碰到数据量很大的清单报表。用户输入的查询条件很宽泛，可能会从数据库中查出几百上千万行甚至过亿的记录，如银行的流水记录，物流的明细等。如果等着把这些记录全部检索出来再生成报表呈现，那需要很长时间，用户体验恶劣；而且报表一般采用内存运算机制，大多数情况下也装不下这么多数据。所以，我们一般都是使用分页呈现的方式，尽量快速地呈现出第一页，然后可以随意翻页显示，每次只显示一页，也不会造成内存溢出。
传统下都会使用数据库分页机制来做，利用数据库提供的返回指定行号范围内记录的语法。界面端根据当前页号计算出行号范围（每页显示固定行数）作为参数拼入 SQL 中，数据库就会只返回当前页的记录，从而实现分页呈现的效果。
这样做，会有两个问题：
1. 翻页时效率较差
用这种办法呈现出第一页来一般都会比较快，但如果向后翻页时，这个原始取数的 SQL 会被再次执行，并且将前面页涉及的记录跳过。有些数据库没有 OFFSET 关键字，就只能由界面端自行跳过这些数据（取出后丢弃），像 ORACLE 还需要用子查询产生一个序号才能再用序号做过滤，这些动作都会浪费时间，前几页还感觉不明显，但如果翻到的页号比较大时，就会有等待感了。
2. 可能出现数据不一致
一般来说，每次按页取数时发出的 SQL 是独立的。这样，如果在两页取数之间数据库又有了插入删除动作，这时取出来的数据将是最新的，很可能和原来的页号匹配不上了。比如第 1 页取出 20 行记录后，在取第 2 页前，第 1 页的 20 行记录中被删除了 1 行，那么这时候取出来的第 2 页的第 1 行就会是原来的第 22 行记录，原来的第 21 行会落到第 1 页去了，要再倒翻页才能看到。如果基于这些数据做汇总统计，那会出现错误的结果。
还有一种不常用的方法。向数据库发出取数 SQL 生成游标，从中取出一页后呈现，但并不终止这个游标，要取下一页的时候再继续取数。这种方法能克服上述两个问题，不会发生不一致的现象，但绝大多数的数据库游标只能向后取数而不是倒回去，这样在界面上的表现就是只能向后翻页了，这一点很难向业务用户解释，所以很少用这种办法。
也可以是两种办法的结合，向后翻页时用后一种办法，一旦发生向前翻页时，则重新执行取数 SQL。这样比每次分页取数的体验略好一些，但并没有根本上解决问题。
