목차
인덱스 구조(2)
B+트리
B+Tree는 B-Tree의 변형입니다. 구조 다이어그램을 살펴보기 위해 최대 차수가 4인 b+ 트리를 예로 들어 보겠습니다.
우리는 두 부분을 볼 수 있습니다:
- 녹색 점선 원으로 둘러싸인 부분이 인용된 부분으로, 데이터를 색인화하는 역할만 하고 데이터를 저장하지는 않습니다.
- 빨간색 점선 원으로 둘러싸인 부분은 데이터 저장 부분으로 리프 노드에는 특정 데이터가 저장되어야 합니다.
즉, B-트리에서는 저장된 데이터가 마지막 리프 노드에 배치됩니다.
마찬가지로 데이터 구조 시각화 웹사이트로 이동하여 다음을 시연할 수 있습니다.
https://www.cs.usfca.edu/~gall es/visualization/BPlusTree.html
데이터 세트 삽입: 100 65 169 368 900 556 780 35 215 1200 234 888 158 90 1000 88 120 268 250.
그런 다음 일부 데이터를 삽입하는 동안 노드의 변경 사항을 관찰합니다.
마지막으로 우리는 B+Tree와 B-Tree 사이에 세 가지 주요 차이점이 있음을 발견했습니다.
- 모든 데이터는 리프 노드에 나타납니다.
- 리프 노드는 단방향 연결 목록을 형성합니다.
- 비리프 노드는 데이터를 인덱싱하는 역할만 하며 특정 데이터는 리프 노드에 저장됩니다.
위에서 본 구조는 표준 B+Tree 데이터 구조인데, 다음으로 MySQL에 최적화된 B+Tree를 살펴보겠습니다 .
MySQL 인덱스 데이터 구조는 클래식 B+Tree를 최적화합니다. 원본 B+Tree를 기반으로 인접한 리프 노드를 가리키는 연결 목록 포인터가 추가되어 시퀀스 포인터가 있는 B+Tree를 형성하여 간격 액세스 성능을 향상시키고 정렬을 용이하게 합니다.
해시시
B+Tree 인덱스 지원 외에도 MySQL은 인덱스 유형---해시 인덱스도 지원합니다.
구조
해시 인덱스는 특정 해시 알고리즘을 사용하여 키 값을 새로운 해시 값으로 변환하고 이를 해당 슬롯에 매핑한 후 해시 테이블에 저장합니다.
두 개 이상의 키 값이 동일한 슬롯에 매핑되면 해시 충돌(해시 충돌이라고도 함)이 발생하며 이는 연결 목록을 통해 해결할 수 있습니다.
이는 기본적으로 데이터 구조의 해시 테이블과 일치합니다.
특징
- 해시 인덱스는 피어 비교(=, in)에만 사용할 수 있으며 범위 쿼리(between, >, <,...)는 지원하지 않습니다.
- 정렬 작업을 완료하기 위해 인덱스를 사용할 수 없습니다.
- 쿼리 효율성이 높고(해시 충돌 없음) 일반적으로 한 번의 검색만 필요하며 효율성은 일반적으로 B+Tree 인덱스보다 높습니다.
스토리지 엔진 지원
MySQL에서 메모리 스토리지 엔진은 해시 인덱스를 지원합니다. InnoDB에는 적응형 해시 함수가 있으며 해시 인덱스는 지정된 조건에서 B+Tree 인덱스를 기반으로 InnoDB 스토리지 엔진에 의해 자동으로 구축됩니다.
생각하다
InnoDB 스토리지 엔진이 B+Tree 인덱스 구조를 사용하는 이유는 무엇입니까?
1. 이진 트리에 비해 수준이 적고 검색 효율성이 높다
2. B-트리의 경우 리프 노드든 리프 노드가 아니든 데이터가 저장되므로 검색 시간이 줄어듭니다.
페이지에 저장되는 키 값과 포인터 감소로 인해 많은 양의 데이터를 저장하면 트리의 높이만 증가할 수 있어 성능이 저하됨 3.
B+트리는 해시 인덱스에 비해 범위 일치를 지원하며, 정렬 작업.
지수 분류
지수 분류
MySQL 데이터베이스에서 특정 유형의 인덱스는 주로 기본 키 인덱스, 고유 인덱스, 일반 인덱스 및 전체 텍스트 인덱스의 범주로 나뉩니다.
| 분류 | 의미 | 특징 | 키워드 |
|---|---|---|---|
| 기본 키 인덱스 |
테이블의 기본 키에 인덱스가 생성됨
|
기본적으로 자동 생성되며
하나만 있을 수 있습니다
.
|
주요한
|
|
고유 인덱스
|
동일한 테이블의 데이터 열에 있는 값의 중복 방지
|
여러 개가있을 수 있습니다
|
고유한
|
| 일반 목록 | 특정 데이터를 빠르게 찾으세요 | 여러 개가있을 수 있습니다 | |
| 전문 색인 | 전체 텍스트 인덱싱은 인덱스에 있는 값을 비교하는 대신 텍스트에 있는 키워드를 검색합니다. | 여러 개가있을 수 있습니다 | 전체 텍스트 |
클러스터형 인덱스 및 보조 인덱스
InnoDB 스토리지 엔진에서는 인덱스의 저장 형태에 따라 다음 두 가지 유형으로 나눌 수 있습니다.
| 분류 | 의미 | 특징 |
|---|---|---|
| 클러스터형 인덱스 |
데이터 저장소와 인덱스를 함께 사용하면 인덱스 구조의 리프 노드에 행 데이터가 저장됩니다.
|
반드시 있어야 하며
,
하나만 있어야 합니다.
|
|
보조
인덱스
|
데이터와 인덱스를 별도로 저장합니다. 인덱스 구조의 리프 노드는 해당 기본 키와 연결됩니다.
|
여러 개가있을 수 있습니다 |
클러스터형 인덱스 선택 규칙:
- 기본 키가 존재하는 경우 기본 키 인덱스는 클러스터형 인덱스입니다.
- 기본 키가 없으면 첫 번째 고유( UNIQUE ) 인덱스가 클러스터형 인덱스로 사용됩니다.
- 테이블에 기본 키나 적합한 고유 인덱스가 없으면 InnoDB는 자동으로 숨겨진 클러스터형 인덱스로 rowid를 생성합니다 .
클러스터형 인덱스와 보조 인덱스의 구체적인 구조는 다음과 같습니다.
우리는 다음을 알 수 있습니다:
- 클러스터형 인덱스의 리프 노드는 이 행의 데이터를 정지시킵니다.
- 보조 인덱스의 리프 노드에는 필드 값에 해당하는 기본 키 값이 걸려 있습니다.
검색 과정
구체적인 과정은 다음과 같습니다.
- 쿼리는 name 필드를 기반으로 하므로 먼저 name='Arm'을 기반으로 name 필드의 보조 인덱스에서 일치 검색을 수행합니다. 그러나 보조 인덱스에서는 Arm에 해당하는 기본 키 값 10만 찾을 수 있습니다.
- 쿼리로 반환된 데이터는 *이므로 이때 기본키 값 10을 기준으로 10에 해당하는 레코드를 클러스터형 인덱스에서 검색하여 최종적으로 10에 해당하는 행을 찾아야 합니다.
- 마지막으로 이 행의 데이터를 가져와 직접 반환할 수 있습니다.
테이블백 쿼리(Table-back query) : 먼저 보조 인덱스의 데이터를 검색하여 기본 키 값을 찾은 후 클러스터형 인덱스의 기본 키 값을 기준으로 데이터를 얻는 방식을 테이블 백 쿼리라고 합니다.
생각하다
다음 두 SQL 문 중 어느 것이 더 효율적인가요? 이유는 무엇입니까?
A. select * from user where id = 10;
B. select * from user where name = 'Arm';
(참고: id는 기본 키이고 이름 필드는 색인이 생성되어 있습니다)
A문의 실행 성능은 B문 보다 높습니다.
문 A는 클러스터형 인덱스로 직접 이동하여 데이터를 직접 반환하기 때문입니다. 명령문 B는 이름 필드의 보조 인덱스를 먼저 쿼리한 다음
클러스터형 인덱스를 쿼리해야 하며, 이는 테이블 쿼리를 수행해야 함을 의미합니다 .
InnoDB 기본 키 인덱스의 B+트리 높이는 얼마입니까?
가정:
데이터 한 행의 크기는 1k이고, 이러한 데이터는 한 페이지에 16행을 저장할 수 있습니다. InnoDB 포인터는 6바이트의 공간을 차지하며
, 기본키가 bigint인 경우에도 차지하는 바이트 수는 8바이트이다.
높이는 2:
n * 8 + (n + 1) * 6 = 16*1024이고 n은 대략 1170으로 계산됩니다.n은 현재 저장된 키 수를 나타냅니다. n*8은 기본 키가 차지하는 총 바이트 수를 계산합니다. n+1은 포인터 수를 나타내며 키보다 포인터가 하나 더 많습니다. 1KB(K) = 1024비트, 모든 단위는 여기서는 비트로 통합하여 사용하므로 16kb = 16 * 1024 비트, 16은 16페이지,
1171* 16 = 18736입니다
. 즉, 트리 높이가 2라면 18,000개 이상의 레코드를 저장할 수 있습니다.
높이는 3:
1171*1171*16 = 21939856
이다. 즉, 트리의 높이가 3이라면 약 2200w 정도의 레코드를 저장할 수 있다.
끝
학습 내용: Dark Horse 프로그래머 - MySQL 데이터베이스 과정