JPA对象查询及原生SQL查询效率对比

[huangjianhua]

JPA对象查询:

select c.id from CompanyProduct c where ....

写查询语句非常简单,简单明了~
在遍历商品的时候也是比较清楚的,代码也非常清晰,一看就知道什么意思了 如:

for(CompanyProduct c : list){
     long product_id = c.getProduct().getId();
     ......
}

但是从上面的long product_id = c.getProduct().getId(); 这一行代码中,JPA隐藏又去做了并表查询,每执行一次就关联表查询一次,在做接口测试中,list的数据只有700多条,结果,执行的效率非常慢,大约用了3分多钟甚至更久;

简单总结一下: 采用JPA关联表查询,代码是清晰了,但是效率极大下降了;

原生SQL查询:

select c.id, c.title,c.product_id,p.short_name 
from ent_product c, v_pdl_product p where c.product_id = p.id .......

写SQL语句变得复杂,记得DBA说过,我们写Sql语句的时候,尽量写到我们要什么数据就出什么数据,不要把整个对象查出来,或者是 "c.*"这么去写,因为这影响效率;

在执行遍历的时候:

for(int i=0; i< list.size(); i++){
    Object[] objArray = (Object[])list.get(i);
    long productId    = objArray[2];
    long id           = objArray[0];
    .......

}

在页面输出内容的时候,代码的清晰度就变得没有用JPA对象查询的那么人性化了,如果要知道ojbArray[2]中是什么内容,还得到回去查看SQL语句中是怎么写的,尽管这个比较麻烦,但是在这里执行效率上面,采用原生SQL查询数据的效率远远快于采用JPA对象查询的速度.

简单总结一下: 原生SQL的方法,代码的可读性比较差,但运行的效率是非常快的.

总结:以后在写接口的时候,有关联表查询的,如:在for循环中又有: "long product_id = c.getProduct().getId();"又对效率的要求比较高的话,尽量采用原生SQL的写法,这样子可以减少for循环减1次的数据库连接.如果对效率要求不高,或者数据不多的情况下还是可以采用Jpa对象查询的.

---

这个现象和v6.1上线时的情况是同一类，这个机制的优劣也是要看情况的，本身jpa就有lazy load的属性，用的时候再去查不是一个错误，看用在什么场合，打个比方说，v6.1上线时那三个图片属性，如果是设成lazyload，那情况会怎么样呢，大家不妨手动试一下。