이 기사는 쿼리 최적화를위한 Oracle Index 생성 및 사용에 대해 자세히 설명합니다. 다양한 인덱스 유형 (B- 트리, 비트 맵, 기능 기반, 리버스 키, 도메인), 응용 프로그램 및 성능 모니터링을 탐색합니다. 이 기사는 또한 OV에 대한주의를 기울입니다 쿼리 최적화를 위해 Oracle에서 인덱스 생성 및 사용 쿼리 성능을 최적화하는 데 Oracle에서 인덱스를 작성하고 사용하는 것이 중요합니다. 인덱스는 데이터베이스가 특정 열 값을 기반으로 테이블에서 행을 빠르게 찾을 수있는 데이터 구조입니다. 책의 색인과 유사하게 작동합니다. 모든 페이지를 스캔하는 대신 관련 섹션으로 직접 이동할 수 있습니다. 인덱스를 만들려면 CREATE INDEX 문을 사용합니다. 이 명령문은 인덱스 이름, 적용되는 테이블 및 그에 따른 열을 지정합니다. 예를 들어, employees 테이블의 last_name 열에서 B-Tree Index (가장 일반적인 유형)를 만들려면 다음 SQL 문을 사용합니다. CREATE INDEX emp_last_name_idx ON employees (last_name); Oracle은 employees 테이블의 데이터가 수정 (삽입, 업데이트 또는 삭제) 될 때마다 인덱스를 자동으로 유지합니다. 쿼리가 인덱스 된 열에서 필터링하는 WHERE 절을 사용하면 데이터베이스는 인덱스를 사용하여 검사해야 할 행의 수를 크게 줄여서 쿼리 속도를 향상시킬 수 있습니다. 예를 들어, SELECT * FROM employees WHERE last_name = 'Smith'; 이 지수에서 큰 혜택을받을 것입니다. 데이터베이스는 전체 테이블 스캔을 수행하는 대신 Index를 사용하여 last_name = 'Smith' 로 행을 빠르게 찾을 수 있습니다. 또한 여러 열에서 복합 인덱스를 생성하여 열 값의 조합을 기반으로 효율적인 조회를 허용 할 수 있습니다. 예를 들어, CREATE INDEX emp_dept_lname_idx ON employees (department_id, last_name); 부서와 성 쿼리 필터링에 유용합니다. 올바른 색인을 사용하는 것은 데이터베이스 튜닝 및 성능 최적화의 핵심 측면입니다. Oracle의 다른 유형의 인덱스 및 사용시기 Oracle은 여러 시나리오에 적합한 여러 인덱스 유형을 제공합니다. B-Tree Index : 이것은 가장 일반적인 유형이며 평등, 범위 및 정렬 된 검색과 관련된 대부분의 시나리오에 적합합니다. 클로스 WHERE = , > , , >= , , BETWEEN , IN , LIKE (선행 와일드 카드 만 포함) 조건을 사용하여 쿼리에 효율적입니다. 비트 맵 인덱스 : 이 인덱스는 카디널리티가 낮은 열에 대해 매우 효율적입니다 (별도의 값이 거의 없습니다). 범주 또는 깃발을 나타내는 열 (예 : 성별, 상태)에 특히 유용합니다. 비트 맵 인덱스는 비트 맵을 사용하여 값의 존재 또는 부재를 나타내므로 이러한 저지성 열이 포함 된 쿼리에 대한 매우 빠른 조회가 발생합니다. 그러나 범위 쿼리의 효율성이 떨어집니다. 기능 기반 인덱스 : 이러한 인덱스는 열 또는 열 세트에 적용되는 함수의 결과에서 생성됩니다. 계산 된 값을 기준으로 자주 쿼리 할 때 유용합니다. 예를 들어, UPPER(last_name) 의 인덱스는 케이스 감도를 무시하는 쿼리 속도를 높입니다. 리버스 키 인덱스 : 자주 삽입되는 고 부가가치 데이터가있는 열에서 범위 스캔과 관련된 쿼리를 최적화하는 데 유용합니다. 데이터를 역순으로 인덱싱하여 이러한 유형의 스캔의 성능을 향상시킵니다. 도메인 색인 : 도메인 색인은 테이블 열 대신 도메인에서 생성됩니다. 이것은 덜 일반적이지만 동일한 도메인이 여러 테이블에서 사용되는 특정 시나리오에서 유리할 수 있습니다. 인덱스 유형의 선택은 데이터 특성 및 쿼리 패턴에 크게 의존합니다. 쿼리와 열의 값 분포를 분석하여 가장 적합한 인덱스 유형을 결정하십시오. 예를 들어, 몇 가지 별개의 값만있는 고객 상태를 나타내는 열이있는 경우 비트 맵 인덱스가 B- 트리 색인보다 효율적입니다. 쿼리에 자주 계산 된 값이 포함되면 기능 기반 인덱스를 고려해야합니다. 인덱스의 성능 영향 모니터링 인덱스의 성능 영향 모니터링에는 인덱스 생성 전후에 쿼리 실행 시간과 리소스 사용량을 추적해야합니다. Oracle은 다음과 같은 도움을 줄 수있는 몇 가지 도구를 제공합니다. SQL*Plus/SQL 개발자 : 이 도구를 사용하면 쿼리를 실행하고 실행 계획을 관찰 할 수 있습니다. 실행 계획은 Oracle이 데이터에 액세스하는 방법을 보여 주므로 인덱스 사용 여부와 그 효과를 나타냅니다. 실행 계획에서 "색인 범위 스캔"또는 "INDEX FAST FULL SCAN"을 인덱스 사용의 긍정적 인 지표로 찾으십시오. AWR (Automatic Workload Repository) : AWR은 과거 성능 데이터를 제공하여 인덱스 생성 전후의 성능을 비교할 수 있습니다. CPU 사용량, I/O 운영 및 쿼리 실행 시간과 같은 메트릭을 분석 할 수 있습니다. ADDM (Automatic Database Diagnostic Monitor) : ADDM은 비효율적 인 인덱스 사용 또는 부족과 관련된 성능 병목 현상을 식별하기 위해 AWR 데이터를 분석합니다. 인덱스 생성 또는 수정에 대한 권장 사항을 제공합니다. DBMS_STATS 패키지 : 이 패키지는 테이블 및 인덱스에 대한 통계를 수집하는 절차를 제공하며, 최적화가 효율적인 실행 계획을 생성하는 데 중요합니다. 정기적으로 통계를 수집하는 것은 Optimizer가 정확한 정보를 갖도록하는 데 중요합니다. 이러한 메트릭을 신중하게 모니터링하면 인덱스의 긍정적 또는 부정적인 영향을 쿼리 성능에 평가할 수 있습니다. 기대에도 불구하고 인덱스를 사용하지 않으면 쿼리 및 색인 정의를 검토하여 잠재적 인 문제를 식별하십시오. 너무 많은 인덱스를 사용하는 단점 인덱스는 쿼리 성능을 크게 향상 시키지만 너무 많은 사용은 몇 가지 단점을 가질 수 있습니다. 저장 공간 증가 : 각 인덱스는 추가 저장 공간을 소비하여 전체 데이터베이스 크기 및 관리 비용에 영향을 줄 수 있습니다. DML 작업 속도가 느립니다 (삽입, 업데이트, 삭제) : 인덱스 유지에는 데이터 수정 작업 중에 추가 오버 헤드가 필요합니다. 색인이 많을수록 이러한 작업이 느려집니다. 데이터가 변경 될 때마다 각 색인이 업데이트되어야하기 때문입니다. 인덱스 유지 보수 오버 헤드 증가 : 인덱스 유지에는 리소스가 필요합니다. 인덱스가 많을수록 유지 보수 오버 헤드가 높아집니다. Optimizer Confusion : 많은 수의 인덱스가 때때로 쿼리 최적화기를 혼동하여 최적의 실행 계획을 선택할 수 있습니다. Optimizer는 다양한 옵션을 평가하는 데 더 많은 시간을 소비하여 인덱스의 이점을 잠재적으로 부정 할 수 있습니다. 따라서 가장 자주 실행되고 성능이 중요한 쿼리를 기반으로 인덱스를 신중하게 선택하는 것이 중요합니다. 조항이 WHERE 이나 카디널리티가 높은 열에 거의 사용되지 않는 열에 인덱스를 생성하지 마십시오. 더 이상 유익하지 않은 인덱스를 정기적으로 검토하고 제거합니다. 잘 계획된 인덱싱 전략은 수많은 인덱스를 유지하는 데 드는 비용으로 성능의 균형을 유지합니다.
