本帖最后由 woaini7374 于 2016-12-5 12:39 編輯
本人剛接觸Oracle資料不久，現在遇到一個磁區查詢慢的問題，有一張TEST表，表一天建立一個磁區，磁區鍵RECORD_DATE ,之所以沒有用DATE型別是考慮到使用的方便性，表的結構如下所示（介于某種原因，表名和欄位暫用其他字符代替）：
create table TEST (
TESTCOL_ID VARCHAR2(128) not null,
TESTCOL_SEQ NUMBER(3) not null,
TESTCOL_TYPE NUMBER(5),
RECORD_DATE NUMBER(10) not null,
RECORD_TIME NUMBER(10) not null,
TESTCOL2_ID NUMBER(5),
TESTCOL2_NAME VARCHAR2(64),
TESTCOL3_ID NUMBER(10),
TESTCOL3_NAME VARCHAR2(64),
TESTCOL4_ID NUMBER(5),
TESTCOL4_NAME VARCHAR2(64),
TESTCOL5_MARK NUMBER(3),
TESTCOL5_DATE NUMBER(10),
TESTCOL5_TIME NUMBER(10),
TESTCOL6_TYPE NUMBER(3),
TESTCOL6_ID NUMBER(10),
TESTCOL6_NAME VARCHAR2(64),
TESTCOL_DESC VARCHAR2(4000),
RESET NUMBER(3),
TESTCOL7_LEVEL NUMBER(3)
)
tablespace TS_TEST
partition by range (RECORD_DATE)
interval(1)
(partition
P0
values less than (20161001));
create index IDX_TEST_TIME on TEST (
RECORD_DATE ASC,
RECORD_DATE ASC
)
local
tablespace TS_IDX_TEST;
create index IDX_TEST on TEST (
RECORD_DATE ASC,
TESTCOL2_ID ASC,
TESTCOL_TYPE ASC,
TESTCOL7_LEVEL ASC
)
local
tablespace TS_IDX_TEST;
create index IDX_TEST2 on TEST (
TESTCOL_ID ASC
)
local
tablespace TS_IDX_TEST;
目前表里有10萬多的資料。如果我用select * from TEST where ( RECORD_DATE=20161203 and RECORD_TIME>=131140847 and RECORD_TIME<=161140847 ) AND TESTCOL2_ID in ( 95,96,97,98 ) AND TESTCOL_TYPE in ( 52 , 51 , 12 , 31 , 32 , 33 , 34 , 35 , 36 , 53 , 44 , 43 , 16 , 14 , 15 , 17 , 99 , 11 , 19 , 62 , 63 , 61 , 42 , 41 , 18 , 103 , 125 , 121 , 120 , 102 , 128 , 122 , 127 , 100 , 101 , 104 , 140 , 110 , 126 , 123 , 129 , 124 ) AND TESTCOL7_LEVEL in ( 4 , 6 , 5 , 1 , 7 , 8 , 3 , 2 , 33 , 31 , 32 , 0 ) ，查詢用時大概需要3秒多，檢索出來的資料3萬8千多條，感覺這已經很慢了，這還是不垮磁區查，如果跨磁區查詢。更加慢，比如執行：select * from TEST where ( (RECORD_DATE=20161103 and RECORD_TIME>=142212378) or (RECORD_DATE>20161103 and RECORD_DATE<=20161202) or (RECORD_DATE=20161203 and RECORD_TIME<=142212378) ) AND TESTCOL2_ID in ( 95,96,97,98 ) AND TESTCOL_TYPE in ( 52 , 51 , 12 , 31 , 32 , 33 , 34 , 35 , 36 , 53 , 44 , 43 , 16 , 14 , 15 , 17 , 99 , 11 , 19 , 62 , 63 , 61 , 42 , 41 , 18 , 103 , 125 , 121 , 120 , 102 , 128 , 122 , 127 , 100 , 101 , 104 , 140 , 110 , 126 , 123 , 129 , 124 ) AND TESTCOL7_LEVEL in ( 4 , 6 , 5 , 1 , 7 , 8 , 3 , 2 , 33 , 31 , 32 , 0 )。所以還請各位大神幫我分析分析，究竟導致查詢緩慢的原因是什么，哪里需要優化的（暫不考慮select * 的優化），感激不盡！！！
uj5u.com熱心網友回復：
看看執行計劃uj5u.com熱心網友回復：
執行第一個sql的計劃：PARTITION RANGE SINGLETABLE ACCESS BY LOCAL INDEX ROWID
INDEX RANGE SCAN
uj5u.com熱心網友回復：
3.8W 條資料都查出來，不算慢了； 畢竟網路上也要時間，顯示出來也要時間；uj5u.com熱心網友回復：
那還有需要優化的地方嗎？uj5u.com熱心網友回復：
建立索引試試uj5u.com熱心網友回復：
把in用其他辦法代替吧轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/109238.html
標籤：基礎和管理