MySQL 단순 인덱스 계획 분석

Mysql 단순 인덱스

1. 인덱스가 없을 때 검색하는 방법

지금 당장 레코드를 직접 검색하고 싶다면 어떻게 검색하나요?

페이지에서 검색

테이블에 레코드가 거의 없고 한 페이지이면 충분하다면 두 가지 상황이 있습니다.

• 기본 키를 검색 조건으로 사용: 이전에 언급한 방법입니다. 기사에서는 이분법을 사용하여 페이지 디렉토리에서 슬롯을 빠르게 찾은 다음 슬롯 그룹에 해당하는 레코드를 탐색하고 마지막으로 지정된 레코드를 찾습니다.

• 다른 비기본 키 열을 검색 조건으로 사용: 데이터 페이지에는 기본 키가 아닌 열에 대한 페이지 디렉터리가 없기 때문에 이분법을 통해서는 슬롯을 빠르게 찾을 수 없습니다. Infimum 레코드부터 시작하는 단일 연결 리스트의 레코드입니다.

여러 페이지에서 검색

테이블에 레코드가 많으면 이를 저장하는 데 많은 데이터 페이지가 사용됩니다. 이 경우 2단계가 필요합니다.

• 다음 페이지를 찾습니다. 기록이 위치합니다.

• 페이지에서 위의 검색 과정을 반복하세요.

일반적으로 색인이 없으면 레코드가 있는 페이지를 빠르게 찾을 수 없습니다. 이중 연결 목록(페이지에는 이전 페이지와 다음 페이지가 있음)을 따라 첫 번째 페이지에서만 검색할 수 있습니다. 을 클릭한 다음 각 페이지에서 검색합니다. 지정된 레코드를 쿼리하려면 페이지에서 위 프로세스를 반복해야 하며, 이는 모든 레코드를 순회해야 하며 시간이 많이 걸립니다.

2. 간단한 인덱스

페이지가 너무 많아 위치 기록이 너무 느린데 어떻게 해결하나요? "페이지 디렉토리"를 참조할 수도 있습니다.

페이지 디렉토리는 기본 키를 기반으로 페이지 내 레코드 위치를 빠르게 찾을 수 있도록 설정됩니다. 따라서 기록이 위치한 페이지를 빠르게 찾기 위해 "다른 디렉터리"를 생성하는 방법을 탐색할 수 있습니다.

하지만 이 "다른 디렉터리"를 완료하기 전에 수행해야 할 두 가지 작업이 있습니다.

1. 다음 페이지의 사용자 레코드의 기본 키 값은 이전 페이지의 기본 키 값보다 커야 합니다.

각 데이터 페이지에 최대 3개의 레코드를 넣을 수 있다고 가정하고(실제로는 많이 넣을 수 있음) 이제 삽입합니다. 테이블에 3개의 레코드가 있고 각 레코드에는 3개의 열 c1, c2, c3이 있습니다. 편의를 위해 저장 행 형식도 단순화되어 주요 속성만 남깁니다. 가상 기록인 Infimum과 Supremum은 각각 사용자 기록의 시작 부분과 끝 부분에 위치하며, 중간에 3개의 사용자 기록이 위치합니다.

이때 계속해서 1개의 레코드를 삽입합니다. 가상의 경우에는 최소한 하나의 새 페이지를 할당해야 하므로 두 페이지가 다시 할당되고 재배열됩니다.

빨간색 글꼴로 표시된 두 레코드에는 기본 키가 4인 새로 삽입된 레코드가 포함되어 있으므로 새 페이지에 배치되어야 합니다. 그러나 다음 페이지의 사용자 레코드의 기본 키 값이 이전 페이지의 사용자 레코드의 기본 키 값보다 커야 한다는 요구 사항을 충족하기 위해 레코드 이동 등의 작업을 수행할 수도 있습니다. "페이지 분할"이라고 합니다.

그리고 새 페이지는 왜 11페이지가 아니고 28페이지인가요? 디스크에서는 페이지가 서로 인접하지 않을 수 있으므로 이전 페이지와 다음 페이지의 번호를 유지하여 연결 목록 관계를 설정합니다.

2. 모든 페이지에 대한 디렉토리 항목을 만듭니다.

이제 계속해서 테이블에 데이터를 추가합니다. 여러 페이지 간의 최종 관계는 다음과 같습니다.

인접하지 않은 여러 페이지에서 레코드를 빠르게 찾으려면 , 페이지가 디스크에서 연속되지 않을 수 있으므로 카탈로그를 작성해야 합니다.

각 페이지는 디렉터리 항목에 해당하며 각 디렉터리 항목에는 다음이 포함됩니다.

• 페이지의 사용자 레코드에서 키로 표시되는 가장 작은 기본 키 값

• page_no로 표시되는 페이지 번호

그래서 목록화한 후의 관계는 다음과 같습니다.

이제 기본 키 값이 20인 레코드를 찾고 싶습니다. 구체적으로 두 단계로 수행하겠습니다.

이분법 사용 디렉토리 항목에서 기본 키를 빠르게 확인하려면 키 값이 20인 레코드가 디렉토리 항목 3에 있고 페이지 번호는 9입니다. 9페이지에 있다는 것을 알고 이전 접근 방식을 반복하여 최종 대상 레코드를 찾습니다.

이제 간단한 해결이 완료됩니다. 완성된 단순 디렉터리에는 index라는 별칭이 있습니다.

3. 단순 인덱스로 드러나는 문제

위의 단순 인덱스는 독자들의 이해를 돕기 위해 원작자가 설정한 내용으로 innodb의 인덱스 방식이 아닙니다.

그럼 위에서 제안한 인덱스를 살펴보고 어떤 문제가 있는지 살펴보겠습니다.

질문 1:

InnoDB는 저장 공간 관리를 위한 기본 단위로 페이지를 사용합니다. 즉, 연속 저장 공간은 최대 16kb까지만 저장할 수 있습니다.

테이블에 레코드가 점점 더 많아지면 모든 디렉토리 항목을 보관하기 위해 매우 크고 연속적인 저장 공간이 필요하며 이는 많은 양의 데이터가 있는 테이블에는 비현실적입니다.

질문2:

기록을 추가, 삭제, 수정해야 하는 경우가 많아 신체 전체에 영향을 줄 수 있습니다.

예를 들어 위 그림에서 28페이지의 레코드를 모두 삭제하면 28페이지는 없어도 되고, 디렉토리 항목 2도 없어도 됩니다. 이때 디렉터리 항목 2 이후의 디렉터리 항목을 앞으로 이동해야 합니다.

이동하지 않더라도 디렉토리 항목 2를 디렉토리 항목 목록에 중복으로 배치하면 저장 공간이 많이 낭비됩니다.

위 내용은 MySQL 단순 인덱스 계획 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!