다양한 데이터의 접근 형태에 일일이 대응하여 인덱스를 많이 만들 수 있는 환경이라면 인덱스 생성에 있어 고민의 여지가 적겠지만, 아쉽게도 인덱스가 많아지면 많아질수록 그에 따른 사이드 이펙트(DML 성능 저하, 저장 공간 차지)가 존재한다. 따라서 적은 수의 인덱스를 유지하는 동시에 다양한 데이터 접근 형태에 대해 인덱스 스캔을 지원하는 것은 중요하다. 이를 위해서는 복합 인덱스 기반으로 하나의 인덱스가 여러 상황을 커버할 수 있도록 테이블 설계가 이루어져야 한다. 해당 글에서는 이를 돕기 위해 복합 인덱스가 어떤 방식으로 작동하는지 알아보고, 복합 인덱스가 작동하는 경우의 수에 대해 다뤄보려고 한다. 이 글은 Mysql 기준으로 작성되었다. 복합 인덱스 작동 방식 복합 인덱스는 둘 이상의 칼럼을 통해 ..

실제로 DB를 다루게 되는 상황에서 빠질 수 없는 것이 바로 인덱스이다. 인덱스를 통하면 특정 조건에서 데이터의 조회 성능이 비약적으로 증가한다는 것은 누구나 알고 있는 사실이다. 그러면서도, 인덱스를 남발하면 안된다는 것 또한 다들 알고있다. 이 때 등장하는 논리가 바로 인덱스가 차지하는 공간적 비용과 데이터 삽입 시 추가적으로 발생하는 시간적 비용에 대한 비중을 무시할 수 없다는 것이다. 그런데 막상 이렇게 겁만 주고 실제로 그 정도가 어느 정도인지 알려주는 자료는 많이 없어서 이에 대해 실제로 확인해보려고 한다. 테스트 환경은 Mysql이고, 아무런 릴레이션이 존재하지 않는 독립된 테이블에서 테스트를 진행하였다. -- 테이블 생성 create table item ( id BIGINT NOT NULL..

RDBMS의 인덱스란? 인덱스란 DB 테이블에서 특정 데이터에 대한 검색 작업을 수행할 때, 검색 성능을 높이기 위해 사용되는 도구이다. 만약 데이터 N개가 존재하는 테이블에서 특정 칼럼의 값이 X인 데이터를 찾기 위해서는, 전체 테이블을 모두 확인해야 하며 O(N)의 시간복잡도를 갖는다. 이를 Full table scan이라고 하는데, 하나의 데이터를 위해 매번 O(N)이 걸리는 것은 상당히 비효율적이다. 이러한 문제를 해결하기 위한 것이 바로 인덱스이다. 주로 쓰이는 B+Tree 자료구조를 통한 인덱스를 이용 시 위와 동일한 조건에서 O(logN)의 향상된 시간복잡도를 갖는다. 인덱스에 이용되는 자료구조 1. Hash Table 해시 테이블은 Key - Value 자료구조이다. 따라서 특정 데이터의 ..