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