1. driving table 선정이 가장 중요함
ð optimizer 가 가장 먼저 읽는 table 을 driving 이라함
ð driving table 이 되기 위해서 driving table 의 key column 에 상수를 주어야함
ð 상수가 아닌 변수나, ||, not , substring , rtrim 등 변형을 가하면 driving 조건에서 배제됨
ð driving table 에서 가능한 범위를 줄여주어야함
(예 실적->조직구조-> 조직 => 조직구조->조직->실적 )
ð driving table 의 조건이 동일하다면 ordered hint 지정
2. join 의 횟수를 줄여야 함
ð Detail 이 driving 되었을때 master 를 detail 건수 만큼 join 할 필요는 없음
ð 예) detail 이나, master table 로 조직을 join 하는 경우=> 한번만 join
ð 예) 상위조직으로 조직별 제품별 실적을 조회하는데 매번 제품을 join 할 필요 없슴
ð Inline view 이용
3. outer join 은 꼭 필요한 경우가 아니면 쓰지 말며 가능한 inline view 로 처리
4. nvl 함수 남발은 결국 performance 저하
ð table layout 상에 Notnull 로 지정된 경우는 nvl 함수 사용금지
ð 수량,금액 fields 는 DB team 에서 default 0 로 변경할 예정임
5. index column 에 변형을 가하면 index scan 하지 못함
6. sort,group by,order by 는 부분범위처리를 하지 못하며 performance 를 저하시키니, 꼭 필요한 need 외에는 쓰지 않는 것이 유리함
7. 검증된 hint 외의 hint 사용은 DBA팀 CONFIRM 후에 사용할것
ð INDEX DESC 는 예외
8. MAX 함수는 INDEX DESC 로 대체
9. PLAN 출력후 operation 이 sort merge나 hash join 이면 nested loop 로 hint 줘야 함
10. 실적을 조회하는 경우 data 를 최소로 read 할 수 있는 table 선정이 중요
ð 하위조직별로 실적 sum 을 요구하는 UI 에서 조직별,제품별을 GROUP BY 하는 것보다는 원장 TABLE 을 SUM 하는것이 빠름
11.UI 구조상 여러 조건에 따라 SQL 문이 달라지는경우 SQL 을 분리하거나, Dynamic sql 을 사용할것
12. UI 를 보고 어떤 TABLE을 DRIVING 으로 쓸것인지 어떤 INDEX 를 쓸것인지 결정한후 설계->프로그램 작성하는 것이 좋
13. 동일 table 을 두번 select 하지 말아야 함
ð 예 UI 에서 월,분기,누계실적을 요구하는 경우 월로 Select, 분기 select,누계 select 를 따로 하는 것보다 누계로 한번만 select 후 분기,월을 계산하면 빨라질 수 있슴
14. PLAN 출력후 PK 로 INDEX SCAN 된다면 ORDER BY 쓰지 말것
(이렇게하면 전체범위 처리를 함)
