Oracle-記一次SQL優化(sum)

原始SQL

SELECT
substr( kemu_id, 1, 4 ),
'8888',
0,
0,
'',
'',
(
	sum( ( CASE WHEN sign( pz_jiefang_jine ) = 0 THEN 0 ELSE 1 END ) * npz_number ) - sum( ( CASE WHEN sign( pz_daifang_jine ) = 0 THEN 0 ELSE 1 END ) * npz_number ) 
),
sum( pz_jiefang_waibi - pz_daifang_waibi ),
sum( pz_jiefang_jine - pz_daifang_jine ),
0,
0,
0,
0,
0,
0,
0,
0,
0 
FROM
	cw_pz2 
WHERE 
	instr( '14', zt_no ) > 0 
	AND REGEXP_LIKE ( kemu_id, '^(1001|1002|1012)' ) 
	AND ( to_char ( pz_date, 'yyyy-mm-dd' ) < '2019-05-01' ) 
GROUP BY
	kemu_id

優化前

Cost值爲93207 ，也沒有走索引

創建複合索引

create index INX_CW_PZ2_KMRQ_2 on CW_PZ2 (ZT_NO, KEMU_ID, PZ_DATE, PZ_JIEFANG_JINE, PZ_DAIFANG_JINE, PZ_JIEFANG_WAIBI, PZ_DAIFANG_WAIBI, NPZ_NUMBER)
  tablespace USERS
  pctfree 10
  initrans 2
  maxtrans 255
  storage
  (
    initial 64K
    next 1M
    minextents 1
    maxextents unlimited
  );

優化後情況

現在Cost值是17864

進一步優化(待續)

第一次根據複合索引的特性進行優化

瞭解了前綴性(Prefixing)和可選性(Selectivity)

查詢各個字段的可選性，進行索引字段的排序

select count(distinct ZT_NO) ZT_NO, count(distinct KEMU_ID) KEMU_ID, 
       count(distinct PZ_DATE) PZ_DATE, count(distinct PZ_JIEFANG_JINE) PZ_JIEFANG_JINE, 
       count(distinct PZ_DAIFANG_JINE) PZ_DAIFANG_JINE, count(distinct PZ_JIEFANG_WAIBI) PZ_JIEFANG_WAIBI, 
       count(distinct PZ_DAIFANG_WAIBI) PZ_DAIFANG_WAIBI, count(distinct NPZ_NUMBER) NPZ_NUMBER
from cw_pz2 t

下面索引修改了順序

create index INX_CW_PZ2_KMRQ_2 on CW_PZ2 (PZ_DAIFANG_WAIBI, PZ_JIEFANG_WAIBI, PZ_JIEFANG_JINE, PZ_DAIFANG_JINE, NPZ_NUMBER, PZ_DATE, KEMU_ID, ZT_NO)
  tablespace USERS
  pctfree 10
  initrans 2
  maxtrans 255
  storage
  (
    initial 64K
    next 1M
    minextents 1
    maxextents unlimited
  );

發現並沒有什麼效果

第？次

發現REGEXP_LIKE 裏面的字段可能是不走索引INX_CW_PZ2_KMRQ （該索引只有where後面的字段） 因爲單純的對like “xxx%” 它是走INX_CW_PZ2_KMRQ 索引（該索引只有where後面的字段）

重新建了個索引

create index INX_CW_PZ2_KMRQ on CW_PZ2 (ZT_NO, KEMU_ID, PZ_DATE)
  tablespace USERS
  pctfree 10
  initrans 2
  maxtrans 255
  storage
  (
    initial 64K
    next 1M
    minextents 1
    maxextents unlimited
  );

結論

1.以前只對着where裏面的字段進行索引創建，發現對sum裏的字段創建也有效果
2.發現根據複合索引的前綴性以及可選性進行優化並沒有什麼效果
3.發現REGEXP_LIKE 裏面的字段可能是不走索引（該索引只有where後面的字段） 因爲單純的對like “xxx%” 它是走索引（該索引只有where後面的字段）