MySQL의 기본 -5

인덱스(Index)

인덱스는 sortedList처럼 처음 넣을 때 부터 정렬을 해서 데이터를 저장하기 때문에, INSERT, UPDATE, DELETE 의 성능을 희생하고 대신 select로 데이터 읽어오는 속도가 빠르다.

인덱스의 구조와 SELECT 성능 향상 원리

인덱스가 존재하면, 테이블의 데이터가 마치 sorted list처럼 미리 정렬된 상태로 저장되고 관리됩니다. 이로 인해 데이터 삽입, 삭제, 갱신 시에는 정렬된 구조를 유지해야 하므로 어느 정도의 성능 저하가 불가피하지만, 그 대신 SELECT 쿼리는 데이터 조회 시 압도적으로 빠른 성능을 제공합니다.

왜 인덱스를 사용하면 SELECT 속도가 빨라질까?

대표적으로 MySQL InnoDB는 B-Tree(균형 트리) 자료구조를 인덱스에 사용합니다. B-Tree는 모든 인덱스 키가 항상 정렬된 상태로 유지되도록 관리하고, 이 덕분에 원하는 값을 찾을 때 전체 데이터를 처음부터 끝까지 하나씩 비교(선형 탐색)할 필요 없이, 트리의 분기 구조를 따라가며 O(log n)이라는 매우 빠른 시간 복잡도로 탐색할 수 있습니다. 즉, 데이터가 수백만~수억 건이 쌓여 있어도, 인덱스를 활용하면 트리의 레벨만큼의 단계만 거치면 원하는 값을 즉시 찾아낼 수 있는 것입니다.

반면, 인덱스가 존재하지 않는다면 데이터는 정렬된 상태가 아니므로, 데이터베이스는 원하는 행을 찾기 위해 테이블의 모든 레코드를 처음부터 끝까지 하나하나 직접 확인해야 합니다. 이 과정을 Full Table Scan이라고 하며, 데이터가 많을수록 성능이 기하급수적으로 떨어지게 됩니다.

인덱스와 디스크 I/O의 관계

데이터베이스의 최대 성능 병목 지점 중 하나가 바로 디스크 I/O입니다. 인덱스를 사용하면, B-Tree 구조 덕분에 필요한 데이터 블록(페이지)만 효율적으로 읽어들이면 되므로, 불필요하게 전체 테이블을 디스크에서 읽어올 필요가 없어져 디스크 I/O 횟수를 획기적으로 줄일 수 있습니다. 또한, B-Tree는 인덱스 키를 기준으로 데이터가 디스크의 연속적인 블록에 저장되도록 유도합니다. 이로 인해 데이터베이스는 랜덤 I/O보다 훨씬 빠른 순차 I/O로 최적화가 가능해집니다.

실무적 결론

정리하면, 인덱스는 SELECT 성능을 획기적으로 향상시켜주는 필수 도구입니다. 하지만 인덱스를 많이 만들 수록 INSERT, UPDATE, DELETE 성능은 상대적으로 희생될 수 있고, 디스크 공간도 더 많이 소모하게 됩니다.

따라서, 인덱스 설계는 조회 패턴, 데이터 규모, 서비스 특성 등을 고려해 최적의 밸런스를 찾아주는 것이 실무적으로 매우 중요합니다. 개인적으로 Covering Index를 이용할 때도 인덱스의 설계는 필수적이라고 판단됩니다.