秒级展现的百万级大清单报表怎么做

数据查询业务中，有时会碰到数据量很大的清单报表。由于用户输入的查询条件可能很宽泛，因此会从数据库中查出几百上千万甚至过亿行的记录，常见的包括银行流水记录，物流明细等。呈现时如果等着把这些记录全部检索出来再生成报表，那会需要很长时间，用户体验自然会非常恶劣。而且，报表一般采用内存运算机制，大多数情况下内存里也装不下这么多数据。所以，我们一般都会使用分页呈现的方式，尽量快速地呈现出第一页，然后用户可以随意翻页显示，每次只显示一页，也不会造成内存溢出。

传统分页呈现的实现，一般都会使用数据库的分页机制来做，利用数据库提供的返回指定行号范围内记录的语法。界面端根据当前页号计算出行号范围（每页显示固定行数）作为参数拼入 SQL 中，数据库就会只返回当前页的记录，从而实现分页呈现的效果。

不过，这样做会有两个问题：

1. 翻页时效率较差

用这种办法呈现第一页一般都会比较快，但向后翻页时，所使用的取数 SQL 会被再次执行，并且将前面页涉及的记录跳过。对于有些没有 OFFSET 关键字的数据库，就只能由界面端自行跳过这些数据（取出后丢弃），而像 ORACLE 还需要用子查询产生一个序号才能再用序号做过滤。这些动作都会降低效率，浪费时间，前几页还感觉不明显，但如果页号比较大时，翻页就会有等待感了。

2. 可能出现数据不一致

用这种办法翻页，每次按页取数时都需要独立地发出 SQL。这样，如果在两页取数之间又有了插入、删除动作，那么取的数反映的是最新的数据情况，很可能和原来的页号匹配不上。例如，每页 20 行，在第 1 页取出后，用户还没有翻第 2 页前，第 1 页包含的 20 行记录中被删除了 1 行，那么用户翻页时取出的第 2 页的第 1 行实际上是删除操作前的第 22 行记录，而原来的第 21 行实际上落到第 1 页去了，如果要看，还要翻回第 1 页才能看到。如果还要基于取出的数据做汇总统计，那就会出现错误、不一致的结果。

为了克服这两个问题，有时候我们还会用另一种方法，用 SQL 游标从数据库中取数，在取出一页呈现后，但并不终止这个游标，在翻下一页的时候再继续取数。这种方法能有效地克服上述两个问题，翻页效率较高，而且不会发生不一致的情况。不过，绝大多数的数据库游标只能单向从前往后取数，表现在界面上就只能向后翻页了，这一点很难向业务用户交代，所以很少用这种办法。

当然，我们也可以结合这两种办法，向后翻页时用游标，一旦需要向前翻页，就重新执行取数 SQL。这样会比每次分页都重新取数的体验好一些，但并没有在根本上解决问题。  原文内容比较丰富,详情请阅读原文

转载于:https://my.oschina.net/u/3980313/blog/2249077