MySQL 인덱스 (고급)

MySQL 색인

I. 개요

MySQL의 공식 정의
지수는 다음과 같습니다 지수 (인덱스)는 인 데이터 구조 (주문) 를 효율적으로 데이터를 얻을 MySQL을하는 데 도움이 . 데이터 외에도 데이터베이스 시스템은 특정 검색 알고리즘을 충족하는 데이터 구조를 유지합니다. 이러한 데이터 구조는 특정 방식으로 데이터를 참조 (지시) 하므로 이러한 데이터 구조에서 고급 검색 알고리즘을 구현할 수 있습니다.이 데이터 구조는 색인 .. 다음 개략도에서 볼 수있는 바와 같이 :
보충 지식 : 이진 트리 스토리지 노드의 특정 사항은 왼쪽에 작고 오른쪽은 크게 둡니다. 노드 데이터보다 작은 것은 왼쪽에 배치하고 노드 데이터보다 큰 것은 오른쪽에 배치합니다. .
예를 들어, 쿼리 데이터 셋을 찾기 위해 전체 텍스트 검색을 필요로하지만 3 인덱싱 후 데이터를 찾으려면, 당신은 단지 그것을 찾기 위해 3 번 검색해야합니다. 그런 다음 인덱스가 해당 데이터를 찾을 않는 방법?에 나타낸 바와 같이 그림은 참조로 데이터를 가리 킵니다.

왼쪽에는 데이터 테이블이 있습니다. 7 개의 레코드로 구성된 두 개의 열이 있습니다. 가장 왼쪽은 데이터 레코드의 물리적 주소입니다 (논리적으로 인접한 레코드가 디스크에서 반드시 물리적으로 인접 할 필요는 없음). Col2 검색 속도를 높이기 위해 오른쪽과 같은 이진 검색 트리를 유지할 수 있습니다. 각 노드에는 인덱스 키와 해당 데이터 레코드의 물리적 주소에 대한 포인터가 포함되어있어 해당 데이터를 빠르게 찾을 수 있습니다. 이진 검색을 사용하여 얻은.

일반적으로 인덱스 자체도 매우 커서 메모리에 모두 저장할 수 없기 때문에 인덱스 파일 형태로 디스크에 저장되는 경우가 많다. 인덱스는 성능 향상을 위해 데이터베이스에서 사용되는 가장 일반적인 도구입니다.

두 인덱스 구조

1 인덱스 구조

인덱스는 서버 계층이 아닌 MySQL의 스토리지 엔진 계층 에서 구현됩니다 . 따라서 각 스토리지 엔진의 인덱스가 반드시 동일 할 필요는 없으며 모든 스토리지 엔진이 모든 인덱스 유형을 지원하는 것은 아닙니다. MySQL은 현재 다음과 같은 네 가지 인덱스를 제공합니다.

(1) BTREE 인덱스 : 가장 일반적인 인덱스 유형으로 대부분의 인덱스는 B- 트리 인덱스를 지원합니다.

(2) HASH 인덱스 : 간단한 사용 시나리오와 함께 메모리 엔진에서만 지원됩니다.

(3) R-tree 인덱스 (공간 인덱스) : 공간 인덱스는 MyISAM 엔진의 특수 인덱스 유형으로 주로 공간 데이터 유형에 사용되며 일반적으로 덜 사용되며 특별히 도입되지 않을 것입니다.

(4) 전체 텍스트 (전체 텍스트 인덱스) : 전체 텍스트 인덱스는 전체 텍스트 인덱스에 주로 사용되는 MyISAM의 특수 인덱스 유형이기도합니다 .InnoDB는 Mysql5.6 버전에서 전체 텍스트 인덱스를 지원합니다.

다양한 유형의 인덱스에 대한 MyISAM, InnoDB, 메모리 3 가지 스토리지 엔진 지원

우리가 일반적으로 언급 하는 인덱스는 달리 지정하지 않는 한 B + 트리 (반드시 이진이 아닌 다중 검색 트리) 구조로 구성된 인덱스를 참조합니다 . 그중 클러스터형 인덱스, 복합 인덱스, 접두사 인덱스 및 고유 인덱스는 모두 기본적으로 인덱스라고하는 B + 트리 인덱스를 사용합니다.

2 인덱스 장점과 단점

이점

1) 책의 카탈로그 색인과 유사하게 데이터 검색의 효율성을 높이고 데이터베이스의 IO 비용을 줄입니다.

2) 인덱스 열별로 데이터를 정렬하고 데이터 정렬 비용을 줄이고 CPU 소비를 줄입니다.

불리

1) 실제로 인덱스도 테이블이고 기본 키 및 인덱스 필드가 테이블에 저장되고 엔티티 클래스의 레코드를 가리 키므로 인덱스 열도 공간을 차지합니다.

2) 인덱스는 쿼리 효율성을 크게 향상 시키지만 테이블에 대한 INSERT, UPDATE, DELETE와 같은 테이블 업데이트 속도도 감소시킵니다. 테이블을 업데이트 할 때 MySQL은 데이터를 저장할뿐만 아니라 인덱스 열 필드를 추가하기 위해 인덱스 파일이 업데이트 될 때마다 인덱스 파일도 저장하므로 업데이트로 인한 키 값 변경 후 인덱스 정보를 조정합니다.

세 가지 BTREE 구조 및 데모 프로세스

Btree는 multi-way 균형 검색 트리라고도합니다 .m-forked Btree에는 다음과 같은 특성이 있습니다.
(1) 트리의 각 노드에는 최대 m 개의 자식이 포함됩니다.
(2) 루트 노드와 리프 노드를 제외하고 각 노드는 최소 [ceil (M / 2)] 하위
노드 (3) 루트 노드가 리프 노드가 아닌 경우 최소 2 개의 하위
노드가 있습니다. (4) 모든 리프 노드가 동일한 레이어에 있습니다.
(5) 각 비 리프 노드에는 n이 있습니다. 키 및 n + 1 포인터 구성, 여기서 [ceil (m / 2) -1] <= n <= m-1, n> m-1 일 때 중간 노드는 상위 노드로 분할되고 두 노드는 하위 노드로 분할됩니다. . 노드
도면에 도시 된 바와 같이, 예로서 5 점 수를 보자
번호 키 : 2 <= N <= 4 일 때 N> 4, 중간 노드는 부모 노드로 분할하고, 양쪽의 노드는 하위 노드로 분할됩니다.
데이터는 CNGAHEKQMFWLTZDPRXYS입니다.

MySQL의 4 개의 B + Tree 및 B + Tree 구조

(1) B + Tree는 BTree의 변형으로 두 가지의 차이점은 다음과 같습니다 :
① n 개의 fork B + Tree는 최대 n 개의 키를 포함하고 BTree는 최대 n-1 개의 키를 포함합니다.
② 리프 노드 of B + Tree는 모든 키 정보를 저장합니다., 키 크기 순으로 정렬
③ 키로 간주 할 수있는 모든 비 리프 노드의 인덱스 부분
B + Tree의 구조도 는 다음과 같습니다.

(2) MySQL 인덱스 데이터 구조는 기존 B + Tree를 최적화하여 인접 리프 노드에 연결된 목록 포인터를 추가하고 순차 포인터가있는 B + Tree를 형성하여 간격의 액세스 성능을 향상시킵니다.
MySQL의 B + Tree 구조에 대한 개략도 :

5 가지 인덱스 분류

(1) 단일 값 인덱스 : 즉, 인덱스에는 단일 열만 포함되고 테이블에는 단일 열 인덱스가 여러 개있을 수 없습니다.
(2) 고유 인덱스 : 인덱스 열의 값은 고유해야하지만 제어가 허용됩니다. 휴대폰 번호, 은행 카드 번호 등과 같은 고유해야합니다.
(3) 복합 인덱스 : 즉, 인덱스에는 휴대폰 번호 및 은행 카드 번호와 같은 여러 열이 포함되어 있습니다. 테이블의 데이터에 여러 필드가있는 경우 쿼리 할 때 항상 동시에 표시되는이 필드는 복합 색인으로 사용할 수 있습니다.

여섯 가지 색인 구문

1 색인 생성

(1) 문법

CREATE [UNIQUE | FULLTEXT | SPATIAL] INDEX index name
[USING index type] 인덱스
를 생성 할 테이블 이름 (인덱스를 생성 할 필드)

(2) 케이스

createt index idx_city_name on city(city_name);

2 색인보기

(1) 문법

인덱스의 테이블 이름을 생성하려면 SHOW INDEX FORM;

(2) 케이스

show index from city;

3 색인 삭제

(1) 문법

DROP INDEX 인덱스 이름 ON 테이블 이름;

(2) 케이스

drop index idx_city_name on city;

4 인덱스를 만드는 ALTER 명령

(1) 문법

① 테이블 테이블 이름 변경 기본 키 (필드) 추가, 기본 키 인덱스 추가, 고유해야하며 null 일 수 없음
② 테이블 테이블 이름 변경 고유 인덱스 이름 (필드) 추가, 고유 인덱스는 null 일 수 있음
③ 테이블 테이블 이름 변경 인덱스 추가 인덱스 이름 (필드), 일반 인덱스 추가, 여러 번 나타날 수 있음
④ 테이블 테이블 이름 변경 전체 텍스트 인덱스 이름 (필드) 추가, 전체 텍스트 인덱스 추가

5 인덱스 사용

(1) Full-value 매칭
인덱스의 모든 컬럼에 대한 특정 포인터를 지정하면 인덱스가 적용되고 실행 효율이 높습니다.

(2) 맨 왼쪽 접두사 규칙 (계단 오르기)
인덱스가 여러 열을 도입하는 경우 맨 왼쪽 접두사 규칙을 준수해야합니다. 쿼리는 인덱스의 맨 왼쪽 열부터 시작하여 인덱스 된 열 즉, 열을 건너 뛰지 않습니다. 인덱스 왼쪽에 포함되어 있습니다 (1 층 계단과 유사).

(3) select *를 피하고 테이블로 돌아가는 쿼리를 생성하려면 커버링 인덱스 (인덱스 열의 필드 만 포함)를 사용하십시오.

추가 포인트 :

using index : 커버링 인덱스를 사용할 때 나타납니다.
using where : 인덱스를 조회
하고 사용할 때 데이터를 쿼리하기 위해 테이블로 돌아 가야합니다. 인덱스 조건을 사용하여 : 인덱스를 검색하고 사용하려면 다음으로 돌아 가야합니다.
인덱스를 사용 하여 데이터를 쿼리하는 테이블 ; using where : 인덱스를 검색하고 사용하지만 필요한 데이터는 인덱스 열에서 찾을 수 있습니다. 그렇지 않으면 테이블 쿼리로 돌아갑니다.

6 인덱스 실패

(1) 범위 쿼리, 오른쪽 열 인덱스가 잘못되었습니다.

(2) 색인 열에서 산술 연산을 사용합니다. 색인이 유효하지 않습니다.

(3) 문자열 유형이 작은 따옴표를 추가하지 않거나 색인이 유효하지

않거나 (4) 색인이 유효하지 않습니다

(5) "** % ** 조건"과 같이 인덱스 무효화

모호성을 해결하기 위해 커버링 인덱스를 사용합니다. 인덱스 실패 문제

(6) null 및 is null 인덱스는 때때로 실패하고 때로는 실패합니다. 주로 테이블 데이터를 확인합니다. 대부분의 데이터 볼륨에 값이 있으면 null입니다. 인덱스로 이동합니다. 대부분이 null이면 go is null index
(7) in take index, not in index is invalid

7 가지 인덱스 디자인 원칙

(1) 쿼리 빈도가 높고 데이터가 많은 테이블을 인덱싱합니다.
(2) where 절의 조건에서 인덱스 필드의 가장 적합한 후보 열을 얻습니다. where 절에 조합이 많으면 common을 선택하고, 필터링 효과가 가장 좋은 컬럼의 조합이 복합 인덱스가됩니다.
(3) 고유 인덱스를 사용합니다. 차별도가 높을수록 인덱스 사용 효율성이 높아집니다.
(4) 인덱스가 좋지 않을수록 좋습니다. 인덱스, 삽입, 업데이트 및 삭제와 같은 해당 DML. 자주 작동하는 테이블의 경우 유지 관리 비용이 증가하고 DML 작업의 효율성이 떨어집니다.
(5) 짧은 인덱스를 사용합니다. 인덱스 생성 후 하드 디스크를 저장 용으로 사용합니다. 인덱스 액세스의 IO 효율성을 높이면 전체 액세스 효율성이 향상 될 수 있습니다. 인덱스 필드가 상대적으로 짧아서 주어진 스토리지 블록 크기 더 많은 인덱스 값을 저장할 수 있습니다. IO에 대한 mysql 액세스의 효율성을 향상시킵니다.
(6) 맨 왼쪽 접두사를 사용하면 N 개의 컬럼으로 구성된 복합 인덱스는 N 개의 인덱스를 생성하는 것과 동일하며 where 절에서 복합 인덱스의 필드를 사용하면 쿼리 효율성이 향상됩니다.
예 :

创建复合索引：
create index idx_name_email_status on tb_seller(name,email,status);
相当于：
	对name创建索引；
	对name，email创建索引；
	对name，email，Status创建索引；