锁定老帖子 主题:关于分页查询的疑惑
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2006-10-24
没有任何讨论的必要。
|
|
返回顶楼 | |
发表时间:2006-10-24
你的疑问很好。
但是你希望别人给与实际测试数据的同时,你自己的手还是闲着的。:) 希望楼主自己动手做做测试,你就知道了。 BTW,我不使用缓存的原因,并不仅是因为性能的考虑,而主要是: 1)你将几万甚至几十万的记录缓存在session里,(应该是放在这里吧?),你不觉得session里放大量东西会严重影响性能么?这个应该算是常识吧。 2),你什么时候更新缓存?用户想看到自己或其他用户添加、更改的内容,你用什么逻辑去更新?是否要考虑线程安全性?深入点,你会发现实际所有使用缓存的方法都会有类似的问题,所以特别是在数据库应用中,我会对数据内容缓存(非配置数据)持非常谨慎的态度。 而对于性能来说,我的一个主要观点是: (我的假设,对一般情况而言)如果用户发现数据非常大,在一般情况下,不会依次查看每页记录,而会更改查询条件或排序方式,使结果更容易读。如果我的假设成立,那么显然,将所有记录都load到缓存里的方法,将有大部分的内容是不会用到的。所以,以前有些数据库查询的设计是,超过一千条的记录,只显示前一千条,和总记录数,这种设计,不是没有道理的,但显然数据库分页的方式比这种更好些,而且保持了类似的性能。 |
|
返回顶楼 | |
发表时间:2006-10-24
Lucas Lee 写道 1)你将几万甚至几十万的记录缓存在session里,(应该是放在这里吧?),你不觉得session里放大量东西会严重影响性能么?这个应该算是常识吧。 2),你什么时候更新缓存?用户想看到自己或其他用户添加、更改的内容,你用什么逻辑去更新?是否要考虑线程安全性?深入点,你会发现实际所有使用缓存的方法都会有类似的问题,所以特别是在数据库应用中,我会对数据内容缓存(非配置数据)持非常谨慎的态度。 can not agree any more…… 这个问题,似乎没有讨论的必要。 |
|
返回顶楼 | |
发表时间:2006-10-24
根据实际情况和客户需要,满足自己的实际就可以了,世上没有这么通用的东西,否则大家以后都可以改行了。
|
|
返回顶楼 | |
发表时间:2006-10-24
只有一个理由我觉得还可以:
1.没有哪个用户愿意一页一页的翻到最后,如果用户查询到的数据超过了他所关心的数据范围,我认为应该让他重新输入查询条件 这就是个具体的设计问题了,用户到底想要如何察看他的数据呢?他最关心数据中那些具体项目(数据查询条件)。但是我想这不是不需要分页的理由吧。 下边的理由我不能接受: 1. 如果数据量很小,显然性能不会有明显的提升,相反,性能会大大下降。因为数据库执行了不必要的查询和查询条件 分页很简单啊,没有多运行什么所谓的查询条件,只是当查询出等于pageSize的数量时暂停查询而已啊,已经查出来的数据会放在数据库缓存中,等再次查询时,也可以提高数据库缓存命中率。不能理解性能如何大大下降啊。 2. 另外,如果一次全部取出数据,的确会造成空间性能的影响,但是,现在内存很便宜... 不能理解内存在楼主眼里的概念啊,客户端的内存?在线实时查询如果数据量很大,数据库服务器会承受很大压力,如果该功能使用人数很多,会严重影响数据库性能,没有哪个应用选择这种解决方案的。 |
|
返回顶楼 | |
发表时间:2006-10-24
这篇文章的评测值得认真去看一看的!
...... 当用户不停的向后翻页,使得&maxrnm逐渐接近满足条件的记录数时,它的性能也渐渐降低到与传统方法相近的水平 ...... http://www.cnoug.org/viewthread.php?tid=38 |
|
返回顶楼 | |
发表时间:2006-10-24
我觉得分页查询是有必要的,主要就是提高用户的检索效率;个人认为在得到数据库查询结果后就进行分页肯定比在view层进行分页效率高。
|
|
返回顶楼 | |
发表时间:2006-10-24
我的意见:
1。 请把数据库限定范围查询和页面数据分页分开。 2。数据库限定范围查询应该是利用Sql中的限定方式,比如msyql 的 limit, sqlserver的top,获取一定范围的结果集。在数据量很大时,数据库限定范围查询确实可以提高数据库访问性能。 3。页面数据分页。用户有时候不一定需要一次看到所有数据,比如搜索引擎的结果。或者数据太长,一次性全部展示,对服务器负担太重。这时候就需要页面数据分页。 如果不做分页,而一次性全部展示,在数据量大时,浏览页面也常常会出现显示不完整和超时的问题。 4。完整的分页处理,应该同时包含 数据库限定范围查询和页面数据的分页。 相对麻烦一些。有时候,有的程序员往往只作页面数据分页,从而导致数据库的压力并没有减轻多少。 此外,楼主说的 引用 奇怪的现象:为什么没有一个大型数据库直接提供分页查询?Oracle的RowNo不是用于分页的,SQLServer的Top更不是。
这并不奇怪。 只能说楼主没有仔细想过数据库查询的基本方法。 一个简单的两个表的inner join,如果要分页,就需要首先得到整个结果集的数量。而仅仅通过top, limit限定范围,则只需要达到限制的数量就可以了。 top 和 limit实现,要比分页简单多了。 所以数据库设计者,是将分页交给用户来作处理而已。 不实现分页不是说分页没有用。 |
|
返回顶楼 | |
发表时间:2006-10-25
引用 写道 分页很简单啊,没有多运行什么所谓的查询条件,只是当查询出等于pageSize的数量时暂停查询而已啊,已经查出来的数据会放在数据库缓存中,等再次查询时,也可以提高数据库缓存命中率。不能理解性能如何大大下降啊。 我所说的“额外的查询”是指那个count查询,如果不加查询条件,count是很快的,如果加查询条件并且不走索引,count查询就很慢了。多数分页查询,都要执行一个count查询吧,它不会影响性能吗? |
|
返回顶楼 | |
发表时间:2006-10-25
引用 这并不奇怪。
只能说楼主没有仔细想过数据库查询的基本方法。 一个简单的两个表的inner join,如果要分页,就需要首先得到整个结果集的数量。而仅仅通过top, limit限定范围,则只需要达到限制的数量就可以了。 top 和 limit实现,要比分页简单多了。 所以数据库设计者,是将分页交给用户来作处理而已。 不实现分页不是说分页没有用。 还是很奇怪呀,分页的确比limit复杂,正因为如此,数据库设计者才不应该把这个工作交给用户。SQLServer压根就没有为分页查询提供可能的技术,Oracle好歹还有一个ROW_NUM,SQLServer的top...唉!这种情况显然与MS的一贯做法不同,MS向来重视客户体验。 实际上,对于数据库设计者来说,提供一个分页功能实在是太简单了。 |
|
返回顶楼 | |