MySQL의 B-트리 인덱스와 해시 인덱스의 차이점: 1. B-트리 인덱스는 가장 왼쪽 접두사 일치 원칙을 지원하지만 해시 인덱스는 이를 지원하지 않습니다. 2. MyISAM과 InnoDB는 모두 B-트리 인덱스, 해시 인덱스를 지원합니다. 메모리 및 NDB 엔진 인덱스에서만 지원됩니다.
해시 인덱스
해시 인덱스 구조가 특별하고, 검색 효율성이 매우 높으며, 루트 노드에서 접근해야 하는 B-Tree 인덱스와 달리 인덱스 검색을 한 번에 찾을 수 있습니다. 페이지 노드에는 다중 IO 액세스가 있으므로 Hash 인덱스의 쿼리 효율성은 B-Tree 인덱스보다 훨씬 높습니다.
많은 사람들이 다시 질문을 할 수 있습니다. Hash 인덱스는 B-Tree보다 훨씬 효율적인데 왜 모든 사람이 Hash 인덱스를 사용하지 않고 B-Tree 인덱스를 사용합니까? 모든 것에는 양면이 있으며 해시 인덱스도 마찬가지입니다. 해시 인덱스는 매우 효율적이지만 해시 인덱스 자체도 그 특수성으로 인해 다음과 같은 많은 제한과 단점을 가지고 있습니다.
(1) 해시 인덱스는 "=", "IN" 및 "<=>" 쿼리만 만족할 수 있으며 범위 쿼리는 사용할 수 없습니다.
해시 인덱스는 해시 연산 후 해시 값을 비교하기 때문에 등가 필터링에만 사용할 수 있고 범위 기반 필터링에는 사용할 수 없습니다. 해시 작업 전과 정확히 동일하다는 보장은 없습니다.
(2) 데이터 정렬 작업을 피하기 위해 해시 인덱스를 사용할 수 없습니다.
해시 인덱스는 해시 계산 후 해시 값을 저장하고, 해시 값의 크기 관계가 반드시 해시 연산 전 키 값과 정확히 동일할 필요는 없으므로 데이터베이스는 정렬 작업을 피하기 위해 인덱스 데이터를 사용할 수 없습니다.
(3) 부분 인덱스 키를 사용하여 해시 인덱스를 쿼리할 수 없습니다.
결합 인덱스의 경우 해시 인덱스의 해시 값을 계산할 때 해시 값을 별도로 계산하는 것이 아니라 결합된 인덱스 키를 병합한 후 함께 해시 값을 계산하므로 처음 하나 또는 여러 개를 통해 쿼리할 때 사용됩니다. 결합된 인덱스의 인덱스 키, 해시 인덱스도 활용될 수 없습니다.
(4) 해시 인덱스는 언제든지 테이블 스캔을 피할 수 없습니다.
앞서 알고 있듯이 해시 인덱스는 인덱스 키에 대해 해시 연산을 수행한 후 해시 연산 결과의 해시 값과 해당 행 포인터 정보를 해시 테이블에 저장하는 것입니다. 특정 Hash 키 값을 만족하는 레코드의 개수를 Hash 인덱스에서 직접 질의할 수 없더라도, 대신 테이블에 있는 실제 데이터에 접근하여 해당 비교를 하고 그에 따른 결과를 얻어야 한다.
(5) 해시 인덱스가 동일한 해시 값을 많이 만나더라도 성능이 반드시 B-Tree 인덱스보다 높지는 않습니다.
선택도가 낮은 인덱스 키의 경우 해시 인덱스를 생성하면 동일한 해시 값과 관련된 레코드 포인터 정보가 대량으로 존재하게 됩니다. 이런 식으로 특정 레코드를 찾는 것은 매우 번거롭고 테이블 데이터에 대한 다중 액세스를 낭비하게 되어 전반적인 성능이 저하됩니다.
B-트리 인덱스
B-트리 인덱스는 MySQL 데이터베이스에서 가장 자주 사용되는 인덱스 유형입니다. Archive 스토리지 엔진을 제외한 다른 모든 스토리지 엔진은 B-트리 인덱스를 지원합니다. 이는 MySQL뿐만 아니라 실제로 다른 많은 데이터베이스 관리 시스템에서도 B-Tree 인덱스가 주요 인덱스 유형입니다. 이는 주로 B-Tree 인덱스의 저장 구조가 데이터 검사에서 중요한 역할을 하기 때문입니다. 의 데이터베이스
Suo Zhong의 성능이 매우 좋습니다.
일반적으로 MySQL의 B-Tree 인덱스의 물리적 파일의 대부분은 Balance Tree 구조에 저장됩니다. 즉, 실제로 필요한 모든 데이터는 트리의 Leaf 노드에 저장되며 어느 곳에서나 액세스할 수 있습니다. 리프 노드(Leaf Node) 최단 경로의 길이는 정확히 동일하므로 우리는 모두 B-Tree 인덱스라고 부릅니다. 물론, 다양한 데이터베이스(또는 MySQL의 다양한 스토리지 엔진)는 자체 B-Tree를 저장할 때 스토리지 구조를 변경할 수 있습니다. 약간의 변화. 예를 들어 Innodb 스토리지 엔진의 B-Tree 인덱스가 사용하는 실제 스토리지 구조는 실제로 B+Tree인데, 이는 B-Tree 데이터 구조를 기반으로 약간의 수정이 이루어지고 각 스토리지에 스토리지가 추가된다는 의미입니다.
Leaf Node. 인덱스 키와 관련된 정보 외에도 리프 노드에 인접한 다음 LeafNode를 가리키는 포인터 정보도 저장됩니다. 이는 주로 인접한 여러 리프 노드를 검색하는 속도를 높이기 위한 것입니다. 추천 튜토리얼: "MySQL 튜토리얼"
위 내용은 MySQL에서 B-Tree 인덱스와 Hash 인덱스의 차이점은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!