<aside> 💡

INDEX 기본

• 자동으로 만들어지는 인덱스
  • PRIMARY KEY, UNIQUE에 의한 자동으로 만들어진다
• 수동인덱스
  • 사용자가 직접 생성한 INDEX를 의미

⇒ INDEX 조회

SELECT * FROM ALL_INDEXS WHERE TABLE_NAME=’테이블명’

⇒ 인덱스를 사용하면 좋은 곳

1. 데이터가 많은 곳
2. 삽입, 수정, 삭제가 잘 일어나지 않는 곳 </aside>

• 테이블에 저장된 데이터를 보다 빠르게 검색할 수 있도록 도와주는 자료구조

  • 장점
    • 빠른 검색 : 인덱스를 사용하면 테이블 전체를 검색하지 않아도 되므로, 데이터 검색 속도가 크게 향상된다.
    • 효율적인 정렬 : 이미 정렬된 형태로 인덱스가 저장되어 있어, 정렬 연산이 빠르게 수행된다.
  • 단점
    • 추가 저장공간 필요 : 인덱스를 생성하면 별도의 저장 공간이 필요
    • 데이터 수정비용 증가 : INSERT, UPDATE, DELETE 작업시 인덱스도 함께 갱신이 되어야 하므로 성능이 저하될 수 있다.

  ⇒ 언제 인덱스가 사용이 되는가

  • WHERE 절
    • 쿼리에서 특정 조건을 만족하는 행을 찾을때, 조건에 사용된 컬럼에 인덱스가 있으면 DBMS가 인덱스를 통해서 빠르게 해당 행의 위치를 찾는다
  • JOIN, ORDER BY, GROUP BY
    • 두 테이블을 조인하거나, 결과를 정렬 또는 그룹화 할 때도 인덱스가 사용된다.

INDEX의 삭제

• 조회 성능을 높이기 위해 만든 객체지만 저장공간을 많이 차지하며 DDL 작업(INSERT, UPDATE, DELETE)시 부하가 많이 발생해 전체적인 데이터베이스 성능을 저하시킨다
• DBA는 주기적으로 INDEX를 검토하여 사용하지 않는 인덱스는 삭제하는 것이 데이터베이스 전체 성능을 향상시킬 수 있다
  • DROP INDEX 인덱스명;

INDEX를 REBUILD 하기

• INSERT, UPDATE, DELETE와 같은 작업이 발생하면 인덱스의 검색 속도를 저하시키고 전체 데이터베이스 성능에 영향을 미치므로 주기적으로 INDEX를 리빌딩하는 작업을 해줘야한다
• ALTER INDEX 인덱스명 REBUILD;

인덱스가 제대로 작동하는지 확인하는 방법

• EXPLAIN PLAN 사용하기
  1. 실행할 쿼리 앞에 EXPLAIN PLAN FOR를 추가한다.
     1. 쿼리의 실행 경로를 분석
     2. 실행 계획 정보는 PLAN_TABLE이라는 테이블에 저장된다.
  2. 그 후 SELECT * FROM TABLE(DBMS_XPLAIN.DISPLAY); 명령을 실해하여 계획을 확인한다.

<aside> 💡

자동으로 만들어진 INDEX던, 우리가 수동으로 만든 INDEX건 조회할 때 사용이 되는 거라면 잘 사용이 되고 있는지 확인을 해야할 필요가 있다

</aside>