복합 색인은 어떻게 작동합니까?

복합 색인은 어떻게 작동합니까?

---

이전에 테이블의 작동 방식을 가정하여 복합 인덱스 ( 수학적 사용자를위한 인덱스) 를 만들었습니다 . 내 가정이 옳은지 아닌지 궁금했습니다.

인덱스의 열 순서를 나열 할 때 인덱스 그룹화 방법도 지정한다고 가정합니다. 당신이 열이있는 경우 예를 들어 a, b그리고 c, 당신은 그 같은 순서로 인덱스를 지정 a ASC, b ASC및 c ASC그 결과 지수는 본질적으로 각 "그룹"많은 인덱스 될 것입니다 a.

이 올바른지? 그렇지 않은 경우 결과 색인은 실제로 어떻게 표시됩니까?

---

복합 색인은 다중 값 키가 있다는 점을 제외하면 일반 색인과 동일하게 작동합니다.

필드 (a, b, c)에 인덱스를 정의하면 레코드가 먼저 a, b, c 순으로 정렬됩니다.

예:

| A | B | C |
-------------
| 1 | 2 | 3 |
| 1 | 4 | 2 |
| 1 | 4 | 4 |
| 2 | 3 | 5 |
| 2 | 4 | 4 |
| 2 | 4 | 5 |

---

복합 색인은 사전의 일반 알파벳 색인과 비슷하지만 다음과 같이 두 개 이상의 문자를 포함합니다.

AA - page 1
AB - page 12

기타

테이블 행은 먼저 인덱스의 첫 번째 열로 정렬 된 다음 두 번째 열로 정렬됩니다.

두 열 또는 첫 번째 열로 검색 할 때 사용할 수 있습니다. 색인이 다음과 같은 경우 :

AA - page 1
AB - page 12
…
AZ - page 245
BA - page 246
…

2문자 ( = 2테이블의 열) 를 검색 하거나 한 문자에 대한 일반 색인처럼 사용할 수 있습니다 .

A - page 1
B - page 246
…

사전의 경우 페이지 자체가 알파벳순으로 정렬됩니다. 이것이 CLUSTERED인덱스 의 예입니다 .

CLUSTERED색인이 아닌 일반 페이지에서 페이지에 대한 참조는 역사 책에서와 같이 정렬됩니다.

Gaul, Alesia: pages 12, 56, 78
Gaul, Augustodonum Aeduorum: page 145
…
Gaul, Vellaunodunum: page 24
Egypt, Alexandria: pages 56, 194, 213, 234, 267

ORDER BY두 개 이상의 열을 사용하는 경우에도 복합 인덱스를 사용할 수 있습니다 . 이 경우 DESC절이 유용 할 수 있습니다.

내 블로그 DESC에서 복합 색인에서 절 사용에 대한이 기사를 참조하십시오 .

• 내림차순 색인

---

가장 일반적인 인덱스 구현은 B- 트리를 사용하여 다소 빠른 조회와 합리적으로 빠른 범위 스캔을 허용합니다. 여기에서 설명하기에는 너무 많지만 여기에 B-trees 에 대한 Wikipedia 기사가 있습니다. 그리고 당신이 맞습니다. 인덱스 생성에서 선언 한 첫 번째 열은 결과 B- 트리의 상위 열이 될 것입니다.

고차 열에 대한 검색은 범위 스캔에 해당하며 B- 트리 인덱스는 이러한 검색에 매우 유용 할 수 있습니다. 이를 확인하는 가장 쉬운 방법은 아직 온라인 카탈로그로 변환하지 않은 라이브러리에있는 기존 카드 카탈로그와 유사하게하는 것입니다.

성이 "Clemens"인 저자의 모든 카드를 찾고 있다면 저자 카탈로그로 이동하여 전면에 "CLE- CLI"라고 적힌 서랍을 매우 빠르게 찾을 수 있습니다. 그것이 바로 서랍입니다. 이제 서랍에서 일종의 비공식 이진 검색을 수행하여 "Clemens, Roger"또는 "Clemens, Samuel"이라고 표시된 모든 카드를 빠르게 찾습니다.

But suppose you want to find all the cards for the authors whose first name is "Samuel". Now you're up the creek, because those cards are not gathered together in one place in the Author catalog. A similar phenomenon happens with composite indices in a database.

Different DBMSes differ in how clever their optimizer is at detecting index range scans, and accurately estimating their cost. And not all indices are B-trees. You'll have to read the docs for your specific DBMS to get the real info.

---

No. Resultant index will be single index but with compound key.

KeyX = A,B,C,D; KeyY = 1,2,3,4;

Index KeyX, KeyY will be actually: A1,A2,A3,B1,B3,C3,C4,D2

So that in case you need to find something by KeyX and KeyY - that will be fast and will use single index. Something like SELECT ... WHERE KeyX = "B" AND KeyY = 3.

But it's important to understand: WHERE KeyX = ? requests will use that index, while WHERE KeyY = ? will NOT use such index at all.

---

My understanding is, Composite indexes work just like regular indexes, except they have multi-values keys. If you define an index on the fields (a,b,c) , Since the composite index will be stored in a BinaryTree therefore, your index will work only following combinations of searches.

ABC
AB
A

For example creating a composite index for a,b and c field is equivalent to creating separate indexes for a, ab, and abc.

참고URL : https://stackoverflow.com/questions/795031/how-do-composite-indexes-work