본문 바로가기

CS

(79)
MySQL의 기본 -13 B-Tree 인덱스 vs Clustered 인덱스 (클러스터형 인덱스) 차이점 정리 B-Tree 인덱스와 클러스터형 인덱스(Clustered Index)의 차이를 명확히 이해하는 것은 MySQL 등 RDBMS의 성능 최적화에 매우 중요하다. 두 인덱스 모두 B+Tree 구조를 기반으로 하지만, 저장 방식과 역할에서 차이가 크다. B-Tree 인덱스는 균형 잡힌 트리 구조로, 각 노드가 정렬된 키와 포인터를 가진다. 모든 리프 노드는 같은 깊이에 있어 검색 속도가 일정하다. 데이터는 물리적으로 정렬되지 않고, 보조 인덱스는 B-Tree 기반으로 동작한다. 예를 들어 기본 키(id)는 클러스터형 인덱스지만, name 같은 컬럼에 생성된 인덱스는 일반 B-Tree 보조 인덱스다. 클러스터형 인덱스는 데이터 자..
MySQL의 기본 -12 클러스터형 인덱스 클러스터형 인덱스(Clustered Index)에서 페이지 분할이 일어나는 원리에 대해 설명하자면, 클러스터형 인덱스는 기본적으로 B+Tree 구조를 이용해 데이터를 저장하고 정렬한다. 이때 페이지 분할(Page Splitting)은 새로운 레코드를 삽입할 때 해당 페이지가 꽉 차 있으면 발생한다. 예를 들어, 하나의 페이지에 10개의 레코드를 저장할 수 있는데, 이 페이지가 가득 차 있으면 새로운 데이터를 넣을 공간이 없어 기존 데이터를 나누어 새로운 페이지를 생성해야 한다. 특히 클러스터형 인덱스는 기본 키 순서대로 데이터가 정렬되므로, 만약 UUID처럼 랜덤한 값이 기본 키라면 데이터가 중간에 삽입되어야 하는 상황이 자주 발생한다. 이 경우 중간 페이지가 가득 차면 페이지 분할이 ..
MySQL의 기본 -11 체크포인트(Check point)란? 체크포인트(Checkpoint)는 InnoDB가 데이터 무결성을 보장하고, 장애 발생 시 복구 시간을 단축하기 위해 사용하는 핵심 메커니즘이다. MySQL(InnoDB)은 데이터를 디스크에 영구 저장할 때 WAL(Write-Ahead Logging) 방식을 따른다. 이는 데이터 변경 내용을 먼저 로그에 기록한 뒤 나중에 실제 데이터를 디스크에 반영하는 기법으로, 데이터 무결성과 복구를 효율적으로 지원한다. 체크포인트는 특정 시점에서 버퍼 풀(Buffer Pool)에 있는 변경된 데이터를 디스크로 플러시(Flush)하는 작업을 수행한다. 체크포인트가 필요한 이유는 크게 두 가지다. 첫째, 시스템 장애 발생 시 복구 시간을 단축하기 위함이다. InnoDB는 데이터를 ..
MySQL의 기본 -10 랜덤 I/O랜덤 I/O는 데이터가 디스크 내 임의의 위치에서 읽히거나 써지는 방식을 의미한다. 이러한 비연속적 데이터 접근은 디스크 헤드가 여러 위치로 이동해야 하므로 탐색 시간이 증가해 전반적인 입출력 속도를 저하시킨다. 특히 HDD에서는 회전하는 플래터 위에서 디스크 헤드가 데이터 위치로 물리적으로 이동하고 회전 대기 시간까지 겹쳐져 성능 저하가 심각하다. 반면 SSD는 플래터와 헤드가 없으므로 랜덤 I/O에 상대적으로 강하지만, 여전히 작은 단위의 많은 I/O 요청은 오버헤드를 유발한다. 랜덤 I/O의 대표적인 예로는 B-Tree 인덱스 탐색과 조인(Join) 수행 시 데이터가 여러 위치에서 불규칙하게 읽히는 경우가 있다. 예를 들어, 특정 id 값을 찾기 위해 인덱스를 따라가다 보면 다양한 블록을..
MySQL의 기본 -9 클러스터링 인덱스(Clustered Index) 추가 설명 클러스터링 인덱스는 테이블의 프라이머리 키(Primary Key)를 기준으로 데이터 레코드의 물리적 순서가 정해지는 방식입니다. InnoDB 스토리지 엔진은 모든 테이블에 대해 기본적으로 클러스터링 인덱스를 사용합니다. 이를 통해 데이터의 물리적 저장 순서가 프라이머리 키에 의해 결정되며, 다른 인덱스들은 이를 기반으로 세컨더리 인덱스(Secondary Index)를 생성합니다. 클러스터링 인덱스의 특징 프라이머리 키 기반 저장 프라이머리 키가 클러스터링 인덱스의 기준이 됩니다. 프라이머리 키 값에 따라 테이블의 레코드가 물리적으로 저장됩니다. 즉, 레코드는 프라이머리 키 순서대로 저장됩니다. 리프 노드에 모든 데이터 포함 B-Tre..
MySQL의 기본 -7 클러스터형 인덱스(Clustered Index)란 무엇인가 클러스터형 인덱스란 테이블의 실제 데이터 레코드가 인덱스 키 값의 순서대로 물리적으로 정렬되어 저장되는 인덱스 구조를 말합니다. 이 방식은 데이터가 정렬된 상태로 저장되기 때문에, 특정 범위에 해당하는 값을 빠르게 검색할 수 있다는 큰 장점이 있습니다. 예를 들어, 날짜나 ID 범위처럼 연속적인 값을 조건으로 하는 쿼리는 클러스터형 인덱스 덕분에 매우 빠른 속도로 처리됩니다. MySQL의 InnoDB 스토리지 엔진은 모든 테이블에 대해 반드시 하나의 클러스터형 인덱스를 사용합니다. 이 인덱스는 기본적으로 PRIMARY KEY에 대해 자동으로 생성되며, 테이블의 실제 데이터 페이지가 항상 PRIMARY KEY 값 기준으로 정렬되어 저장됩니다. 따라..
MySQL의 기본 -6 B-Tree 인덱스의 구조와 실제 저장 방식 B-Tree 인덱스는 데이터베이스에서 가장 널리 사용되는 인덱스 구조로, 인덱스 키 값이 항상 정렬된 상태로 관리된다는 특징이 있습니다. 즉, 인덱스가 적용된 컬럼의 값은 B-Tree 구조체 내에서 자동으로 오름차순(혹은 내림차순)으로 정렬되어 저장되고, 이 덕분에 빠르고 효율적인 탐색이 가능해집니다. 하지만 여기서 한 가지 오해하기 쉬운 점은, 인덱스의 키 값이 정렬되어 있다고 해서 데이터 파일 자체의 레코드도 항상 같은 순서로 저장된다는 것은 아니라는 점입니다. 많은 분들이 데이터가 INSERT된 순서대로 물리적으로 저장된다고 생각하지만, 실제로는 삭제와 재삽입, 빈 공간 재사용 등의 과정 때문에 데이터 파일 내 레코드는 임의의 순서로 저장될 수 있습니다...
MySQL의 기본 -5 인덱스(Index)인덱스는 sortedList처럼 처음 넣을 때 부터 정렬을 해서 데이터를 저장하기 때문에, INSERT, UPDATE, DELETE 의 성능을 희생하고 대신 select로 데이터 읽어오는 속도가 빠르다. 인덱스의 구조와 SELECT 성능 향상 원리 인덱스가 존재하면, 테이블의 데이터가 마치 sorted list처럼 미리 정렬된 상태로 저장되고 관리됩니다. 이로 인해 데이터 삽입, 삭제, 갱신 시에는 정렬된 구조를 유지해야 하므로 어느 정도의 성능 저하가 불가피하지만, 그 대신 SELECT 쿼리는 데이터 조회 시 압도적으로 빠른 성능을 제공합니다. 왜 인덱스를 사용하면 SELECT 속도가 빨라질까? 대표적으로 MySQL InnoDB는 B-Tree(균형 트리) 자료구조를 인덱스에 사용합니다..