데이터베이스 인덱스

데이터베이스 인덱스는 인덱스 데이터 구조를 유지하기 위해 추가 쓰기 및 저장 공간을 희생하면서 데이터베이스 테이블의 데이터 검색 작업 속도를 향상시키는 데이터 구조입니다.인덱스는 데이터베이스 테이블에 액세스할 때마다 데이터베이스 테이블의 모든 행을 검색할 필요 없이 데이터를 빠르게 찾는 데 사용됩니다.인덱스는 데이터베이스 테이블의 하나 이상의 열을 사용하여 생성할 수 있으며, 빠른 랜덤 검색과 순서가 지정된 레코드의 효율적인 액세스를 위한 기반을 제공합니다.

인덱스는 테이블에서 선택한 데이터 열의 복사본으로, 매우 효율적인 검색이 가능하도록 설계되었습니다.인덱스는 일반적으로 전체 행을 효율적으로 검색할 수 있도록 복사된 원래 데이터 행에 대한 "키" 또는 직접 링크를 포함합니다.일부 데이터베이스는 개발자가 함수 또는 식에 의해 변환된 열 값에 대한 색인을 작성할 수 있도록 하여 색인 작성 기능을 확장합니다.예를 들어 인덱스를 생성할 수 있습니다.upper(last_name)의 대문자 버전만 저장됩니다.last_name필드를 선택합니다.때때로 지원되는 또 다른 옵션은 부분 인덱스를 사용하는 것입니다. 여기서 인덱스 엔트리는 일부 조건식을 충족하는 레코드에 대해서만 생성됩니다.유연성의 또 다른 측면은 사용자 정의 함수와 임베디드 함수의 집합에서 형성된 표현식에 대한 인덱싱을 허용하는 것입니다.

사용.

고속 검색 지원

대규모 데이터베이스에서는 선형 검색이 비효율적이기 때문에 대부분의 데이터베이스 소프트웨어에는 하위 선형 시간 검색을 통해 성능을 향상시킬 수 있는 인덱싱 기술이 포함되어 있습니다.

데이터베이스에 N개의 데이터 항목이 포함되어 있고 필드 중 하나의 값을 기준으로 데이터를 검색해야 한다고 가정합니다.간단한 구현은 테스트에 따라 각 항목을 검색하고 검사합니다.일치하는 항목이 하나만 있는 경우 해당 항목이 발견되면 이 작업이 중지될 수 있지만 일치하는 항목이 여러 개 있는 경우 모든 항목을 테스트해야 합니다.즉, 평균적인 경우 연산 횟수가 O(N) 또는 선형 시간임을 의미합니다.데이터베이스에는 많은 오브젝트가 포함되어 있을 수 있으며 룩업은 일반적인 작업이기 때문에 성능을 향상시키는 것이 좋습니다.

인덱스는 조회 성능을 향상시키는 데이터 구조입니다.이 목적을 위해 사용되는 다양한 데이터 구조가 있습니다.룩업 성능, 인덱스 크기 및 인덱스 업데이트 성능과 관련된 복잡한 설계 트레이드오프가 있습니다.많은 인덱스 설계는 로그(O(log(N)) 검색 성능을 나타내며, 일부 애플리케이션에서는 플랫(O(1)) 성능을 달성할 수 있습니다.

데이터베이스 제약 조건의 폴리싱

인덱스는 UNIKE, EXCLUMTION, PRIMAY KEY 및 FORNE KEY와 같은 데이터베이스 제약 조건을 폴리싱하는 데 사용됩니다.인덱스는 UNIQURE로 선언될 수 있으며, 이로 인해 기본 테이블에 암묵적인 제약 조건이 생성됩니다.데이터베이스 시스템은 일반적으로 PRIMAY KEY로 선언된 열 집합에 인덱스를 암묵적으로 작성합니다.또한 기존 인덱스를 사용하여 이 제약을 폴리싱할 수도 있습니다.많은 데이터베이스 시스템은 FORENAL KEY 제약조건의 참조 및 참조 열 세트를 모두 인덱싱해야 하므로 제약조건에 참여하는 테이블에 대한 삽입, 업데이트 및 삭제 성능이 향상됩니다.

일부 데이터베이스 시스템은 새로 삽입되거나 업데이트된 레코드에 대해 특정 술어가 다른 레코드에 대해 유지되지 않도록 하는 제외 제약 조건을 지원합니다.이는 중복되는 시간 범위나 교차하는 지오메트리 개체가 테이블에 저장되지 않도록 하는 등 고유 제약 조건(등식 술어 포함) 또는 더 복잡한 제약 조건을 구현하기 위해 사용할 수 있습니다.이러한 ^[1]제약조건을 폴리싱하기 위해서는 술어를 만족시키는 레코드의 신속한 검색을 지원하는 인덱스가 필요하다.

인덱스 아키텍처 및 인덱싱 방법

비클러스터화

데이터는 임의 순서로 표시되지만 논리적 순서는 인덱스로 지정됩니다.데이터 행은 색인화된 열 또는 식 값에 관계없이 테이블 전체에 분산될 수 있습니다.비클러스터형 인덱스 트리에는 인덱스 키가 정렬된 순서대로 포함되어 있으며 인덱스의 리프 레벨에는 레코드에 대한 포인터가 포함됩니다(페이지 구성 엔진의 데이터 페이지의 페이지 및 행 번호, 파일 구성 엔진의 행 오프셋).

비클러스터형 색인에서는

• 행의 실제 순서가 인덱스 순서와 동일하지 않습니다.
• 인덱스된 열은 일반적으로 JOIN, WHERE 및 ORDER BY 절에서 사용되는 비프라이머리 키열입니다.

데이터베이스 테이블에 둘 이상의 비클러스터 인덱스가 있을 수 있습니다.

클러스터화

클러스터링은 데이터 블록을 인덱스와 일치하도록 특정 고유한 순서로 변경하므로 행 데이터가 순서대로 저장됩니다.따라서 특정 데이터베이스 테이블에는 클러스터된 인덱스를 하나만 작성할 수 있습니다.클러스터된 인덱스는 전체 검색 속도를 크게 높일 수 있지만, 일반적으로 클러스터된 인덱스와 동일한 순서 또는 역순으로 데이터에 순차적으로 액세스하거나 항목 범위를 선택할 때만 해당됩니다.

실제 레코드는 디스크에서 이 정렬 순서이므로 시퀀스의 다음 행 항목은 마지막 행의 바로 앞 또는 뒤에 있으므로 필요한 데이터 블록 읽기가 줄어듭니다.따라서 클러스터된 인덱스의 주요 기능은 실제 데이터 행을 가리키는 인덱스 블록에 따라 정렬하는 것입니다.일부 데이터베이스는 데이터 블록과 인덱스 블록을 별도의 파일로 구분하고, 다른 데이터베이스는 동일한 물리적 파일 내에 완전히 다른 두 개의 데이터 블록을 배치합니다.

클러스터

여러 데이터베이스와 여러 테이블이 결합된 경우 클러스터라고 합니다(앞에서 설명한 클러스터된 인덱스와 혼동하지 마십시오).클러스터 키의 값을 공유하는 테이블에 대한 기록은 동일한 데이터 블록 또는 가까운 데이터 블록에 함께 저장해야 한다.그러면 일치하는 레코드가 함께 저장되고 찾는 ^[2]데 필요한 I/O가 줄어들기 때문에 클러스터 키에서 이러한 테이블의 결합이 개선될 수 있습니다.클러스터 구성은 클러스터의 일부인 테이블의 데이터 레이아웃을 정의합니다.클러스터는 B-Tree 인덱스 또는 해시 테이블을 사용하여 키를 지정할 수 있습니다.테이블 레코드가 저장되는 데이터 블록은 클러스터 키의 값에 의해 정의됩니다.

열순서

인덱스 정의가 열을 정의하는 순서가 중요합니다.첫 번째 인덱스된 열만 사용하여 행 식별자 집합을 검색할 수 있습니다.그러나 대부분의 데이터베이스에서 두 번째 이상의 색인 열만 사용하여 행 식별자 집합을 검색하는 것은 불가능하거나 효율적이지 않습니다.

예를 들어, 도시별로 먼저 정리된 전화번호부, 그 다음에 성별로 정리된 전화번호부, 그리고 그 다음에 이름으로 특정 도시에서 쉽게 모든 전화번호 목록을 추출할 수 있다.그러나 특정 성의 모든 전화번호를 찾는 것은 매우 번거로운 일입니다.그 성을 가진 출품작들은 각 도시의 구역 내에서 찾아봐야 할 것이다.일부 데이터베이스는 이 작업을 수행하지만 다른 데이터베이스는 색인을 사용하지 않습니다.

컬럼에 컴포지트인덱스가 작성되어 있는 전화번호부의 예(city, last_name, first_name)) 3개의 필드 모두에 대해 정확한 값을 지정하여 검색하면 검색 시간은 최소화되지만 값을 지정하면city그리고.first_name이 검색에서는 다음 명령어만 사용됩니다.city일치하는 레코드를 모두 가져옵니다.그런 다음 순차적 조회는 다음과 같이 일치 여부를 확인합니다.first_name따라서 성능을 향상시키려면 검색란 순서대로 인덱스를 생성해야 합니다.

응용 프로그램 및 제한 사항

인덱스는 많은 응용 프로그램에 유용하지만 몇 가지 제한이 있습니다.다음 SQL 문을 고려하십시오.SELECT first_name FROM people WHERE last_name = 'Smith';. 인덱스를 사용하지 않고 이 문을 처리하려면 데이터베이스 소프트웨어는 테이블의 모든 행에 있는 last_name 열을 확인해야 합니다(이 열을 전체 테이블 스캔이라고 합니다).인덱스를 사용하면 데이터베이스는 Smith 엔트리가 발견될 때까지 인덱스 데이터 구조(일반적으로 B-트리)를 따를 뿐입니다.이것은 전체 테이블 스캔보다 계산 비용이 훨씬 적게 듭니다.

다음 SQL 문을 고려하십시오.SELECT email_address FROM customers WHERE email_address LIKE '%@wikipedia.org';이 쿼리는 이메일 주소가 "@wikipedia.org"로 끝나는 모든 고객에 대해 이메일 주소를 생성하지만 email_address 열이 인덱싱되어 있더라도 데이터베이스는 전체 인덱스 검사를 수행해야 합니다.이는 단어가 왼쪽에서 오른쪽으로 간다는 가정 하에 인덱스가 작성되기 때문입니다.검색어 선두에 와일드카드를 사용하면 데이터베이스 소프트웨어는 기본 인덱스 데이터 구조를 사용할 수 없습니다(즉, WHERE-clause는 sargable할 수 없습니다).이 문제는 다음에 작성된 다른 인덱스를 추가함으로써 해결할 수 있습니다.reverse(email_address)SQL 쿼리는 다음과 같습니다.SELECT email_address FROM customers WHERE reverse(email_address) LIKE reverse('%@wikipedia.org');그러면 와일드카드가 쿼리 오른쪽 끝(현재의 gro.aidepikiw@%)에 배치되어 리버스(email_address)의 인덱스가 충족할 수 있습니다.

와일드카드 문자가 검색어 양쪽에 %wikipedia.org%로 사용되는 경우 이 필드에서 사용할 수 있는 인덱스는 사용되지 않습니다.오히려 O(N) 시간이 걸리는 순차 검색만 수행됩니다.

인덱스 유형

비트맵 인덱스

비트맵 인덱스는 데이터의 대부분을 비트 배열(비트맵)로 저장하고 이러한 비트맵에 대해 비트 논리 연산을 수행하여 대부분의 쿼리에 응답하는 특수한 인덱스입니다.B+ 트리와 같이 가장 일반적으로 사용되는 인덱스는 인덱스의 값이 몇 번 반복되지 않거나 반복되지 않는 경우에 가장 효율적입니다.반면 비트맵 인덱스는 변수의 값이 매우 자주 반복되는 경우를 위해 설계되었습니다.예를 들어, 고객 데이터베이스의 성별 필드에는 일반적으로 남성, 여성 또는 알 수 없는(기록되지 않음) 세 가지 값만 포함됩니다.이러한 변수의 경우 비트맵 인덱스는 일반적으로 사용되는 트리보다 성능이 크게 향상될 수 있습니다.

조밀 지수

데이터베이스의 고밀도 인덱스는 데이터 파일의 모든 레코드에 대한 키와 포인터 쌍이 있는 파일입니다.이 파일의 모든 키는 정렬된 데이터 파일의 레코드에 대한 특정 포인터와 관련지어집니다.중복된 키가 있는 클러스터된 인덱스의 경우 고밀도 인덱스는 해당 ^[3]키가 있는 첫 번째 레코드를 가리킵니다.

스파스 인덱스

데이터베이스의 스파스 인덱스는 데이터 파일의 모든 블록에 대한 키와 포인터 쌍이 있는 파일입니다.이 파일의 모든 키는 정렬된 데이터 파일의 블록에 대한 특정 포인터와 연결됩니다.중복 키가 있는 클러스터된 인덱스에서 스파스 인덱스는 각 블록에서 가장 낮은 검색 키를 가리킵니다.

역색인

반전 키 인덱스는 키 값을 인덱스에 입력하기 전에 반전합니다. 예를 들어, 값 24538은 인덱스에서 83542가 됩니다.키 값을 반전시키는 것은 시퀀스 번호와 같은 새로운 키 값이 단조롭게 증가하는 데이터를 인덱싱하는 데 특히 유용합니다.

프라이머리 인덱스

프라이머리 인덱스에는 테이블의 키필드와 테이블의 비키필드에 대한 포인터가 포함됩니다.기본 색인은 테이블이 데이터베이스에 작성될 때 자동으로 작성됩니다.

이차 지수

이 명령어는 필드 순서도 키 필드 순서도 아닌 필드의 인덱스에 사용됩니다(파일이 키 필드 또는 프라이머리 키 필드에 정리되어 있는 것은 아닙니다).데이터 파일의 각 태플에 대해 하나의 인덱스 항목(밀도 인덱스)에는 인덱스된 속성의 값과 블록 또는 레코드에 대한 포인터가 포함됩니다.

해시 인덱스

인덱스 실장

인덱스는 다양한 데이터 구조를 사용하여 구현할 수 있습니다.인기 지수로는 균형 나무, B+ 나무, ^[4]해시가 있습니다.

Microsoft SQL Server에서 클러스터된 인덱스의 리프 노드는 비클러스터된 ^[5]인덱스의 경우와 같이 단순히 다른 곳에 있는 데이터에 대한 포인터가 아니라 실제 데이터에 해당합니다.각 관계에는 단일 클러스터된 인덱스와 여러 클러스터되지 않은 ^[6]인덱스가 있을 수 있습니다.

인덱스 동시성 제어

인덱스는 일반적으로 여러 트랜잭션 및 프로세스에서 동시에 액세스되므로 동시성 제어가 필요합니다.인덱스는 원칙적으로 공통 데이터베이스 동시성 제어 방법을 사용할 수 있지만, 상당한 성능 향상을 위해 공통 방법과 함께 적용되는 인덱스에 대한 특수한 동시성 제어 방법이 있습니다.

피복지수

대부분의 경우 인덱스는 필요한 데이터를 읽을 수 있는 데이터 레코드를 빠르게 찾기 위해 사용됩니다.즉, 인덱스는 테이블에서 데이터 레코드를 찾는 데만 사용되며 데이터를 반환하는 데는 사용되지 않습니다.

커버링 인덱스는 인덱스 자체에 필수 데이터 필드가 포함되어 필수 데이터에 응답할 수 있는 특수한 경우입니다.

다음 표를 참조하십시오(기타 필드 생략).

아이디	이름.	기타 필드
12	플러그	...
13	램프	...
14	녹이다	...

ID 13의 이름을 찾으려면 (ID)의 인덱스가 유용하지만 이름을 얻으려면 레코드를 읽어야 합니다.그러나 (ID, 이름)의 인덱스는 필수 데이터 필드를 포함하므로 레코드를 조회할 필요가 없습니다.

커버링 인덱스는 각각 특정 테이블에 대한 것입니다.여러 테이블에 걸쳐 JOIN/액세스하는 쿼리는 이러한 테이블 ^[7]중 하나 이상의 인덱스를 포함할 수 있습니다.

커버링 인덱스는 데이터 검색 속도를 크게 높일 수 있지만 추가 키로 인해 데이터 삽입 및 업데이트 속도가 느려지기 때문에 데이터 검색 자체가 커질 수 있습니다.이러한 인덱스 크기를 줄이기 위해 일부 시스템에서는 인덱스에 키가 아닌 필드를 포함할 수 있습니다.비키 필드는 그 자체가 지수 순서의 일부가 아니라 리프 수준에서만 포함되므로 전체 지수 크기가 적은 커버링 지수를 사용할 수 있다.

표준화

ISO SQL 표준은 물리적 측면을 다루지 않기 때문에 인덱스 작성 방법을 정의하는 표준은 없습니다.인덱스는 스토리지(테이블 스페이스 또는 파일 그룹)와 같은 데이터베이스 개념의 물리적 부분 중 하나입니다.RDBMS 벤더는 모두 CREATE INDEX 구문에 소프트웨어 기능에 따라 다른 특정 옵션을 제공합니다.

「 」를 참조해 주세요.

• 인덱스 잠금
• 색인(검색 엔진)
• 반전 지수

레퍼런스