SQL BOOSTER - 인덱스 설계 과정
SQL 하나를 위한 인덱스 설계는 어렵지 않다.
테이블 관련 SQL을 모두 검토하고 종합적으로 인덱스를 설계하는 것이 가장 중요하다.
SQL 하나만 보고 인덱스를 생성해서는 안 된다.
실무에서 이는 어려운 일이지만, 어떻든 간에 인덱스는 전체 SQL을 보고 설계하는 것이 정석이다.
전체 SQL을 볼 수 없다면 가능한 많은 SQL을 살펴보자
인덱스 종합적 설계 과정
- SQL별 접근 경로 조사
- 테이블 별 접근 경로 정리
- 종합적인 인덱스 설계
- 핵심 테이블 및 핵심 SQL 집중 설계
- 생성 및 모니터링
SQL 별 접근 경로 조사
이 과정을 진행하기 위해서는 개발 완료된 모든 SQL을 살펴봐야한다. SQL을 살펴보면서 사용된 접근 경로들을 엑셀로 정리해 놓는다.
- 각 항목을 살펴보면, 파일명 SQL ID를 관리해 해당 SQL이 존재하는 위치를 관리한다.
- SQL의 CRUD를 구분하고, 테이블 접근 경로를 정리한다.
- 마지막 칸에 SQL이 잘못되었거나, 의심되는 부분이 있으면 정리해 놓는다.
CRUD 항목에 U나 D로 표시한 부분이 최적화 1순위 SQL이다. 해당 SQL의 조건절에 적절한
인덱스를 설정하지 않으면 전체적으로 데이터베이스 동시성이 떨어진다.
가장 중요한 것은 접근 경로다.
테이블의 컬럼명과 다양한 기호들을 사용해 정리한다.
- J: 조인
- J->: 아우터 조인 기준 집합
- J <- : 아우터 조인의 참고 집합
- = : 같다 조건
- =+ : 아우터 조인에서 참고 집합의 같다 조건
- ><:범위조건, LIKE 포함
- S: SELECT 절에서 사용 (커버 인덱스 고려)
- O: ORDER BY(페이징 고려시), 컬럼들을 [,]로 묶을 것
- IN : IN 조건
- !IN : Not IN 조건
- ISN: ISNULL 조건
- MM : SELECT 절에서 MIN,MAX 집계함수 사용
CUS_ID 컬럼으로 조인 되고 있다면, CUS_ID(J)와 같이 표시한다.
CUS_ID로 조인이 되면서 ORD_DT에는 범위 조건이 사용된다면, CUS_ID(J), ORD_DT(><)와 같이 표시한다.
테이블별 접근 경로 정리
두 번째 단계는 테이블별 접근 경로 정리다. 앞에서 정리한 SQL별 접근 경로는 SQL을 기준으로 접근 경로를 정리했기 때문에 테이블별 인덱스를 설계할 수가 없다.
SQL별 접근 경로를 아래 표와 같이 테이블 순서로 정렬해서 엑셀표로 만든다. 이때 테이블별로 이미 존재하는 인덱스도 추가해 정리하도록 한다. 여기에 표시하지는 않았지만, 테이블의 건수까지 정리해 놓는다면 인덱스 설계에 큰 도움이 될 것이다.
종합적인 인덱스 설계
앞에서 정리한 테이블별 접근 경로를 살펴보면서 접근 경로별로 예상 인덱스 항목에 사용 가능한 인덱스를 적어 넣는다.
현재 존재하는 인덱스 중에 사용 가능한 것이 없다면, 인덱스를 신규로 설계하고 예상 인덱스 부분을 신규로 채워 넣는다.
예상 인덱스를 정리할 때는 조건에 따른 선택성을 따져봐야한다.
이 작업을 통해 새로운 인덱스가 설계되고 기존 인덱스 중에 불필요한 것도 선별해 낼 수 있다.
불필요한 인덱스를 제거하면 좋지만, 인덱스 제거는 매우 어려운 일이다.
핵심 테이블 및 핵심 SQL 집중 설계
핵심 테이블이나 핵심 SQL들은 추가로 더 검토할 필요가 있다.
핵심 테이블은 시스템에 따라 다양하게 정의할 수 있다. 일반적으로 데이터가 많이 발생하는 실적 테이블을 핵심 테이블로 정의한다.
핵심 테이블은 많은 인덱스를 생성하기에 부담이 있다.
따라서 관련 SQL을 정밀하게 검토해서 최적의 인덱스를 구성하는 전략이 필요하다.
핵심 테이블들의 인덱스 설계시에는 접근 경로만 보지 말고, SQL문 전체를 살피는 것이 좋다.
인덱스 추가 없이 프로세스나 SQL 자체를 변경해 개선 할 수도 있기 때문이다.
생성 및 모니터링
종합적인 설계로 인덱스를 생성했다고 해서 DB 성능 문제가 무조건 해결되는 것은 아니다.
성능이 나빠지거나, 원하는 만큼 안나올수도 있다. 이런 경우에는 인덱스를 변경하거나 적절한 힌트를 사용해야한다.
ㄱ그러므로 인덱스를 생성한 후에는 DB 모니터링이 필수이다.