Re: [SQL ] 關於Oracle索引問題
※ 引述《slalala (ptt不是丁丁知識+)》之銘言：
: ※ 引述《ling123 (@@)》之銘言：
: : 有一TABLE: MM_STKREC 有2個索引，分別是STKNO+RECYM(儲區+異動年月)
: 這個是組合鍵的關係，條件上 單單只有STKNO 是沒有索引的效果...
: 我之前碰過類似的狀況
: 所以又重建了一個類似你範例中的STKNO的索引...
: 結果速度就正常了
: 有錯請糾正XD沒有深入研究過SQL...
這跟組合鍵無關
首先要說一個觀念 INDEX不是萬能的
一般我們我CREATE的INDEX是 B-TREE INDEX
原則上在RETRIVE資料量佔TABLE 比例很小時 速度很快
若我們在某個TABLE 如 性別的欄位 ( 'M' ,'F' )
建立 B-TREE INDEX 只不過是浪費STORAGE 的動作
因為 反而造成更大的 I/O 量
就 ORACLE 來說
因為 OPTIMIZER 的關係 ORACLE 通常會使用 COST BASE OPTIMIZER (CBO)
而不使用 RULE BASE OPTIMIZER (RBO)
COST 怎麼算出來的? 大致上依據 I/O 及 CPU LOADING 所算出來
當我們使用INDEX的 QUERY COST 大於不使用INDEX
那麼 OPTIMIZER 會選擇 FTS (FULL TABLE SCAN)
所以 SCAN 很久 !!
至於你的 STKREC值 究竟佔全部的多少比例 ( CARDINALITY )
適不適合用 B-TREE INDEX
高的 CARDINALITY才適合 如 ID 這種欄位
那麼 低的 CARDINALITY (如:性別) 就無解了嗎?
不 還有一種 BITMAP INDEX
但 BITMAP 在 DML 頻繁的table 確是不適合的
所以建什麼索引 必須看 系統 BUSINESS RULE決定
基本上你的 QUERY1 與 QUERY2 拿來比較 有點怪怪的
要比較需要對同 TABLE 的同欄位的同索引才有意義
趕著出門
有錯歡迎指教
: : 及RECDT(進出日期)
: : 使用語法1時，只會開STKNO+RECYM這個索引，但RECDT卻不會開，
: : 結果速度很慢(因為此檔會儲區進出交易記錄檔，是超級大檔)
: : 使用語法2時，直接開RECDT這個索引，結果速度超快
: : 為什麼為什麼ㄋ ??? 照道理不是應該兩個索引都會開嗎 ?? 有人知道為什麼嗎
: : 語法1:
: : select a.STKNO,RECYM,a.RFMNO,a.ITEMNO,a.NSN,a.GQTY,a.TRNCTP,a.ITMLOT,a.RECDT
: : from MM_STKREC a
: : where a.RECDT>='10/04/2007' and a.RECDT<'10/05/2007'
: : and a.STKNO='AKMS1'
: 語法1搜尋條件沒有同時運用到STKNO+RECYM 所以INDEX沒有效果...
: 如果加上一個RECYM的條件 效果應該會出來...
: : 語法2:
: : select a.STKNO,RECYM,a.RFMNO,a.ITEMNO,a.NSN,a.GQTY,a.TRNCTP,a.ITMLOT,a.RECDT
: : from MM_STKREC a
: : where a.RECDT>='10/04/2007' and a.RECDT<'10/05/2007'
: : and a.STKNO>='AKMS1' AND a.STKNO<='AKMS1'
: 語法2因為條件中使用到RECDT的索引... 所以會很快....
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.229.81.127
討論串 (同標題文章)