讨论一个SQL性能调优有关问题
讨论一个SQL性能调优问题
有如下两段SQL,返回的结果相同,但貌似性能略有差异,第二种效率略好。
查看了各自的执行计划,居然是相同的。
请大家讨论下,以下两种写法,哪一种是首选呢?
另外,子查询如何能够优化SQL的效率?
------解决方案--------------------
此类语句一般效率是一样的
在一些情况下,例如驱动表需要聚合,那么在子查询里聚合以后再做连接效率可能会比连接以后再聚合高得多
------解决方案--------------------
如果执行计划一样,速度不一样.首先我怀疑的是因为,第二条语句在执行的时候,你没有alter system flush share_pool;alter system flush buffer_cache;这个时候在第一条语句执行之后,你的表块在buffer pool当然就快一点了.其他速度是一样的.
如果不是这个原因,建你先做一个dbms_stats.gather_table_stats收集一下表的统计信息.
有如下两段SQL,返回的结果相同,但貌似性能略有差异,第二种效率略好。
查看了各自的执行计划,居然是相同的。
请大家讨论下,以下两种写法,哪一种是首选呢?
另外,子查询如何能够优化SQL的效率?
--SQL 1
SELECT account_id,address1,address2
FROM ADDRESSREFERENCE ADDRRF
LEFT JOIN ADDRESS ADDR
ON ADDRRF .ADDRESSID = ADDR. ADDRESSID
WHERE ADDRRF. ADDRESSTYPEID = 10
AND ADDRRF .ENTITYID = 3 ;
SELECT account_id,address1,address2 frin
(SELECT * FROM ADDRESSREFERENCE WHERE ADDRESSTYPEID = 10 AND ENTITYID =3 ) ADDRRF
LEFT JOIN ADDRESS ADDR ON ADDRRF.ADDRESSID = ADDR. ADDRESSID ;
------解决方案--------------------
此类语句一般效率是一样的
在一些情况下,例如驱动表需要聚合,那么在子查询里聚合以后再做连接效率可能会比连接以后再聚合高得多
------解决方案--------------------
如果执行计划一样,速度不一样.首先我怀疑的是因为,第二条语句在执行的时候,你没有alter system flush share_pool;alter system flush buffer_cache;这个时候在第一条语句执行之后,你的表块在buffer pool当然就快一点了.其他速度是一样的.
如果不是这个原因,建你先做一个dbms_stats.gather_table_stats收集一下表的统计信息.