生產系統反應較慢，IO負載較高，查看故障時間的awr報表，發現主要都是類似下面sql引起的： Sql語句 。。。 這個sql語句的主要問題在于最后的一個filter操作，一般我們在子查詢中經常會看見hash jon 和filter兩種執行計劃，cbo在9i下就能夠根據條件去選擇合適

生產系統反應較慢，IO負載較高，查看故障時間的awr報表，發現主要都是類似下面sql引起的：

Sql語句

。。。

這個sql語句的主要問題在于最后的一個filter操作，一般我們在子查詢中經常會看見hash jon 和filter兩種執行計劃，cbo在9i下就能夠根據條件去選擇合適的執行計劃，當然走hash join也需要一些限制，而這里的cbo之所以沒有選擇hash join而選擇糟糕的filter正是因為這個子查詢的or引起的，我們在執行計劃id=4 filter的謂詞轉換中能夠清晰的看見cbo轉換為一個exists or exists形式

這個版本的數據庫是10.2.0.5，這里cbo沒有能夠對這個or做一個union all的操作然后轉換為view來做hash join，這里我們選擇改寫or為union all來幫助cbo選擇合適的hash join，改寫完后的sql語句執行計劃如下：(由于sql語句較長，這里我只摘要修改的部分和執行計劃)

這里看出改寫為union all的sql語句執行計劃已經由filter改變了hash join，而且驅動表的順序也已經改變了，都是用小結果集去做驅動表。

改成上述sql后，這個sql執行成本下降了許多，這里截取部分賦部分值給綁定變量予以顯示區別：

1)Union all改寫后當：1=10時的消耗資源

Statistics

----------------------------------------------------------

1 recursive calls

0 db block gets

17138 consistent gets

2816 physical reads

0 redo size

27539 bytes sent via SQL*Net to client

25555 bytes received via SQL*Net from client

1 SQL*Net roundtrips to/from client

2 sorts (memory)

0 sorts (disk)

0rows processed

2 ) 原sql語句 ：1=10消耗的資源：

Statistics

----------------------------------------------------------

1 recursive calls

0 db block gets

313213 consistent gets

10029 physical reads

64 redo size

27539 bytes sent via SQL*Net to client

24605 bytes received via SQL*Net from client

1 SQL*Net roundtrips to/from client

1 sorts (memory)

0 sorts (disk)

0rows processed

需要注意的是oracle 11g下，對于子查詢中包含or的已經能被cbo優化為union all操作來和另外的表的做hash join聯合，從而可能避免了某些糟糕的filter執行計劃。

總結

以上是生活随笔為你收集整理的mysql查询filter_子查询包含or引起的filter性能问题案例的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。