分类：
2008-10-28 17:46:27
今天yxg提了一张bug单中提到oracle的环境下告警查询非常慢，连上去看了一下发现是非常慢（十多秒钟），开始怀疑是setMaxRow没有生效，导致进行了全表查询，但是在页面确认返回的结果确实是set过的500条，但是如果在语句里直接加入rownum<500不用QueryHelper.setMaxRow方法来限制查询条数的时候查询速度确是正常的（毫秒级），是不是jdbc的setMaxRow这个方法在性能上有些不足？
re:
setMaxRow的作用是限制最终的返回记录数，这个限制返回和sql执行的速度是基本没有什么关系。
你需要了解一下sql的运行机制，你可以set showplan on来看看sql的执行计划。
上面红色的最终意思是：数据库已经处理好返回的结果，然后从这些结构中获取指定的返回记录数。
特别是一些带有order by的操作，如果没有用到索引，则需要将查询结果放到临时表中进行排序，然后再从排序结果中返回指定的记录数。这个创建临时表和排序的过程也非常消耗数据库的cpu的。
setMaxRow作用主要是避免应用这段需要处理过多的记录而导致出现IO的性能问题。
我们的web开发主要都是围绕数据库的开发，sql的性能直接影响系统的稳定性。sql的编写通常都需要一些经验和技巧的，关于这块开发中心可以考虑进行一次培训。
re:
我觉得这个接口只能限制你返回的数据，而不能限制你查出来多少数据，限制查出来多少条还是要程序自己控制。
想在这个接口里面控制查出来的结果集有难度。
以oracle为例，我就有个深刻教训。
从97接口表中查询1000条待处理数据，按照SO_NBR,ACT_TYPE排序，原来是这样写的
select * from interface_97 where STS='D' and rownum<=1000 order by SO_NBR,ACT_TYPE
这个语句是在oracle里是有问题的，虽然是排序了，也只返回了1000条，但是SO_NBR不连续了，因为oracle只是从STS='D'的数据中抽取了1000条进行排序（抽取的规则不详，虽然大多数情况下没问题）
后来改成这样就没问题了
select * from (
select * from interface_97
where STS='D' order by SO_NBR,ACT_TYPE
)
where rownum<=1000
order by rownum asc
上面举的例子只是想说明，要想在setMaxRow里面把你想做的都做了，实现起来肯定有难度，而且可能和你的预期不一致，所以最好还是在你的代码中控制数据量。
re:
嗯，这个让 QueryHelper 来加或替换 set rowcount 或 rownum 或 top，随意性太大，甚至象魏巍这个例子一样，导致结果可能不是你想要的。
在DBA中，限制查询数据的返回条数，大家都写死 select maxrow=1000, * from table
然后 DBA对应 Sybase翻译成 set rowcount 1000，Oralce翻译成 rownum < 5000，自定义的一套SQL规则。比较土 :)
QueryHelper，仅仅是在 java.sql.* 上简单的包装了一层，做了日志和时间统计过程。和其名字相称，仅仅是一个简单的helper。
大家有没有什么比较好的，又不是太重量级的咚咚，来屏蔽这种数据库层面的差异？
做出来show show，大家都觉得好的话，肯定会加到openEAP上去。
呵呵，openEAP是大家的EAP，是open的....
就如老汤说的，目前用QueryHelper这个层面，很难把数据库的SQL差异给屏蔽掉:
如很常用的日期类型，很多查询中都会用到，如果不加 todate 函数，不会执行的，而Sybase则不需要。
Sybase用条件查询有 case，用 decode ...
