关于分页查询的疑惑

以前发在CSDN的一篇blog，但是没有人回复。这是我一直疑惑的问题。原文如下：
http://blog.csdn.net/catstiger/archive/2006/08/31/1148015.aspx

分页查询是经常能够遇到的问题，我们首先看看分页查询存在的理由:

方便用户：用户不可能一次察看所有数据，所以一页一页的翻看比较好。
提高性能：一次从数据库中提取所有数据会比较慢。

那么现在我来尝试反驳上述理由：

真的方便吗？我们考虑下面的情况
[list=]如果数据只有20条。
如果数据超过1000条。[/list]
第一种显然不必分页查询。奇怪的是第二种也不必，因为没有哪个用户愿意一页一页的翻到最后，如果用户查询到的数据超过了他所关心的数据范围，我认为应该让他重新输入查询条件，就像我们使用google一样。
但是作为一个友好的应用界面，我们总是希望用户可以全面的了解他的查询结果，所以有必要告诉用户：“你查到了多少数据，但是，目前只能显示前1000条，如果您希望察看所有数据，那么应该如何如何... ”
性能会提高吗？
如果数据量很小，显然性能不会有明显的提升，相反，性能会大大下降。因为数据库执行了不必要的查询和查询条件。
如果数据量很大，性能也不见得有明显提升，因为你总是要执行一个额外的count查询。当然，这要看实际情况了。
可以想像，分页查询对于性能的影响和数据量之间的关系应该是一个曲线，数据量小的时候会降低性能，数据量大的时候可能（根据不同的数据库）会提升性能。关键是通过测试，找到曲线的拐点。性能不是根据经验和感觉得到的，而是通过测试得到的
另外，如果一次全部取出数据，的确会造成空间性能的影响，但是，现在内存很便宜...
分页查询的负面影响
对于一个架构良好的web应用，将pageNo和PageSize在各个类之间传递实在是不爽，这两个数据明显属于表现层。
分页查询还会明显提高编程复杂度。
奇怪的现象：为什么没有一个大型数据库直接提供分页查询？Oracle的RowNo不是用于分页的，SQLServer的Top更不是。
结论
ExtremeTable、DisplayTag、JSF DataTable都提供了简单的分页方式，那就是在结果集合中分页。使用非常方便，而且使得逻辑清晰，大大提高了工作效率。绝大多数情况下，可以直接使用这种方式。
如果通过测试，发现上述方式影响了性能，那么考虑使用分页查询。
对于用户量很大的应用，因为内存的原因，也可以考虑分页查询。但是，我个人更推荐缓存方式：同样的查询放在一个缓存中...
采用合理的设计，屏蔽开发人员处理分页逻辑。比如，将分页逻辑和count查询放在父类，开发人员负责组合查询条件。具体看设计模式吧。
欢迎大家讨论！！！

评论

18 楼 cats_tiger 2006-10-25  

引用 写道

分页很简单啊，没有多运行什么所谓的查询条件，只是当查询出等于pageSize的数量时暂停查询而已啊，已经查出来的数据会放在数据库缓存中，等再次查询时，也可以提高数据库缓存命中率。不能理解性能如何大大下降啊。

我所说的“额外的查询”是指那个count查询，如果不加查询条件，count是很快的，如果加查询条件并且不走索引，count查询就很慢了。多数分页查询，都要执行一个count查询吧，它不会影响性能吗？

17 楼 dwangel 2006-10-24  

我的意见：

1。 请把数据库限定范围查询和页面数据分页分开。
2。数据库限定范围查询应该是利用Sql中的限定方式，比如msyql 的 limit， sqlserver的top，获取一定范围的结果集。在数据量很大时，数据库限定范围查询确实可以提高数据库访问性能。
3。页面数据分页。用户有时候不一定需要一次看到所有数据，比如搜索引擎的结果。或者数据太长，一次性全部展示，对服务器负担太重。这时候就需要页面数据分页。 如果不做分页，而一次性全部展示，在数据量大时，浏览页面也常常会出现显示不完整和超时的问题。

4。完整的分页处理，应该同时包含 数据库限定范围查询和页面数据的分页。 相对麻烦一些。有时候，有的程序员往往只作页面数据分页，从而导致数据库的压力并没有减轻多少。

此外，楼主说的

引用

奇怪的现象：为什么没有一个大型数据库直接提供分页查询？Oracle的RowNo不是用于分页的，SQLServer的Top更不是。

这并不奇怪。
只能说楼主没有仔细想过数据库查询的基本方法。
一个简单的两个表的inner join，如果要分页，就需要首先得到整个结果集的数量。而仅仅通过top, limit限定范围，则只需要达到限制的数量就可以了。 top 和 limit实现，要比分页简单多了。
所以数据库设计者，是将分页交给用户来作处理而已。
不实现分页不是说分页没有用。

16 楼 小贾 2006-10-24  

我觉得分页查询是有必要的,主要就是提高用户的检索效率；个人认为在得到数据库查询结果后就进行分页肯定比在view层进行分页效率高。

15 楼 YuLimin 2006-10-24  

这篇文章的评测值得认真去看一看的！
......
当用户不停的向后翻页，使得&maxrnm逐渐接近满足条件的记录数时，它的性能也渐渐降低到与传统方法相近的水平
......

http://www.cnoug.org/viewthread.php?tid=38

14 楼 捆绑 2006-10-24  

只有一个理由我觉得还可以:
1.没有哪个用户愿意一页一页的翻到最后，如果用户查询到的数据超过了他所关心的数据范围，我认为应该让他重新输入查询条件

这就是个具体的设计问题了，用户到底想要如何察看他的数据呢？他最关心数据中那些具体项目（数据查询条件）。但是我想这不是不需要分页的理由吧。

下边的理由我不能接受：

1. 如果数据量很小，显然性能不会有明显的提升，相反，性能会大大下降。因为数据库执行了不必要的查询和查询条件

分页很简单啊，没有多运行什么所谓的查询条件，只是当查询出等于pageSize的数量时暂停查询而已啊，已经查出来的数据会放在数据库缓存中，等再次查询时，也可以提高数据库缓存命中率。不能理解性能如何大大下降啊。

2. 另外，如果一次全部取出数据，的确会造成空间性能的影响，但是，现在内存很便宜...

不能理解内存在楼主眼里的概念啊，客户端的内存？在线实时查询如果数据量很大，数据库服务器会承受很大压力，如果该功能使用人数很多，会严重影响数据库性能，没有哪个应用选择这种解决方案的。

13 楼 kimfly 2006-10-24  

根据实际情况和客户需要，满足自己的实际就可以了，世上没有这么通用的东西，否则大家以后都可以改行了。

12 楼 pedestrian_I 2006-10-24  

Lucas Lee 写道

1)你将几万甚至几十万的记录缓存在session里，(应该是放在这里吧?),你不觉得session里放大量东西会严重影响性能么？这个应该算是常识吧。
2)，你什么时候更新缓存？用户想看到自己或其他用户添加、更改的内容，你用什么逻辑去更新？是否要考虑线程安全性？深入点，你会发现实际所有使用缓存的方法都会有类似的问题，所以特别是在数据库应用中，我会对数据内容缓存(非配置数据)持非常谨慎的态度。

can not agree any more……
这个问题，似乎没有讨论的必要。

11 楼 LucasLee 2006-10-24  

你的疑问很好。
但是你希望别人给与实际测试数据的同时，你自己的手还是闲着的。:)
希望楼主自己动手做做测试，你就知道了。

BTW,我不使用缓存的原因，并不仅是因为性能的考虑，而主要是:
1)你将几万甚至几十万的记录缓存在session里，(应该是放在这里吧?),你不觉得session里放大量东西会严重影响性能么？这个应该算是常识吧。
2)，你什么时候更新缓存？用户想看到自己或其他用户添加、更改的内容，你用什么逻辑去更新？是否要考虑线程安全性？深入点，你会发现实际所有使用缓存的方法都会有类似的问题，所以特别是在数据库应用中，我会对数据内容缓存(非配置数据)持非常谨慎的态度。

而对于性能来说，我的一个主要观点是：
(我的假设，对一般情况而言)如果用户发现数据非常大，在一般情况下，不会依次查看每页记录，而会更改查询条件或排序方式，使结果更容易读。如果我的假设成立，那么显然，将所有记录都load到缓存里的方法，将有大部分的内容是不会用到的。所以，以前有些数据库查询的设计是，超过一千条的记录，只显示前一千条，和总记录数，这种设计，不是没有道理的，但显然数据库分页的方式比这种更好些，而且保持了类似的性能。

10 楼 together 2006-10-24  

没有任何讨论的必要。

9 楼 codeutil 2006-10-24  

你如果见过一个用户的一个联系人分类下面挂了1万个联系电话，生成的js有2万多行的话，
就知道不是该不该分页的问题，而是是否预留了分页支持的接口的问题！

请在站在用户实际环境的角度上去考虑问题，不要把自己的思维局限于自己的几条或者几十条或者几百条测试环境的数据！

8 楼 dengyin2000 2006-10-24  

在一个项目中， 开始也是使用一次把数据全部找出， 然后在客户端用javascript分页。 这种情况是第一次慢，然后下一页， 上一页飞快。 如果有上万条数据的话， 这样的情况就不太合理了。 后来还是做成了一页一页的取， 我们写了一个javascript分页类，基本上改的东西很少。PageSize PageNo都是其中一个属性，点下一页的时候通过jsonRPC－java到服务器段取道那页数据就行，然后用jst填充

7 楼 fxsc 2006-10-24  

一个设计良好的分页查询模块可以很容易的嵌入使用不同架构的WEB程序中，我自己就在用一个从论坛上改进来的分页模块。
良好设计并不是重构的敌人，楼主应该开阔一下眼界

6 楼 daquan198163 2006-10-24  

cats_tiger 写道

性能不是根据经验和感觉得到的，而是通过测试得到的。另外，如果一次全部取出数据，的确会造成空间性能的影响，但是，现在内存很便宜...

对于用户量很大的应用，因为内存的原因，也可以考虑分页查询。但是，我个人更推荐缓存方式：同样的查询放在一个缓存中...

不同意。
你很难预计将来的用户数和数据量
如果每个用户都导致把上万条数据加载道内存里，多少内存才够用呢？

cats_tiger 写道

分页查询的负面影响
对于一个架构良好的web应用，将pageNo和PageSize在各个类之间传递实在是不爽，这两个数据明显属于表现层。
分页查询还会明显提高编程复杂度。
奇怪的现象：为什么没有一个大型数据库直接提供分页查询？Oracle的RowNo不是用于分页的，SQLServer的Top更不是。
结论
ExtremeTable、DisplayTag、JSF DataTable都提供了简单的分页方式，那就是在结果集合中分页。使用非常方便，而且使得逻辑清晰，大大提高了工作效率。绝大多数情况下，可以直接使用这种方式。

采用合理的设计，屏蔽开发人员处理分页逻辑。比如，将分页逻辑和count查询放在父类，开发人员负责组合查询条件。具体看设计模式吧。
欢迎大家讨论！！！

那还能称其为架构良好的web应用吗

参考我的《分享一个通用数据库分页方案》

5 楼 cats_tiger 2006-10-24  

如果单纯为了提高用户体验，那么使用JSF、ExtremeTable之类的tags就可以，不必从数据库中分页。如果为了提高性能而分页...,总感觉性能不会有明显提高。当然，性能还是要看测试数据。

我的意思是，开发的时候不考虑数据库层面的分页查询，而是直接利用Tags提供的在List中分页的方法。然后执行性能测试，如果经过分析，发现分页查询的确可以提高性能，则通过重构，将原来的实现改为分页查询。

4 楼 fxsc 2006-10-24  

个人认为你的建议有一些道理，但也有不太实际的想法。
用户大多数情况下不是计算机专业人员，比如将一般用户和DBA或Programmer比较，在检索大表的数据时，DBA或Programmer多半能够准确的设定where条件，如果结果数据较多可能还会限制输出的行数或先select count(*)。
而对于用户不熟悉表结构和准确设定检索条件，则多半需要经过多次查询不断修改条件最终得出合适的检索结果。因此分页查询能够在前几次不确切的查询中减少每次的结果返回时间，至于用户是不是愿意一页一页的翻到最后，显然要看具体情况。
因此分页查询不是仅是为了提高性能还为了改善用户体验，你用google时也不会每次都能准确全部输入查询条件，总要多次尝试。
至于在各层之间传递参数，完全可以用更好的设计方法封装，以降低耦合度，论坛里已经有多次讨论，你可以参考。

3 楼 ITeye管理员 2006-10-24  

贴过来也可以编辑格式的

2 楼 cats_tiger 2006-10-24  

to楼上：谢谢，本来也想贴的，但是格式没有了。

1 楼 ITeye管理员 2006-10-24  

帮你贴过来了，以后这种帖子最好附上内容。