什么是謂詞越界？謂詞越界其實就是SQL語句的查詢條件超出了數據庫統計信息所記錄的范圍。謂詞越界會導致Oracle優化器錯誤的選擇SQL語句的執行計劃，導致性能問題。

這里舉一個簡單的例子說明謂詞越界導致優化器選擇了錯誤的執行計劃。

create table t1 (col1 number); create index idx_t1 on t1(col1);beginfor i in 1..10000 loopinsert into t1 values (i);end loop;commit; end; /

這里創建了t1表，并在col1列上創建了索引，并向表里寫入了10000條數據。提供過對t1表收集統計信息，可以得到目前表t1的謂詞情況。

SQL> exec dbms_stats.gather_table_stats('SALP','T1'); SQL> select low_value,high_value from dba_tab_col_statistics where table_name='T1' and owner='SALP';LOW_VALUE HIGH_VALUE ---------- ---------- C102 C302SQL> var x number; SQL> exec dbms_stats.convert_raw_value('C102',:x);PL/SQL procedure successfully completed.SQL> select :x from dual;:X ----------1SQL> exec dbms_stats.convert_raw_value('C302',:x);PL/SQL procedure successfully completed.SQL> select :x from dual;:X ----------10000

上面用到了一個系統包，把統計信息表里的上下限裸數據轉換成可讀的數值。

在謂詞范圍內的條件查詢的執行計劃為

explain plan for select * from t1 where col1 between 1 and 10000; select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Plan hash value: 1387720244 ------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 10000 | 40000 | 7 (0)| 00:00:01 | |* 1 | INDEX FAST FULL SCAN| IDX_T1 | 10000 | 40000 | 7 (0)| 00:00:01 | ------------------------------------------------------------------------------- Predicate Information (identified by operation id): ---------------------------------------------------1 - filter("COL1">=1 AND "COL1"<=10000) 13 rows selected.

因為這里的條件包含了t1表內的所有數據，所以采用多塊讀且不需要回表的執行計劃是最優的（table access full/index fast full scan），這里實際使用的是index fast full scan。

接下來繼續向t1表寫入數據

beginfor i in 10001..10000000 loopinsert into t1 values (i);end loop;commit; end; /

在不重新收集統計信息的情況下，檢查表的統計信息

select low_value,high_value from dba_tab_col_statistics where table_name='T1' and owner='SALP';LOW_VALUE HIGH_VALUE ---------- ---------- C102 C302

現在來進行一次謂詞越界的查詢，使用謂詞條件 col1 between 10001 and 10000000。按道理來說，這種選擇表里99.9%數據的語句應該使用多塊讀且不回表的執行計劃（table access full/index fast full scan）。我們來實際試驗一下。

SQL> set timing on; SQL> Select count(*) from t1 where col1 between 10001 and 10000000;COUNT(*) ----------9990000Elapsed: 00:00:11.17 SQL> select * from table(dbms_xplan.display_cursor(null,null,'advanced'));PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- SQL_ID 86kr1tnhns36d, child number 0 ------------------------------------- Select count(*) from t1 where col1 between 10001 and 10000000Plan hash value: 1970818898---------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 2 (100)| | | 1 | SORT AGGREGATE | | 1 | 4 | | | |* 2 | INDEX RANGE SCAN| IDX_T1 | 1 | 4 | 2 (0)| 00:00:01 | ----------------------------------------------------------------------------

可以看到這條語句執行了11s才出結果，且執行計劃選擇的是單塊讀的index range scan，而不是我們期望的多塊讀不回表的兩種執行計劃之一且返回的Rows和Bytes出現了嚴重預估錯誤。

我們重新為t1表收集一次統計信息，再次執行同樣的語句并檢查執行計劃。

SQL> exec dbms_stats.gather_table_stats('SALP','T1');PL/SQL procedure successfully completed. Elapsed: 00:00:07.92 SQL> select count(*) from t1 where col1 between 10001 and 10000000;COUNT(*) ----------9990000Elapsed: 00:00:00.31 SQL> select * from table(dbms_xplan.display_cursor(null,null,'advanced'));PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- SQL_ID g47843nv7gsdq, child number 0 ------------------------------------- select count(*) from t1 where col1 between 10001 and 10000000Plan hash value: 3724264953--------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 4434 (100)| | | 1 | SORT AGGREGATE | | 1 | 6 | | | |* 2 | TABLE ACCESS FULL| T1 | 9990K| 57M| 4434 (2)| 00:00:01 | ---------------------------------------------------------------------------

這次走出了我們希望的執行計劃(table access full)，預估的Rows和Bytes也都正常了，且語句花了310ms就運行完了。

?

謂詞越界一般會發生在什么場景下？

1 臨時表

這里指的是業務上的臨時表而不是Oracle數據庫本身的temporary table。在某些系統中會根據業務條件創建前臺表和后臺表，數據先進入前臺表，處理完畢后，存入后臺表，并用delete語句清理前臺表的數據，前臺表起到一個臨時表的作用。我們知道，Oracle自動收集統計信息的默認時間窗口是工作日晚上的22點到凌晨2點，或者周末的早上6點到第二天凌晨2點。在自動收集統計信息窗口內，數據庫前臺表基本上處于無數據，或者數據量很小的情況，那么產生的統計信息就會和白天實際處理業務數據時有偏差，就有可能發生謂詞越界的情況。

2 巨大表

Oracle觸發自動收集某個表的統計信息的條件是表中修改的數據量超過該表數據總量的10%，假設一個表每天新增1w條數據，一年后這個表變成了365w條數據，那么這意味著這個表需要再過一個多月才會觸發一次自動收集統計信息的作業。那么在這個表上的謂詞查詢，尤其是時間、序列等自增條件上的查詢，就可能發生謂詞越界的情況，影響優化器正確選擇執行計劃。

轉載于:https://www.cnblogs.com/aegis1019/p/9059220.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的Oracle统计信息不准(谓词越界)造成的性能问题的全部內容，希望文章能夠幫你解決所遇到的問題。

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