* 부정형 비교를 사용할때
** {code:sql}
select *
from 고객
where 직업 <> '학생'
* 세가지의 경우 Range Scan 이 불가능 하지만 Full Scan 은 가능하다.
* 예외적인 경우로 not null 의 경우 not null 제약이 있을경우 옵티마이져는 Table Full Scan 을 피하기 위해 인덱스 스캔을 통해 0 집합을 리턴한다.
* is null 조건을 사용하더라도 다른 인덱스 구성 컬럼에 is null 이외의 조건식이 하나라도 있으면 Range Scan 이 가능하다.
h3. 인덱스 컬럼의 가공
* 인턱스 컬럼을 가공하면 정상적인 Range Scan 이 불가능해 진다.
** substr
!19_09_11_1.jpg!
** 연산 + - * /
!19_09_17_1.jpg!
** to_char (날자를 문자로 형변환)
!19_09_23_1.jpg!
** 연산자 \|\| 를 사용한 형변환
!19_09_27_1.jpg!
** 의미없는 함수의 사용
!19_20_40_1.jpg! !19_20_57_1.jpg!
* 튜닝사례 1
!19_35_09_1.jpg!
!19_35_13_1.jpg!\*\* PK 인덱스 선두 컬럼을 가공하여 인덱스를 사용할수 없게됨.
거래일자 만으로 구성된 인덱스를 사용했거나 Full Table Scan
PK 인덱스 선두 컬럼을 가공하지 않는 쿼리로 변환.
* 튜닝사례 2
h3. 묵시적 형변환
* varchar2 컬럼에 숫자 값을 더하거나 빼는 연산을 가해 내부적으로 숫자형으로 형변환이 일어난 경우.
!19_39_51_1.jpg!
!19_40_29_1.jpg!
NL outer 조인은 x 쪽 파트너 지원 요청 을 읽고 y 쪽을 읽는다.
varchar2 컬럼에 숫자 값을 더하거나 빼는 연산을 가하면 내부적으로 숫자형으로 형변환이 일어 난다.
숫자형과 문자형이 비교될 때는 숫자형이 우선시 되기 때문에 y 쪽 대상연월이 숫자형으로 형변환 된다.
결과적으로 인덱스 컬럼을 가공한 셈이 된다.
!19_40_33_1.jpg!
* 숫자형 컬럼(n_col) 과 문자형 컬럼(v_col) 을 비교하여 문자형 컬럼이 숫자형 컬럼으로 변환
!19_41_42_1.jpg!
명시적으로 변환함수를 사용
!19_41_52_1.jpg!
h3. FBI (Funtion Base Index)
* 가공된 컬럼에 대한 인덱스 엑세스 가능
** 함수 등에 의해 where 조건절의 인덱스 컬럼 변경시에도 인덱스 사용 가능
\*DML 부하증가
* SQL 변경 없이 정상적으로 인덱스 사용
** 실제 인덱스에 데이터 저장시 함수를 적용하여 저장해야 함으로 함수 수행에 의한 부하 증가.
* 인덱스의 유연성 감소
** 인덱스로 만들어진 함수가 where 조건에 반드시 존재 해야만 인덱스 사용이 가능함으로 다른 조건들에 대한 인덱스 사용 불가
* 묵시적 형변화에 의해 성능이슈가 있을 경우 임시방편으로 함수기반 인덱스(FBI)를 사용할 수 있다.
(꼭 추후 일정을 잡아 개선해야 한다)
{code:sql}
=>묵시적 형 변환 : to_number(v_deptno) = 20
create index emp_x01 on emp(to_number(v_deptno));
v_deptno = 20