인덱스란 무엇이고 왜 쓰는 걸까?

MySQL에서 조회 성능 개선을 위해 가장 자주 사용되는 Index에 대해 알아보겠습니다.

(해당 내용은 InnoDB 스토리지 엔진을 기준으로 작성했습니다.)

 

 

MySQL 공식문서에서 Index는 Optimization 영역으로 구분되어 있습니다.

특히, 조회 성능을 높이는 최고의 방법으로 Index를 직접적으로 언급하며, 인덱스의 사용을 강조하고 있습니다.

 

인덱스란?

공식문서에는 다음과 같이 작성되어 있습니다.

 

MySQL can quickly determine the position to seek to in the middle of the data file without having to look at all the data. This is much faster than reading every row sequentially.

(Index를 사용하면 전체 데이터를 조회하지 않고 빠르게 데이터를 찾을 수 있다.)

 

한마디로 데이터를 빠르게 찾을 수 있도록 도와주는 도구입니다.

 

그리고 그 핵심은 데이터를 전체 조회하지 않는다는 것이죠

그렇다면 왜 인덱스를 사용하면 데이터를 모두 조회하지 않아도 되는 걸까요?

 

그 이유는 바로 데이터 구조 B-Tree로 설명 가능합니다.

 

(MySQL에서 InnoDB에서 사용하는 명칭 B-tree는 B+Tree를 포함하는 개념으로

실제, InnoDB의 경우 B+Tree를 주로 사용하므로, 해당 포스트에 인용된 B-Tree는 B+Tree로 이해하시면 좋을 거 같습니다.)

 

B+Tree?

B+Tree는 데이터베이스 인덱스에서 가장 많이 사용되는 트리 데이터구조 중 하나로 자식 노드가 2개로 제한된 이진트리와는 달리 여러 자식 노드를 가질 수 있으며 항상 self-balancing 상태를 유지한다는 것이 중요한 특징입니다. 즉, 모든 서브 트리의 높이 차이는 1입니다.

 

MySQL는 B-Tree에 대해 다음과 같이 설명합니다.

 

A B-tree index can be used for column comparisons in expressions that use the =, >, >=, <, <=, or BETWEEN operators. The index also can be used for LIKE comparisons if the argument to LIKE is a constant string that does not start with a wildcard character. 

 

B-Tree에선 비교연산자를 활용한다는 점에서 위에서 인덱스의 핵심,데이터를 전체 조회하지 않는 이유로 이해할 수 있습니다.

 

그럼 자세한 구조를 보겠습니다.

• 각 노드는 page라고 불리며, 같은 level의 노드끼리는 doubly-linked 형태로 연결되어 있습니다. 이는 Order By에 따른 정렬 ASC, DESC에 대해 효율적인 탐색을 가능하게 합니다.
• 노드 내부 각 Records는 서로 단일 연결리스트로 연결되어 있습니다. 이는 노드 간 삽입, 삭제의 효율성을 보장합니다.
• Non-leaf 페이지의 Records 내부 데이터는 다음 노드의 주소(node pointer)를 저장하고 있으며, leaf 노드의 레코드에는 실제 데이터를 저장하고 있습니다.

 

위에서 언급했듯, Non-leaf 페이지의 Record는 범위 연산자를 포함하고 있는 것을 확인할 수 있습니다.

데이터 조회 시, 루트노드에서 조회하고자 하는 데이터에 대해 범위 연산을 거치기 때문에 데이터를 전체 조회할 필요가 없고 전체 구조가 항상 균형을 유지한 상태(모든 서브 트리의 높이 차이는 1) 덕분에, 데이터에 대한 일관성 있는 조회 성능을 보장할 수 있는 것 입니다.

 

 

 

그렇다면 인덱스는 늘 옳은 최적화 방법일까요?

모든 기술이 그렇듯, 일관된 장점만 있는 것은 아닙니다.

 

 

인덱스, 언제 써야할까?

공식문서에선 인덱스가 비효율적인 상황에 대해 이렇게 언급합니다.

 

데이터의 양이 적고, 쿼리 수행의 실행계획이 대부분의 데이터를 조회하거나, 순차적인 조회가 일어난다면 인덱스는 좋은 방법이 아닐 것 입니다. 또한 인덱스는 데이터의 삽입, 수정, 삭제할 경우 각 인덱스를 반드시 업데이트하기 때문에 데이터의 변경이 자주 일어나는 컬럼은 인덱스로 적절하지 않습니다.

 

인덱스를 만드는 것만으로 디스크의 저장공간을 사용하는 것이기에 메모리와 성능을 고려하여 인덱스를 적절히 설정하고 활용하는 것이 가장 중요합니다.

 

 

 

 

출처

https://dev.mysql.com/doc/refman/8.4/en/innodb-introduction.html

https://dev.mysql.com/doc/refman/8.4/en/mysql-indexes.html

https://dev.mysql.com/doc/refman/8.4/en/optimization-indexes.html