使用ROWNUM进行Oracle查询优化

这个题目此刻没有现实意义

我从头计较了表格中的统计数据,添加了新的指数,并从头说明白现有指数.这完全改变了我的功效,并使我的大大都发明无效.在这一点上,我发明白一个新的查询,它具有足够的机能,不必要任何ROWNUM能力.

另外,我以为值得指出的是,下面的查询,如所写,不能担保给出我想要的功效.将DISTINCT添加到中间查询也许会粉碎我实行在最内里的查询中应用的次序.在实践中,这没有产生,但我不能依靠于此.

原始题目

我写了一个查询,当我输入一个假的ROWNUM搜查时,它好像示意得更好：

SELECT * FROM
  (
    SELECT DISTINCT * FROM 
    ( 
      SELECT TransactionID FROM WOWDev.QueryLog WHERE UPPER(UserName)=UPPER('xyz') AND TransactionID IS NOT NULL ORDER BY TransactionID DESC
    ) 
    WHERE ROWNUM<=1e100 -- fake ROWNUM check! this gets us on the fast path
  )
  WHERE ROWNUM<=50

这是优化器打算.

SELECT STATEMENT,GOAL = ALL_ROWS           38025   50  650
 COUNT STOPKEY                  
  VIEW  JSTILES     38025   801 10413
   SORT UNIQUE NOSORT           38025   801 3204
    COUNT STOPKEY                   
     VIEW   JSTILES     38024   801 3204
      TABLE ACCESS BY INDEX ROWID   WOWDEV  QUERYLOG    38024   545694  9276798
       INDEX FULL SCAN DESCENDING   WOWDEV  IX_QUERYLOG_TID 1263    212704

假如我注释掉了假的ROWNUM搜查,那么查询溘然瓦解并变得慢得多(以及本钱为5倍).

SELECT STATEMENT,GOAL = ALL_ROWS           204497  50  650
 COUNT STOPKEY                  
  VIEW  JSTILES     204497  34865   453245
   SORT GROUP BY STOPKEY            204497  34865   592705
    INDEX FAST FULL SCAN    WOWDEV  IX_QUERYLOG_USER_TID    204462  545694  9276798

显然,这也是一个完全差异的指数(一个显然不得当它).

假如我天然地简化查询并删除全部冗余,我们会获得一个与贫民版原形同的执行打算,同样机能也差.

SELECT * FROM 
(
  SELECT DISTINCT TransactionID
          FROM WOWDev.QueryLog
         WHERE UPPER(UserName) = UPPER('xyz')
           AND TransactionID IS NOT NULL
         ORDER BY TransactionID DESC
)
WHERE ROWNUM <= 50

表明如下：

SELECT STATEMENT,GOAL = ALL_ROWS           207527  50  650
 COUNT STOPKEY                  
  VIEW  JSTILES     207527  34865   453245
   SORT UNIQUE STOPKEY          207491  34865   592705
    INDEX FAST FULL SCAN    WOWDEV  IX_QUERYLOG_USER_TID    204462  545694  9276798

如下所示,我实行用ROWNUM> 0替代我的ROWNUM< = 1e100,这也到达了快速路径,但打算略有差异：

SELECT STATEMENT,GOAL = ALL_ROWS           38025   50  650
 COUNT STOPKEY                  
  VIEW  JSTILES     38025   801 10413
   SORT UNIQUE NOSORT           38025   801 3204
    COUNT                   
     FILTER                 
      VIEW  JSTILES     38024   801 3204
       TABLE ACCESS BY INDEX ROWID  WOWDEV  QUERYLOG    38024   545694  9276798
        INDEX FULL SCAN DESCENDING  WOWDEV  IX_QUERYLOG_TID 1263    212704

谁能表明这种举动？是否有更洁净,更少hacky的方法让Oracle走上快车道？

办理要领

我用过ROWNUM>已往0逼迫数据“物化”.

这反过来应承查询处理赏罚器得到正确的基数.

譬喻,假如查询筹划器以为特定谓词只返回一行,它凡是会在其上行使笛卡尔毗连.假如数据现实上不是一行而是许多,则笛卡尔毗连会导致大量行和大量不正确的处理赏罚.添加ROWNUM> 0迫使它在评估ROWNUM>之前评估每一行的rownum. 0,有用地逼迫数据的实现

固然这看起来不是这个题目.

大概是由于数据的撒播,实现起来更快,然后搜刮表而不是起首搜查索引.

在该打算转储中是否有步伐办理谓词的应用位置？

很遗憾你必需UPPER这个规模,由于它使它不具有sargeable而且不会在该字段上行使索引.

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!