Mysql 인덱스의 데이터 구조
목차
1.2.1. MyISAM (데이터와 인덱스가 함께 있지 않아 클러스터되지 않은 인덱스이기 때문)
1.2.2 InnoDB (인덱스와 데이터가 함께 있기 때문에 클러스터형 인덱스라고도 함)
1. 색인
인덱스는 MySQL이 데이터를 효율적으로 가져 오는 데 도움이되는 정렬 된 데이터 구조입니다.
1.1. 데이터 구조
1.1.1. 바이너리 트리
이진 트리는 중요한 트리 구조 유형입니다. 많은 실제 문제에서 추상화 된 데이터 구조는 종종 이진 트리 형태이며, 일반 트리도 쉽게 이진 트리로 변환 할 수 있으며, 이진 트리의 저장 구조 및 알고리즘이 비교적 단순하여 이진 트리는 다음과 같습니다. 특히 중요합니다. 이진 트리의 특징은 각 노드가 최대 2 개의 하위 트리 만 가질 수 있고 왼쪽 및 오른쪽 하위 트리가 있다는 것입니다.
먼저 실제 문제에 따라 분석하십시오.
인덱스 SQL 문 쿼리를 사용하지 않았을 때 다음과 같습니다.
select * from table where Col2 = 23간단한 SQL 쿼리에는 7 개의 디스크 IO 작업 (하나씩 하향 쿼리)이 필요하며 이는 의심 할 여지없이이 문제를 해결하기 위해 이진 트리를 도입합니다.
이진 트리를 데이터 저장에 사용할 때이 Col2는이 유형으로 정렬됩니다. 23을 쿼리 할 때 이번에는 해당 데이터를 찾는 데 4 개의 디스크 IO 만 필요합니다.
이것은 우리가 만난 직접 전체 테이블 쿼리의 문제를 해결하기위한 것일 뿐이지 만 이진 트리를 사용하면 새로운 문제가 수반 될 수 있습니다.
1.二叉树的定义是每个节点只有两个字数，那么每一层的存储是有限的（当面对MySQL大的数据量的情况下，子叶数据过多，层级过多也会导致大量的IO产生）
2.在特殊情况下，二叉树是存在问题的（如下图所示） 
정렬 된 자동 증가 시퀀스를 사용할 때 이진 트리는 다음과 같은 구조를 갖습니다.
Col1을 인덱스로 사용한다고 가정하면 위의 그림과 같이 이진 트리에 문제가 있으므로 이진 트리 사용의 의미가 크지 않습니다.
1.1.2. 레드-블랙 트리
Red Black Tree는 컴퓨터 과학에서 사용되는 데이터 구조 인 자체 균형 이진 검색 트리이며 일반적인 사용은 연관 배열을 구현하는 것입니다.
레드-블랙 트리는 특수 AVL 트리 (밸런스드 이진 트리)로, 삽입 및 삭제시 특정 작업을 통해 이진 검색 트리의 균형을 유지하여 더 높은 검색 성능을 얻을 수 있습니다.
红黑树和平衡二叉树的区别，红黑树在结构的变化上还算是比较稳定的。
所以就会导致平衡二叉树相对于红黑树保持更加严格的平衡,所以平衡二叉树的查询是比较快的（但是以多旋的方式保持平衡增加可新增、修改、删除的开销）
这也就是HashMap的树使用的是红黑树而不使用平衡二叉树的原因。먼저 빨강-검정 트리를 사용하여 Col2의 인덱스를 봅니다.
Col1의 인덱스 정렬을 다시 확인하십시오.
레드-블랙 트리는 이진 트리에서 일련 번호의 자동 증가 문제를 해결하고 스핀 최적화 방법을 수행하지만 데이터 양이 너무 많으면 여전히 문제를 해결하지 못합니다. 더 많은 리프 노드, 더 많은 레이어 및 더 많은 IO 문제).
1.1.3. 해시 트리
해시 트리 (또는 해시 트리)는 컬렉션 및 매핑을 구현하는 데 사용할 수있는 영구 데이터 구조이며 순수 함수형 프로그래밍에서 해시 테이블을 대체하기위한 것입니다. 기본 형식에서 해시 트리는 해당 키의 해시 값 (비트 문자열로 간주 됨)을 트라이에 저장합니다. 여기서 실제 키와 (선택 사항) 값은 트라이의 "최종"노드에 저장됩니다.
먼저 해시 트리 설정은 목표의 요구 사항을 충족 할 수 있으며 해시 값에 따라 지정된 위치를 빠르게 찾을 수 있습니다.
인덱싱 방법 선택시 Hash 선택이 허용되지만 질의가 빠르더라도 실제 인덱싱 상황에서는 거의 사용되지 않는데 왜 그럴까요?
우선 느린 쿼리 문제를 해결하지만 값의 범위를 만나면 Hash는 무력합니다. 전체 테이블 스캔 만 하나씩 비교할 수 있습니다. 이것은 우리가보고 싶은 것이 아닙니다.
1.1.4. B 트리
BTree의 정의를 설명하기 전에 먼저 다음과 같은 Btree의 개략도를 살펴볼 수 있습니다.
BTree의 특징
叶节点具有相同的深度，叶节点的指针为空
所有索引元素不重复
节点中的数据索引从左到右递增排列Mysql의 기본값은 각 자엽 블록의 크기가 16K입니다.
Btree는 현재의 실제 상황을 완벽하게 해결할 수 있지만 각 인덱스 아래에 해당 데이터가 있는지 관찰해야합니다. 테이블에 데이터 필드가 적 으면 마지 못해 받아 들일 수 있지만 필드가 많으면 인덱스 각 잎 블록에 저장할 수있는 블록도 매우 작기 때문에 매우 만족스럽지 않습니다.
1.1.5.B + 트리
B + Tree를 설명하기 전에 아래와 같이 B + Tree의 개략도를 살펴볼 필요가 있습니다.
B + Tree의 특징은 다음과 같습니다.
非叶子节点不存储data，只存储索引(冗余)，可以放更多的索引
叶子节点包含所有索引字段
叶子节点用指针连接，提高区间访问的性能B + Tree가 실제 문제를 해결합니까?
第一：每一个叶子节点不会专门的带有Data的数据了，那么每个叶子节点存放的数据就会更多，估计到了第三层的时候就能打倒2000W左右的数据存储（解决了二叉树、红黑树、BTree问题）
第二：解决了二叉树连续递增的问题（不仅解决了，这里之后还更加依赖了整形类的数据递增，因为这样的话，才能更好的组装B+Tree的结构，不是递增的情况下有中位数据的产生，有可能导致
数据结构的变化，对于数据库来说也是很大的开销）（解决了二叉树问题）
第三：在最底层的时候会有环行链（首尾相连）的结构在里面，解决了Hash树的范围查询的问题（解决了Hash树问题）1.2. 인덱스 엔진
MySQL 인덱싱 엔진에는 두 개의 주요 검색 엔진이 있습니다. 하나는 MyISAM이고 다른 하나는 InnoDB입니다.
1.2.1. MyISAM (데이터와 인덱스가 함께 있지 않아 클러스터되지 않은 인덱스이기 때문)
MyISAM이 본질적으로 데이터에 저장되는 방식을 먼저 살펴보십시오.
My User 테이블은 MyISAM 유형으로 정의되며 DATA 데이터에는 3 개의 파일이 있습니다.
*.frm 存储表结构
*.MYD 存储表数据
*.MYI存储表索引실제 쿼리 논리는 아래 그림에 나와 있습니다.
먼저 MYI의 데이터를 쿼리하여 데이터 저장소의 위치를 확인한 다음 위치 정보 (0x07)에 따라 전체 데이터를 찾습니다.
그런 다음 위치 정보를 통해 MYD 파일을 찾고 데이터의 내용을 직접 가져옵니다.
1.2.2 InnoDB (인덱스와 데이터가 함께 있기 때문에 클러스터형 인덱스라고도 함)
InnoDB 저장 방법 확인
테이블 sys_uesr_role은 InnoDB에 의해 정의되며 데이터에는 두 개의 파일 데이터가 있습니다.
*.frm 存储表结构
*.idb 存储的是索引和数据실제 구현 논리는 아래 그림에 나와 있습니다.
기본 키 색인 :
비 기본 키 인덱스 :
문제:
为什么InnoDB表必须有主键，并且推荐使用整型的自增主键？
答：没有主键的话，系统会默认的使用 rowid作为主键进行排序，但是rowid是默认的，大小是不确定的，在插入的时候可能会导致索引树结构的变更。这也同时回答了为什么用整数自增型来作为主键
为什么非主键索引结构叶子节点存储的是主键值？(一致性和节省存储空间)
答：非主键这么存储的原因是因为，为了只是维护一份数据，假设如果非主键数据也存在Data,idb的数据是按照倍数增加，而且如果非主键索引存储了数据，
就会包含一致性事务在里面，白白浪费了很多无用的开销。1.3. 공동 지수
공동 지수는 가장 왼쪽에있는 원칙을 가지고 있습니다.