인덱스는 데이터베이스 테이블에 대한 검색 성능의 속도를 높여주는 자료구조임, 특정 컬럼에 인덱스를 생성하면 해당 컬럼의 데이터들을 정렬하여 별도의 메모리 공간에 데이터의 물리적 주소와 함께 저장됨
이렇게 인덱스를 생성하였다면 앞으로 쿼리문에 인덱스 생성 컬럼을 Where 조건으로 거는 등의 작업을 하면 옵티마이저에서 판단하여 생성된 인덱스를 탈 수 있음
인덱스를 타면 아래와 같이 인덱스를 타게 되고 먼저 인덱스에 저장되어 있는 데이터의 물리적 주소로 가서 데이터를 가져오는 식으로 동작하여 검색 속도의 향상을 가져올 수 있음
테이블을 만들고 안에 데이터가 쌓이게 되면 테이블의 레코드는 내부적으로 순서가 없이 뒤죽박죽 저장이 됨, 이러면 처음부터 끝까지 다 읽는 풀 테이블 스캔을 하게 됨
하지만 인덱스 테이블에서는 데이터들이 정렬되어 저장되어 있기 때문에 해당 조건에 맞는 데이터들을 빠르게 찾아낼 수 있음
인덱스를 사용하면 Order by에 의한 Sort 과정을 피할 수 있음
Order by는 부하가 많이 걸리는 작업임 정렬과 동시에 1차적으로 메모리에서 정렬이 이루어지고 메모리보다 큰 작업이 필요하다면 디스크 I/O도 추가적으로 발생됨
인덱스를 사용하면 이러한 전반적인 자원의 소모를 하지 않아도 됨, 이미 정렬이 되어 있기 때문에
INSERT, UPDATE, DELETE를 통해 데이터가 추가되거나 값이 바뀐다면 인덱스 테이블 내에 있는 값들을 다시 정렬을 해줘야한다는 점에서 DML에 취약함
검색을 위주로 하는 테이블을 인덱스로 생성하는것이 좋음
인덱스는 테이블의 전체 데이터 중에서 10 ~ 15% 이하의 데이터를 처리하는 경우에만 효율적이고 그 이상의 데이터를 처리할 땐 인덱스를 사용하지 않는 것이 더 나음
예를 들어 1개의 데이터가 들어있는 테이블과 100만개의 데이터가 들어있는 테이블이 있다고 할 때 1개의 데이터가 들어있는 테이블을 굳이 인덱스 스캔 없이 풀 스캔이 더 빠를 것임
인덱스를 관리하기 위해선 데이터베이스의 약 10%에 해당하는 저장공간이 추가로 필요함, 무턱대고 인덱스를 만들면 안됨
속도 향상에 비해 단점들의 COST를 비교해서 인덱스를 만들지 결정해야함
데이터베이스 서버에 성능 문제가 발생하면 가장 빨리 생각하는 해결책이 인덱스 추가 생성임
문제가 발생할 때마다 인덱스를 생성하면 인덱스가 쌓여가는 것은 하나의 쿼리문을 빠르게는 만들 수 있지만 전체적인 데이터베이스의 성능 부하를 초래함
인덱스를 생성하는 것보다는 SQL문을 좀 더 효율적으로 짜는 방향으로 나가야함, 인덱스 생성은 마지막 수단으로 강구할 문제임
인덱스는 항상 최신의 데이터를 정렬된 상태로 유지해야 원하는 값을 빠르게 탐색할 수 있음
그렇기 떄문에 인덱스가 적용된 칼럼에 INSERT, UPDATE, DELETE가 수행된다면 계속 정렬을 해주어야 하고 그에 따른 부하가 발생함
이런 부하를 최소화하기 위해 인덱스는 데이터 삭제라는 개념에서 인덱스를 사용하지 않는다라는 작업으로 이를 대신함
INSERT : 새로운 데이터에 대한 인덱스를 추가함
DELETE : 삭제하는 데이터의 인덱스를 사용하지 않는다는 작업을 진행함
UPDATE : 기존의 인덱스를 사용하지 않음 처리하고, 갱신된 데이터에 대해 인덱스를 추가함
생성된 인덱스를 가장 효율적으로 사용하려면 데이터의 분포도는 최대한으로 그리고 조건절에 호출 빈도는 자주 사용되는 컬럼을 인덱스로 생성하는 것이 좋음
인덱스는 특정 컬럼을 기준으로 생성하고 기준이 된 컬럼으로 정렬된 Index 테이블이 생성됨, 이 기준 컬럼은 최대한 중복이 되지 않는 값이 좋음
조건절에 자주 등장하는 컬럼, 항상 =
으로 비교되는 컬럼, 중복되는 데이터가 최소한인 컬럼(분포도가 좋은) 컬럼, ORDER BY
절에서 자주 사용되는 컬럼, 조인 조건으로 자주 사용되는 컬럼이 이에 해당함