잡동사니 보물섬

소트를 완료하고 나서 데이터 가공하기 

 - select 절에 여러 컬럼들을 붙여서 사용하면서 order by를 사용할 경우 

   차라리 order by 를 먼저 실행한 후 여러 컬럼들을 붙이는 것이 sort area 영역을 적게 사용한다.

Top-N 쿼리 

 - Top-N 쿼리 형태로 작성하면 소트 연산 횟수를 최소화함은 물론 Sort Area 사용량을 줄일 수 

   있다. ( order by 와 where 절 rownum 사용 )

    * 만약 rownum 이 아니라 일반 순번 컬럼을 사용 시 해당 효과를 얻을 수느 ㄴ없다. 

분석함수에서 Top-N 쿼리 

 - window sort 시에도 rank()나 row_number( )를 쓰면 Top-N 쿼리 알고리즘이 작동해 

   max( )등 함수를 쓸 때보다 소트 부하를 경감시켜 준다. 

Sort Order by 대체 

 - where A=값 order by B 일 때 A+B 인덱스를 사용한다면 sort order by 연산을 대체할 수 있다. 

   ( A 만 있거다 A와 B 사이에 다른 컬럼이 있으면 sort order by 연산을 대체 할 수 없다. ) 

 - 물론, 소트해야 할 대상 레코드가 무수히 많고 그 중 일부만 읽고 멈출 수 있는 업무에서만 

   이 방식이 유리하다. 인덱스를 스캔하면서 결과집합을 끝까지 Fetch 한다면 오히려 I/O 및 

   리소스 사용 측면에서 손해다. 대상 레코드가 소량일 때는 소트가 발생하더라도 

   부하가 크지 않아 개선 효과도 미미하다. 

Sort Group By 대체 

 - group 절에 사용 된 컬럼이 선두인 결합 인덱스나 단일 컬럼 인덱스를 사용한다면 

   sort group by 연산을 대체할 수 있다. 

   ( 'sort group by nosort' 가 실행계획으로 표시 된다. ) 

 - 이처럼 인덱스를 이용한 nosort 방식으로 수행될 때는 group by  오퍼레이션에도 불구하고 

   부분범위처리가 가능해져 OLTP환경에서 매우 극적인 성능 개선 효과를 얻을 수 있다. 

인덱스가 소트 연산을 대체하지 못하는 경우 

 - 인덱스 사용보다 full table scan이 효과적일 때 

 - 인덱스를 사용할 해당 컬럼에 not null 제약이 추가 되지 않았을 때 

    ( group by도 마찬가지다. group by nosort를 우해 사용하려는 인덱스가 단일 컬럼 

      인덱스일 때는 해당 컬럼에 not null 제약이 설정돼 있ㅇ야 제대로 작동한다. ) 

 - order by 절에 nulls first 구문을 사용하는 경우 

   ( 마찬가지 원리로 인덱스를 뒤쪽부터 읽으려고 index_desc 힌트를 쓰면 null 값들이 

    먼저 출력 될텐대, null 값들을나중에 출력하려고 nulls last 구문을 사용하면 소트가 발생한다.)

소트가 발생하지 않도록 SQL 작성 

 - 데이터 모델 측면에선 이상이 없는데, 불필요한 소트가 발생하도록 SQL을 작서하는 경우 

   예시 1) Union을 사용하면 중복제거를 하려고 sort unique 연산을 하게 되는데 union all을 

              사용해도 되는 경우 union을 사용하여 불필요한 sort unique 연산을 하게 되는 경우 

   예시 2) distinct를 사용하는 경우도 매우 흔한데, 대부분 exists 서브쿼리로 대체함으로써 

              소트 연산을 없앨 수 있다.