SQL 실행(Operation) 시 두가지 방법이 있는데,
이 중 INDEX 방법은, table 일부 레코드에만 액세스를 하여 탐색하는 기법으로 DB성능이 크게 향상할 수 있는 방법이다.
큰 테이블에서 소량의 데이터를 검색할때 사용할 수 있는 인덱스 기법은, 효율적인 인덱스 정렬 및 인덱스 컬럼 구성하는 것이 필요하다.
이때 효율화라는 것은 두가지 방안으로 구현할 수 있다.
선택도는 낮고 카디널리티는 높은 컬럼으로 구성(=이름보다는 주민등록번호, 이름+지역 등의 중복키 등 유일성이 높은 항목을 인덱스로 채택)
인덱스(루트/브랜치/리프)를 거쳐 table 탐색 후 후속처리 작업으로 랜덤액세스를 할 수 있는데, 이 랜덤액세스가 DBMS 성능저하의 주 요인으로 작용할 수 있다.
Balance Tree, 정렬한 인덱스를 별도의 메모리에 저장하는 방식 혹은 구조를 말한다.
인덱스를 사용한다면 데이터를 일부만 읽고 멈출 수 있고, 이때 인덱스는 정렬된 상태로 저장한다.
인덱스 정렬 상태 및 Tree(노드) 구조에 따라 루트/브랜치/리프로 구조를 나눌 수 있고, 해당 구조를 탐색하면서 인덱스를 찾는다.
B Tree 구조는 데이터 유지를 위해 자주(DBMS에서 가장 많이) 사용하는 구조이다. 효율적이고 빠른 탐색이 가능하며, 데이터를 정렬(Sort) 상태로 유지한다.
인덱스 구조를 사용하면 다음의 3가지 장점을 확인할 수 있다.
어떠한 값에 대해서도 같은 시간에 결과를 얻을 수 있다.
정렬을 마친 데이터 구조 탐색에 효과적이고, 정렬이 안된 데이터를 선형탐색할 경우 성능에 불균형이 온다.
루트로부터 리프까지의 거리가 일정하고, 이는 곧 어떠한 데이터를 탐색하여도 소요시간이 일정하다는 의미이다.
밸런스는 정기적으로 재구성해주는 작업이 필요하다.
인덱스를 사용한다면 장점과 단점 모두 존재하고, 반드시 full scan보다 빠르다고 확신할 수 없기에 반드시 구성환경을 잘 알아본 후 사용하는 것이 좋다.
인덱스 갱신의 오버헤드로 갱신처리기능이 약화된 상태이다.
테이블 데이터의 갱신 및 제거 시 인덱스 또한 갱신되어야 하며(별도의 객체라도 각자의 주소값을 참조하고 있으므로), 인덱스 갱신 이외의 부차적인 처리가 누적될 경우 처리 시간이 증가한다.
DB table에 복수의 인덱스가 생성될 경우, 옵티마이저가 예측을 벗어날 수 있으므로 튜닝이 필요하다.
인덱스 table은 DB와는 별도의 table이며, 이에 따라 백업시간이 늘어나고 저장소 공간 비용 역시 증가한다.
인덱스가 비효율적으로 정렬되어 있는 상태에서 대용량 데이터의 인덱스 스캔 시 full scan보다 오히려 성능이 불리할 수 있다.
빠른 데이터 탐색을 위해 인덱스를 생성하는 규칙이 정해져 있다.
※ Where 절에서 "=" 조건으로 조회되는 컬럼을 생성하거나, 복합인덱스의 경우 "=" 조건이 앞으로 오도록 설정한다.
B Tree - https://velog.io/@ryuhyewon/B-tree-Btree, https://m.blog.naver.com/nimdrak/222055921004
카디널리티/선택도 - https://velog.io/@jduck1024/%EC%B9%B4%EB%94%94%EB%84%90%EB%A6%AC%ED%8B%B0-VS-%EC%84%A0%ED%83%9D%EB%8F%84-feat.-NDV-Density