좀더 나은 나를 위하여

조회하고자 하는 데이터의 특성상 가장 최근의 데이터부터 역순으로 인덱스를 조회하는 것이 유리할 경우가 있다.

예)

신입사원의 입사정보조회

게시판의 최신 글 내용 조회

로그성 데이터의 정보조회

내림차순인덱스 생성하는 방법

CREATE INDEX 인덱스명 ON BIG_EMP (EMPNO DESC)

조회시 힌트를 사용하는 방법

SELECT /*+ INDEX_DESC  (BIG_EMP 인덱스명) */

EMPNO FROM BIG_EMP ROWNUM<10 ;

데이터의 존재여부만 확인하면 되는데 불필요하게 전체 건수를 count 하는 경우다.

SELECT COUNT(*) AS CNT FROM BIG_EMP 

WHERE DEPTNO='60' AND MGR='7698';

If(rs.getString("CNT") > 0){

    …

}

Or

SELECT * FROM BIG_EMP 

WHERE DEPTNO='60' AND MGR='7698';

If(rs.size() > 0){

   …

}

SELECT COUNT(*) CNT FROM EMP

WHERE DEPARTMENT='SALES' 

  AND LOCATION='SEOUL'  AND ROWNUM <= 1;

If(rs.getString("CNT") > 0){

   …

}

MS-SQL 인 경우 Top N 사용

SELECT COUNT(*) FROM DUAL

WHERE EXISTS(

  SELECT ‘x’ FROM BIG_EMP 

  WHERE DEPT='60' AND MGR='7698'

);

If(rs.getString("CNT") > 0){

    …

}

여러가지 DB에 유연하도록 하기위해서 EXISTS 를 추천한다.

한테이블에 모든 정보를 모아놓으면(반정규화) 조인에 의한 부하가 줄어들거라는 기대를 하게된다.

하지만 고려해야되는 것들이 있다.

1. 저장공간의 낭비가 생긴다.

2. I/O가 증가된다.(특히 블럭단위 조회시)

아래 예가 있다.

만일 사원이 40만명이라면 

40만  레코드 X 168 Byte 

= 67,200,000 Byte

= 64Mbyte

64Mbyte 의 저장공간이 필요하게 된다.

그리고 만일 DB에서 한번에 읽어들이는 블록이 8Kbyte 라면 

한번 I/O 때 48개의 레코드를 읽게 된다.

정규화를 한 위의 사원테이블과 부서테이블은 각각

사원 테이블

40만 레코드 X 46 Byte

= 18,400,000 Byte

= 17.5Mbyte

부서 테이블

100 레코드X 130Byte

= 12Kbyte

약 17.6Mbyte 의 저장공간이면 되고

DB에서 한번에 읽어들이는 블록이 대략 178개 레코드를 읽을 수 있다.

즉

저장공간에서는 3배가 줄어들게 되고

풀 스캔시 4배의 I/O 가 감소되게 된다.

실제 필드에서는 수천만 수억, 수십억의 레코드가 있는 테이블도 있으므로 성능의 차이는 더 커진다.