(1) 쿼리 효율성 향상(IO 사용량 감소)
(2) CPU 사용량 감소
예를 들어 B+ 인덱스 트리 자체가 순위는 좋은 순서이므로 다시 쿼리하고 인덱스를 트리거하면 다시 쿼리할 필요가 없습니다.
(1) 인덱스 자체가 커서 메모리나 하드디스크에 저장이 가능하며, 보통 하드디스크에 저장됩니다.
(2) 인덱스는 ① 적은 양의 데이터 ② 자주 변경되는 필드 ③ 거의 사용되지 않는 필드 등 모든 상황에서 사용되지는 않습니다.
(3) 인덱스는 추가, 삭제, 수정의 효율성을 떨어뜨립니다
(1) 단일 값 인덱스
(2) 고유 인덱스
(3) 통합 인덱스
(4) 기본 키 인덱스
참고: 고유 인덱스와 기본 키 인덱스의 유일한 차이점은 기본 키입니다. index는 null일 수 없습니다.
alter table user add INDEX `user_index_username_password` (`username`,`password`)
MySQL 인덱스의 기본 데이터 구조는 B+ 트리입니다.
B+Tree는 다음을 기반으로 합니다. B-Tree는 외부 스토리지 인덱스 구조를 구현하는 데 더 적합하게 만들며 InnoDB 스토리지 엔진은 B+Tree를 사용하여 인덱스 구조를 구현합니다.
B-Tree 구조 다이어그램의 각 노드에는 데이터의 키 값뿐만 아니라 데이터 값도 포함됩니다. 각 페이지의 저장 공간은 제한되어 있으며, 데이터 데이터가 크면 각 노드(즉, 한 페이지)에 저장할 수 있는 키의 수가 매우 적습니다. B - Tree의 깊이가 커져 쿼리 중 디스크 I/O 수가 증가하여 쿼리 효율성에 영향을 미칩니다. B+Tree에서는 모든 데이터 레코드 노드가 키 값 순서로 동일한 레이어의 리프 노드에 저장되며, 리프가 아닌 노드에는 키 값 정보만 저장되므로 각 노드에 저장되는 키 값의 수가 크게 늘어날 수 있습니다. node.B+Tree의 높이를 줄입니다.
B+Tree는 B-Tree와 비교하여 몇 가지 차이점이 있습니다.
Non-leaf 노드는 키 값 정보만 저장합니다.
모든 리프 노드 사이에는 링크 포인터가 있습니다.
데이터 레코드는 리프 노드에 저장됩니다.
이전 섹션에서 B-Tree를 최적화합니다. B+Tree의 리프가 아닌 노드는 키 값 정보만 저장하므로 각 디스크 블록이 4개의 키 값과 포인터 정보를 저장할 수 있다고 가정하면 B의 구조가 됩니다. +Tree. 아래 그림과 같이:
일반적으로 B+Tree에는 두 개의 헤드 포인터가 있습니다. 하나는 루트 노드를 가리키고 다른 하나는 가장 작은 키워드가 있는 리프 노드를 가리키며 종류가 있습니다. 모든 리프 노드(즉, 데이터 노드) 간의 관계. 따라서 B+Tree에서는 두 가지 검색 작업을 수행할 수 있습니다. 하나는 기본 키에 대한 범위 검색 및 페이징 검색이고, 다른 하나는 루트 노드에서 시작하는 무작위 검색입니다.
위 예에는 데이터 레코드가 22개만 있을 수 있으며 B+Tree의 장점을 볼 수 없습니다. 계산은 다음과 같습니다.
InnoDB 스토리지 엔진의 페이지 크기는 16KB이고 기본 키 유형은 일반 테이블은 INT(4워드 점유) 섹션) 또는 BIGINT(8바이트 점유)이며 포인터 유형은 일반적으로 4 또는 8바이트입니다. 즉, 페이지(B+Tree의 노드)는 약 16KB/(8B+8B)를 저장합니다. )=1K 키값(추정이므로 계산의 편의를 위해 여기서 K값은 〖10〗^3)입니다. 즉, 깊이가 3인 B+Tree 인덱스는 10^3 * 10^3 * 10^3 = 10억 개의 레코드를 유지할 수 있습니다.
실제 상황에서는 각 노드가 완전히 채워지지 않을 수 있으므로 데이터베이스에서 B+Tree의 높이는 일반적으로 2~4레이어입니다. MySQL의 InnoDB 스토리지 엔진은 루트 노드가 메모리에 상주하도록 설계되었습니다. 즉, 특정 키 값의 행 레코드를 찾는 데 1~3회의 디스크 I/O 작업만 필요하다는 의미입니다.
데이터베이스의 B+Tree 인덱스는 클러스터형 인덱스와 보조 인덱스로 나눌 수 있습니다. 위의 B+Tree 예시 다이어그램은 클러스터형 인덱스로 데이터베이스에 구현되어 있으며, 클러스터형 인덱스의 B+Tree에 있는 리프 노드에는 테이블 전체의 행 레코드 데이터가 저장됩니다. 보조 인덱스와 클러스터형 인덱스의 차이점은 보조 인덱스의 리프 노드에는 행 레코드의 모든 데이터가 포함되어 있는 것이 아니라 해당 행 데이터를 저장하는 클러스터형 인덱스 키, 즉 기본 키가 포함된다는 점입니다. 보조 인덱스를 통해 데이터를 쿼리할 때 InnoDB 스토리지 엔진은 보조 인덱스를 순회하여 기본 키를 찾은 다음 기본 키를 통해 클러스터형 인덱스에서 전체 행 레코드 데이터를 찾습니다.
위 내용은 MySQL에서 인덱스의 용도는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!