【Face Jing】 데이터베이스 인덱스 (MySQL)

기사 디렉토리

인덱싱은 데이터베이스에서 데이터 쿼리 / 검색을위한 최적화 체계입니다.

1. 인덱스에서 사용하는 데이터 구조

주로 두 가지 데이터 구조가 있습니다 : 해시 인덱스 및 B + 트리 .

Mysql의 기본 InnoDB 엔진에서 기본값은 B + Tree입니다.

2. 왜 B + Tree를 사용합니까? 해시 인덱스와 비교하여 장단점이 있습니까?

해시 인덱스의 맨 아래 계층은 해시 테이블입니다. 해시 테이블은 데이터를 키-값 쌍 구조로 저장합니다. 여러 데이터는 저장 관계에서 순서 관계가 없습니다. 간격으로 쿼리 할 때 인덱스를 통해 직접 쿼리 할 수 없습니다. , 전체 테이블 스캔이 필요합니다. 따라서 해시 인덱스는 동등한 쿼리 시나리오에만 사용할 수 있습니다 . 다른 문제 : 해시 인덱스는 정렬을 완료하기 위해 인덱스를 사용할 수 없습니다 , 및 다중 열 공동 인덱스의 가장 왼쪽 일치 규칙을 지원하지 않습니다 . 해시 충돌 문제가 있습니다.
B + 트리는 다 방향 균형 검색 트리 입니다. 노드는 원래 순서가 지정되어 있으므로 범위 쿼리에 전체 테이블 스캔이 필요하지 않습니다.

3. B + 트리의 리프 노드.

B + 트리의 리프 노드는 전체 데이터 행을 저장하거나 기본 키 키의 값을 저장할 수 있습니다 .

클러스터형 인덱스 : 데이터의 물리적 저장소에 따라 나뉩니다. 레코드 묶음의 경우 클러스터형 인덱스를 사용하여 주로 물리적 저장소를 설명하는 레코드 힙을 나눕니다. 클러스터형 인덱스가 고유해야하는 것은 바로이 분할 방법 때문입니다. 클러스터형 인덱스는 큰 범위를 지정하고 범위를 빠르게 줄이는 데 도움이 될 수 있습니다. 그러나 기록을 찾으려면이 작은 영역에서 스캔해야합니다.
비 클러스터형 인덱스 : B + 트리의 리프 노드는 비 기본 키 인덱스라고도하는 기본 키의 값을 저장합니다. 비 클러스터형 인덱스는 넓은 영역을 작은지도로 변환 한 다음이 작은지도에서 찾고있는 정보의 위치를 찾아야하며 마지막으로이 위치를 통해 필요한 레코드를 찾을 수 있습니다.

데이터를 쿼리 할 때 클러스터형 인덱스는 일반적으로 비 클러스터형 인덱스보다 빠릅니다. 비 클러스터형 인덱스 쿼리 데이터는 기본 키의 값이고 데이터 테이블은 기본 키의 값을 통해 다시 쿼리해야하기 때문입니다. 이 상황이라고 불리는 테이블로 돌아갑니다 .

비 기본 키 인덱스는 수 테이블에 복귀하지 않도록 하여 인덱스를 포함하는 .

커버링 인덱스 : 쿼리 문의 실행은 데이터 테이블에서 읽지 않고 인덱스에서만 얻을 수 있습니다. 인덱스 커버리지가 달성되었다고 말할 수도 있습니다.

질의 문 실행시 인덱스에서 필요한 데이터를 얻을 수 있다면 인덱스를 찾아서 데이터 테이블로 돌아와서 운영 할 필요가 없어 I / O를 줄이고 효율성을 높일 수 있습니다.

예 :

Covering_index_sample 테이블에는 공통 인덱스 idx_key1_key2 (key1, key2)가 있습니다.

SQL 문을 사용할 때 : select key2 from covering_index_sample where key1 = 'keytest';, we can query key2 through the coverage index and return it without back to the table.

4. 조인트 인덱스, 맨 왼쪽 일치

가장 왼쪽의 매칭 원리 이기 때문에 우리는 공동 지수를 설정하는 과정에 있기 때문에 지수는 높고 낮은 빈도의 빈도 와 높고 낮은 정도의 분산 값 을 왼쪽에서 오른쪽으로 순서대로 사용함에 따라 유의해야합니다. , 인덱스가 있기 때문에 순차 스캔의 실패를 최소화 할 수 있습니다.

맨 왼쪽 일치의 원칙 : where 문의 조건은 인덱스에 의해 생성 된 필드의 순서대로 사용됩니다 (및 조건이 순서대로 작성되어야한다는 의미는 아닙니다). 열에 조건이없는 경우 middle 또는 like를 사용하면 다음 열에서 인덱스를 사용하지 않습니다.

인덱싱에 적합한 필드는 무엇입니까?
1. 쿼리를 위해 자주 선택되는 필드
2. 종종 테이블에 연결되는 필드
3. 정렬 기준, 그룹화 기준, 구별 후 자주 나타나는 필드
어떤 상황에서 인덱스 오류가 발생하고 전체 테이블 스캔이 수행됩니까?
1. "% abc %", "% __"등과 같이 맨 왼쪽에 "% (모든 문자)"가있는 LIKE 퍼지 쿼리;
2. 인덱스 필드는 OR 문 앞뒤에 동시에 사용되지 않습니다.
3. 데이터 유형의 암시 적 변환 (예 : 작은 따옴표가없는 varchar는 자동으로 int 유형으로 변환 될 수 있음)
4. 다중 열 인덱스의 경우 맨 왼쪽 일치 원칙이 충족되지 않습니다.

5. 인덱싱의 단점

주로 시간과 공간에서 고려 :

시간 : 인덱스를 만들고 유지하는 데 시간이 걸립니다. 특히 테이블에서 데이터를 추가, 삭제 및 수정할 때 인덱스도 동적으로 유지 관리되어야하므로 데이터 유지 관리 속도가 느려집니다.
공간 : 인덱스는 물리적 공간을 차지해야합니다.

6. MySql 5.6에서 인덱스 최적화

인덱스 조건 푸시 다운

MySQL 5.6은 기본적으로 활성화 된 인덱스 푸시 다운 최적화를 도입했습니다.

끄려면 SET optimizer_switch = 'index_condition_pushdown = off';를 사용합니다.

공식 문서에 제공된 예와 설명은 다음과 같습니다.

people 테이블 (zipcode, lastname, firstname)은 색인을 구성합니다.

SELECT * FROM people WHERE zipcode = '95054'AND lastname like '% etrunia %'AND address LIKE '% Main Street %';

인덱스 푸시 기술을 사용하지 않는 경우 MySQL은 zipcode = '95054'를 통해 스토리지 엔진에서 해당 데이터를 쿼리하여 MySQL 서버로 반환 한 다음 MySQL 서버는 LIKE '% etrunia %'성을 기반으로합니다. 데이터가 조건을 충족하는지 확인하기 위해 LIKE '% Main Street %'주소를 지정합니다.

인덱스 푸시 기술을 사용하는 경우 MYSQL은 먼저 zipcode = '95054'를 충족하는 인덱스를 반환 한 다음 LIKE '% etrunia %'성 및 주소 LIKE '% Main Street %를 기준으로 인덱스가 조건을 충족하는지 여부를 판단합니다. '. 조건이 충족되면 인덱스에 따라 해당 데이터를 찾고, 그렇지 않으면 직접 거부됩니다. 인덱스 푸시 다운 최적화를 사용하면 조건이 유사한 쿼리의 경우 테이블로 돌아가는 횟수를 줄일 수 있습니다.

참조 기사 :