Hql的祸

程序写的好不好,就看代码写的怎样,仔细看下面2条hql语句,有什么不同:

1.    from SinoASNDetail a where a.asn.warehouse = :warehouse and a.asn.receivedTime >= :beginTime and a.asn.receivedTime <= :endTime and a.item.id in (select b.id from SinotransItem b where b.customHouse=:itemcode)

2.    select distinct a from SinoASNDetail a ,SinotransItem item where a.item.id = item.id and a.asn.warehouse = :warehouse and item.customHouse=:itemcode and a.asn.receivedTime >= :beginTime and a.asn.receivedTime <= :endTime order by a.asn.receivedTime asc

查询出来的结果都一样,可是效率确完全不一样.小数据量或许没有什么区别,如果你让它循环几十次做这样的查询,区别就出来了.

偶今天的实践证明,用第一条hql查询的报表(因某种原因循环20余次),一分钟不到得到结果;用第二条hql查询,2分钟多点.

再来看看是谁惹的货,看见上面橙色字体没,distinct 和 order by ,就是这2个家伙了.切记切记啊.还有,不要随随便便的用笛卡尔集合进行查询,苦头有的吃.

如果不用order by,你怎么进行排序呢?

这里只是想说一下效率的问题,因为测试的时候发现在hql中使用order by确实大大降低了查询的效率,当然如果你一定要在查询的时候顺便排序的话,order by也不是不可以.不过似乎查询出list以后在程序中使用Collections.sort()的效率要更快些,具体使用的时候根据个人需求取舍了

噢？有这样的事情？

我没有具体测试和深入研究过，所以只能靠想象说话了。我认为hql的order by其实也是翻译成sql的order by，由数据库来执行的。效率低的话，应该是数据库效率低。另外，我认为数据库排序应该会比我们的应用程序排序更快……

数据库使用的是mysql,我在程序中排序确实比在hql中排序要快的.不晓得是不是因为mysql的缘故呢?

select distinct a from SinoASNDetail a ,SinotransItem item

你这里就有table a x item 大的matrix在内存里，还加个distinct，table的full scan很浪费的。

第一个查询只是两个table分开的scan，当然效率高点。

order by是数据库搞定的，和HQL无关。

如果数据量大的话，每次查询都要获得全部结果集，在程序里排序，这样只能降低效率吧？

hql应该只是sql的抽象。这个例子说明不了什么问题，sql的效率和记录数量有很大关系，且数据库都在执行时探寻最优、次优的等价查询语句。再者，搂主举的例子，两条语句并不等价，order by 本身是high cost 的，而第一句却没有。还有，集合操作的问题，一般来说，如果是一次操作，可以直接在sql中做order by，还有很多情况下，是把一个很大的recordset先拿出来，在程序里面对部分数据做处理，这种情况还是在程序里面做比较快，。

楼主，如果取数据库中记录来进行排序呢，不会对我说几百万条记录一下子取出来放在集合啊，然后再时行排序吧

关键看你order by的字段是不是做了索引。
如果没做，然后整体数据集比较大的话，数据库会比较慢。
另外，你这里是关联属性的order，实际上会查很多次关联表，
性能就比不上查出来，再排序了。