※ 引述《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