데이터베이스는 기본적으로 인덱스(Index)라는 것을 활용해 인덱싱(Indexing)을 할 수 있습니다. 인덱싱(Indexing)은 쿼리가 처리 될 때 필요한 디스크 액세스 횟수를 최소화하여 데이터베이스 성능을 최적화하는 방법 중 하나입니다. 인덱스 또는 데이터베이스 인덱스는 데이터베이스 테이블의 데이터를 빠르게 찾고 액세스하는 데 사용되는 데이터 구조입니다. 색인은 일부 데이터베이스 열을 사용하여 작성됩니다. 이러한 것은 키 값과 연결된 행을 빠르게 찾을 수 있도록 도움을 줍니다(B-Tree)
인덱스는 크게 클러스터 인덱스(Cluster Index) 그리고 비 클러스터 인덱스(Uncluster Index, Secondary Index) 두 가지 종류가 있습니다.
Cluster Index이 인덱스는 해당 값을 기반으로 실제 정렬순서나 저장순서를 결정합니다. 그래서 테이블 당 오직 1개의 인덱스만 필요로 합니다. 엔진에 따라 다르지만 대부분 기본적으로 PK를 클러스터 인덱스로 지정합니다. 테이블에 클러스터 인덱스가 지정되지 않으면 정렬되지 않는 구조(Heap)로 저장됩니다.
Uncluster Index(Secondary Index)이 인덱스는 실제로 값의 순서를 결정하지는 않습니다. 데이터의 행을 가리키는 값만 가질 뿐입니다. 그래서 행에 대한 로케이터가 필요합니다. 이것은 중간에 있는 노드처럼 활용이 됍니다. 이 참조를 통해 데이터의 위치를 알 수 있습니다. 그리고 이것은 클러스터 인덱스와 다르게 오직 1개의 존재라는 제한을 가지지 않습니다. 게다가 클러스터 인덱스와 달리 정렬의 기준을 정하지 않기 떄문에 INSERT 속도의 손실을 가져오지 않습니다.
인덱스의 사용 목적은 오직 검색(SELECT) 성능 향상에 있습니다. 그리고 성능 향상의 가장 기본적인 방법 중 하나는 인덱스를 잘 활용하는 것입니다. 앞에 소개하다시피 인덱스는 처음부터 끝까지 데이터를 찾으려고 하는 일은 막아주기 때문입니다. 물론 INSERT, UPDATE, DELETE에서 좀 더 추가적인 작업이나 업데이트를 해야 한다는 것이 아쉬울 수는 있습니다. 하지만 실제 이 3가지 작업은 SELECT(대략 낮게 잡아도 85%정도의 작업 비율)에 비해 실제 작업 비율이 적습니다. 그리고 실제로 UPDATE나 DELETE는 데이터를 찾아야 하므로 오히려 이 부분에서는 도움이 될 수도 있습니다. 이러한 이유 때문에 인덱스를 사용하는 편이 좋은데, 과연 어떤 기준에서 사용할지는 애매모호 합니다.
측정하기일단 인덱싱을 적용하려면 이 Query가 불필요한 작업을 하지 않는 것임에도 불구하고 성능 향상이 필요한 경우라고 할 수 있다. 모든 데이터베이스는 이 성능 측정에 필요한 도구를 제공하는데 예를 들면 MySQL은 Slow Query에 관한 log를 제공합니다. 이를 Slow query log라고 합니다. 이 Query중에 실행 빈도수가 높은 것부터 최적화의 대상으로 눈 여겨 봐야 합니다. 가장 좋은 방법은 실제 어플리케이션을 Deploy하고 Query Caching을 사용하지 않는 환경에서 측정하는 것이 가장 좋은 방법이 될 것 같습니다.
작성중....