index 잘 타지 못하는 경우

[ 인덱스 ] 

- clustering factor 를 잘 확인하고 cardinality 를 확인해서 이제 이슈를 해결해보자 

- 인사정보 조회데이터에서 이제 [이름], [조직명] 에 대한 데이터를 이제 운영 

 

 

 

1) 통계정보의 불확실성

QueryOptiizer 는 SQL 의 실행계획을 수립하는 과정에서 통계쩡보를 활용한다

하지만 통계쩡보 데이터가 테이블에 대한 부정확한 데이터로 구성되어 있으면 이제 인덱스의 사용이 효율적인데도 불구하고 잘못계산된 Cardinality 에 의해 Table full scan 이 효율적인 수행이라고 판단할 수 잇따.

 

2) 인덱스 컬럼의 데이터 형 변환 

Dictionary view 중 all tab columns 에서 확인 가능하다. 

이제  toDV 등에 대해서 형변환이 이루어지면 인덱스를 잘 타지 못하는 경우이다. 

 

Clustering Factor는 데이터베이스에서 테이블에 저장된 데이터와 인덱스가 물리적으로 얼마나 잘 정렬되어 있는지를 나타내는 지표입니다. Clustering Factor가 낮을수록 데이터가 인덱스와 동일한 순서로 정렬되어 있어 성능이 좋습니다.

Clustering Factor를 확인하는 방법은 데이터베이스 시스템에 따라 다릅니다. 주로 사용되는 데이터베이스(MySQL, Oracle, PostgreSQL)별로 설명하겠습니다.

 

 

• 인덱스 설계: 카디널리티가 높은 컬럼(고유 값이 많은 컬럼)에 인덱스를 생성하면 검색 성능이 향상될 수 있습니다. 반면, 카디널리티가 낮은 컬럼(중복 값이 많은 컬럼)에 인덱스를 생성하면 성능 향상에 큰 도움이 되지 않을 수 있습니다.
• 추천 : 네이버 블로그
• 쿼리 최적화: 데이터의 중복 정도를 파악하여 효율적인 쿼리 계획을 수립하는 데 도움이 됩니다.

 

 

1. 쿼리 패턴 분석 및 인덱스 재설계

• 쿼리 로그 분석: 성능 저하를 유발하는 쿼리 패턴을 식별하기 위해 데이터베이스의 쿼리 로그를 분석했습니다.
• 주요 필드 인덱스 선정: WHERE 조건, JOIN, GROUP BY, ORDER BY 절에서 자주 사용되는 필드에 대해 적합한 인덱스를 설계했습니다.
• 복합 인덱스 도입: 단일 컬럼 인덱스 대신, 자주 조합되는 컬럼을 대상으로 복합 인덱스를 생성하여 불필요한 데이터 스캔을 줄였습니다.

2. 클러스터형 인덱스 최적화

• 클러스터형 인덱스 활용: 데이터를 정렬된 상태로 저장하는 클러스터형 인덱스를 테이블의 주요 검색 조건에 따라 재구성하여, 검색 속도를 높였습니다.