데이터베이스 인덱스의 역할

데이터베이스 인덱스의 가장 큰 역할은 쿼리 속도를 높이는 것입니다. 데이터베이스 인덱스는 데이터베이스의 정보를 저장하는 구조입니다. 테이블의 특정 컬럼. 모든 값, 즉 인덱스는 데이터 테이블의 컬럼을 기준으로 생성됩니다.

데이터베이스 인덱스는 쿼리 속도를 높이기 위해 테이블 ​​필드에 첨부되는 식별자입니다. 나는 많은 사람들이 인덱스의 개념을 기계적으로 이해하고 인덱스를 추가하면 이익만 있을 뿐 해가 되지 않는다고 생각하는 것을 보았습니다. 여기에 이전 인덱스 연구 노트를 요약하고 싶습니다.

먼저 인덱스가 속도를 높이는 이유를 이해하십시오. DB가 Sql 문을 실행할 때 기본 방법은 검색 조건에 따라 전체 테이블 스캔을 수행하는 것입니다. , 일치하는 조건이 발견되면 검색에 참여합니다. 특정 필드에 인덱스를 추가하면 쿼리할 때 먼저 인덱스 목록에서 특정 값을 갖는 행의 개수를 찾게 되는데, 이는 탐색되는 일치하는 행의 개수를 크게 줄여 쿼리 속도를 크게 높일 수 있습니다. 그렇다면 언제든지 인덱싱을 추가해야 할까요? 다음은 몇 가지 반례입니다. 1. 매번 모든 테이블 레코드를 가져와야 하고 어쨌든 전체 테이블 스캔을 수행해야 하는 경우 인덱스를 추가할 필요가 없습니다. 2. "성별"과 같이 반복되는 값이 많고 고유하지 않은 필드의 경우 색인을 추가하는 것은 의미가 없습니다. 3. 상대적으로 레코드 수가 적은 테이블의 경우 인덱스를 추가하면 속도가 최적화되지 않고 저장 공간이 낭비됩니다. 인덱스에는 저장 공간이 필요하고 업데이트/삽입/삭제를 실행할 때마다 모든 인덱스 필드가 있어야 한다는 치명적인 단점이 있습니다. 업데이트를 위해 다시 계산됩니다.

그러면 언제 색인을 추가하는 것이 적절한가요? MySQL 매뉴얼에 제공된 예를 살펴보겠습니다. 다음은 SQL 문입니다.

SELECT c.companyID, c.companyName FROM Companies c, User u WHERE c.companyID = u.fk_companyID AND c.numEmployees >= 0 AND c .companyName LIKE '%i%' AND u.groupID IN (SELECT g.groupID FROM Groups g WHERE g.groupLabel = 'Executive')

이 문은 3개 테이블의 조인을 포함하며 크기 비교와 같은 많은 검색 조건을 포함합니다. , 매칭 등 MySQL이 인덱스 없이 수행해야 하는 스캔 행 수는 77721876개 행입니다. companyID 및 groupLabel 필드에 인덱스를 추가한 후 스캔된 행 수는 134개에 불과합니다. Mysql에서는 explain Select를 통해 스캔 횟수를 확인할 수 있습니다. 이러한 조인트 테이블과 복잡한 검색 조건의 경우 인덱스가 가져오는 성능 향상은 인덱스가 차지하는 디스크 공간보다 훨씬 더 중요하다는 것을 알 수 있습니다.

그러면 인덱스는 어떻게 구현되나요? 대부분의 DB 공급업체는 데이터 구조인 B-트리를 기반으로 인덱스를 구현합니다. B-트리의 특징은 디스크 등 직접 저장 장치에 동적 조회 테이블을 구성하는 데 적합하다는 점입니다. B-트리의 정의는 다음과 같습니다. m(m>=3) 순서의 B-트리는 다음 조건을 충족하는 m-ary 트리입니다.

1. 각 노드는 다음 범위(j, p0, k1, p1 , k2, p2, ...ki, pi) 여기서 j는 키워드 수, p는 하위 포인터

2. 모든 리프 노드는 동일한 레이어에 있으며 레이어 수는 트리 높이 h

3. 각 비 루트 노드에 포함된 키워드 수는 [m/2-1]<=j<=m-1

을 만족합니다. 4. 트리가 비어 있지 않으면 루트 루트가 리프가 아닌 경우 최소 1개의 키워드가 있는 경우 최소 2개의 하위 트리가 있고 최대 m개의 하위 트리가 있습니다.

B-트리의 예를 보면 26개의 영문자에 대한 B-트리를 구성할 수 있습니다. 이:

이 B-트리에서 영문자 검색의 복잡도는 O(m)에 불과하다는 것을 알 수 있는데, 데이터의 양이 상대적으로 클 경우 이러한 구조는 쿼리 속도를 크게 높일 수 있습니다. 그러나 B-트리보다 빠르게 쿼리를 수행하는 또 다른 데이터 구조, 즉 해시 테이블이 있습니다. 해시 테이블의 정의는 다음과 같습니다. 가능한 모든 키워드 집합을 u로 두고 실제로 저장된 키워드는 k로 표시되며 |k|는 |u|보다 훨씬 작습니다. 해싱 방법은 u를 해시 함수 h를 통해 테이블 ​​T[0,m-1]의 첨자에 매핑하여 u에 있는 키워드가 변수가 되고, h를 사용한 함수 연산의 결과가 T[0,m-1]의 저장 주소가 되도록 하는 것입니다. 해당 노드. 따라서 O(1) 시간 안에 검색을 완료할 수 있습니다.
하지만 해시 테이블에는 해시 충돌이라는 결함이 있습니다. 즉, 두 개의 키워드가 해시 함수를 통해 동일한 결과를 계산합니다. m과 n은 각각 해시 테이블의 길이를 나타내며, n/m은 해시 테이블의 채우기 요소입니다. 요소가 클수록 해시 충돌 가능성이 커집니다.
이 결함으로 인해 데이터베이스는 해시 테이블을 인덱스의 기본 구현으로 사용하지 않습니다. MySQL은 실행 쿼리 형식에 따라 디스크 기반 B-트리 인덱스를 적합한 해시 인덱스로 변환하려고 시도한다고 주장합니다. 검색 속도를 더욱 향상시킵니다. 결국 다른 데이터베이스 업체들도 비슷한 전략을 가지고 있을 것이라 생각합니다. 결국 데이터베이스 전장에서는 검색 속도와 관리 보안이 매우 중요한 경쟁력이 될 것입니다.

위 내용은 데이터베이스 인덱스의 역할의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!