id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	due_date
120	JPA对象查询及原生SQL查询效率对比	huangjianhua	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对象查询的."	defect	new	major		商家后台			原生SQL JPA对象查询 对比		25/10/2012