分页查询效率为什么高?

f504501983 2011-10-27 10:54:03
开发中经常用到分页查询,一般都是用服务器端分页。都知道分页的查询效率高。至于为什么高,我一直不太明白。
我的理解是:
比如一张表中有100W条数据,分页查询(pageSize=10)
优势一:每次查询的数据只有10条(不是一次查询100W条),因此查询效率快了一些。
优势二:响应到客户端的数据只有10条(不是一次全部响应100W条),因此 响应的效率又高了一些。
是不是这样???????
别的地方我也不知道哪里效率高了。
假如只有这两个地方效率高了,那么看看下边的例子
selct * from A.
selct count(*) from (select * from A)
要分页就要得到总记录数,我的查询条件不确定,可能是多表连接查询,我只能想到这种获得总数的方法(哪位大侠知道更好的方法请告知????????)。
这样的话,每次分页查询之前我都需要用到count(*),这样一来每次都执行了select * from A 的操作。
这样的话 查询效率高的优势(优势一)就没有了,只是响应到客户端的效率高了(优势二)。这样理解对么?????????
这样以来分页还有意义么?????
优势一和优势二到底哪个对查询效率影响比较大????????换句话说,一次全部查询比较慢,慢在哪里,是一次查询全部数据比较影响效率,还是一次把所有数据响应到客户端比较影响效率??????????

???????????结尾的是我的问题
...全文
964 15 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
15 条回复
切换为时间正序
请发表友善的回复…
发表回复
kouyiSC 2011-10-28
  • 打赏
  • 举报
回复
举个例子把:连接查询的:
where后的参数条件:
<sql id="param_post">
<isNotEmpty prepend=" AND " property="menuPostId">
T.MENU_POST_ID = #menuPostId#
</isNotEmpty>
<isNotEmpty prepend=" AND " property="trainForm">
M.TRAIN_FORM = #trainForm#
</isNotEmpty>
<isNotEmpty prepend=" AND " property="postLevelCode">
S.POST_LEVEL_CODE = #postLevelCode#
</isNotEmpty>
</sql>

// 查询语句
<select id="query" parameterClass="java.util.HashMap"
resultClass="java.util.HashMap">
SELECT
T.POST_NAME as "postName",
T.ORG_ID as "orgId",
T.PROJECT_NO as "projectNo" ,
M.PROJECT_NAME as "projectName" ,
M.PROJECT_TYPE as "projectType" ,
M.MANAGE_MODE as "manageMode" ,
S.JOB_CODE as "jobCode",
S.JOB_TYPE_CODE as "jobTypeCode"
FROM
T_HRTR_TRAIN_YR_MENU M,
T_HRPO_POSITION S,
T_HRTR_TRAIN_MENU_POST T
WHERE
T.menu_no = M.menu_no
AND
T.post_code = S.post_code
AND M.ALIVE_FLAG = '1'
AND S.ALIVE_FLAG = '1'
AND T.ALIVE_FLAG = '1'

<include refid="HRTRTrainMenuPost.param_post" />
</select>

// 查询数量:
<select id="count" resultClass="int">
SELECT COUNT(*) FROM
T_HRTR_TRAIN_YEAR_MENU M,
T_HRPO_POSITION S,
T_HRTR_TRAIN_MENU_POST T
WHERE
t.menu_no = m.menu_no
and
t.post_code = s.post_code
AND M.ALIVE_FLAG = '1'
AND S.ALIVE_FLAG = '1'
AND T.ALIVE_FLAG = '1'
<include refid="HRTRTrainMenuPost.param_post" />
</select>

空白-键 2011-10-28
  • 打赏
  • 举报
回复
你说的优势一其实不是什么优势,就selct count(*) from (select * from A)而言,我给你个数据:表总共有11409538条数据,sql执行的时间是0.9秒,主要还是在前台页面上。
f504501983 2011-10-28
  • 打赏
  • 举报
回复
[Quote=引用 3 楼 linminqin 的回复:]
你说的优势一其实不是什么优势,就selct count(*) from (select * from A)而言,我给你个数据:表总共有11409538条数据,sql执行的时间是0.9秒,主要还是在前台页面上。
[/Quote]
您的意思是查询所用的时间其实是很小的,基本可以忽略不计,还是响应到前台的数据量影响效率 ?是这个意思么?
ld191474639 2011-10-28
  • 打赏
  • 举报
回复
selct * from A.
selct count(*) from (select * from A)
首先这2条语句的效率是不能等同的,在select * from A中万一你的数据库字段有很多,查询起来就会慢,开发中不建议使用*。
你说到的分页查询效率的问题也只说到了一部分。
假设现在你有1百万数据,现在不说效率问题,光显示到网页上就让人没法看吧,现在你说用分页查询不。
分页的主要用途是清晰,简单的给用户呈现出信息。用到分页当然效率会比一般查询效率高,企业不是因为效率高才用的分页,你要明白。
f504501983 2011-10-28
  • 打赏
  • 举报
回复
[Quote=引用 2 楼 ld191474639 的回复:]
selct * from A.
selct count(*) from (select * from A)
首先这2条语句的效率是不能等同的,在select * from A中万一你的数据库字段有很多,查询起来就会慢,开发中不建议使用*。
你说到的分页查询效率的问题也只说到了一部分。
假设现在你有1百万数据,现在不说效率问题,光显示到网页上就让人没法看吧,现在你说用分页查询不。
分页的主……
[/Quote]
selct * from A.
selct count(*) from (select * from A)
我知道他们的效率不同,我的意思是当多表连接查询的时候,我要获得总记录数,我只能想到从结果集中count(*),selct * from A.就是我的结果集,只是举个例子。
分页不是为了小率高的话,完全可以用客户端分页啊,那样照样可以使结果很清晰的啊
nizhicheng 2011-10-28
  • 打赏
  • 举报
回复
你为啥在数据库中的查询分析器中使用 selec * from table 也许 TABLE 数据量很大 然而会发现返回也很快~ 比如用PLSQL 查询数据的时候~
其实你看到的数据根本不是全部数据 ,还原出来的语句其实在后面加了 limit 。
页面实现分页的原理跟查询分析器 的原理是一样的
postgrest 2011-10-28
  • 打赏
  • 举报
回复
hibernate自带分页也不错
ws-小铁匠 2011-10-28
  • 打赏
  • 举报
回复
我的看法是,数据库有它自己的分页机制。。。

不一定的你所说的那样。。。
xc19891112 2011-10-28
  • 打赏
  • 举报
回复
select * from (select A.*,ROWNUM RN from (select * from t_product_lj) A where ROWNUM <=5) where RN>0;
龙四 2011-10-28
  • 打赏
  • 举报
回复
另外,某些数据库,select的数据集超过了全部数据的某个百分比就会全表扫描

而低于这个值就会使用索引,效率自然高
romanitc 2011-10-28
  • 打赏
  • 举报
回复
还是不太懂分页效率!
Inhibitory 2011-10-28
  • 打赏
  • 举报
回复
[Quote=引用 13 楼 chris_zcl 的回复:]

引用 3 楼 linminqin 的回复:

你说的优势一其实不是什么优势,就selct count(*) from (select * from A)而言,我给你个数据:表总共有11409538条数据,sql执行的时间是0.9秒,主要还是在前台页面上。

我理解的效率里面还有一点正如3楼所说,页面显示其实是最耗时的地方,我做过测试,如果页面只显示10条记录的速度要远远快于30条记录,再……
[/Quote]
页面显示非常耗时是真的。
在做页面显示时,很多时候是需要很巧妙的小技巧,例如动态加载,分页显示,每页数据量等都可能会考虑。
但是查询在很多时候,比页面显示更耗时,数据库如果设计得不合理,数据量很大,查询语句的优化,存储过程等都是很关键的,如果弄不好,几分钟,几十分钟查询不出结果都是很正常的。

所以不管哪个方面,都需要一定的技巧与功力。
zs_jl_bh 2011-10-28
  • 打赏
  • 举报
回复
对啊,如果页面中定义的变量多了,都会影响效率的
chris_zcl 2011-10-28
  • 打赏
  • 举报
回复
[Quote=引用 3 楼 linminqin 的回复:]

你说的优势一其实不是什么优势,就selct count(*) from (select * from A)而言,我给你个数据:表总共有11409538条数据,sql执行的时间是0.9秒,主要还是在前台页面上。
[/Quote]
我理解的效率里面还有一点正如3楼所说,页面显示其实是最耗时的地方,我做过测试,如果页面只显示10条记录的速度要远远快于30条记录,再加上如果网速不怎么样的话,差的就更多了
wangshiyang 2011-10-27
  • 打赏
  • 举报
回复
呵呵! 当然是一次把所有数据都传给客户端的效率慢了! 一下网速,二是服务器对一个就发送这么多数据,况且还不是一个用户! 不慢才怪! 是1KB的数据快还是1M的数据快呢?

67,549

社区成员

发帖
与我相关
我的任务
社区描述
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
社区管理员
  • Java EE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧