mysql 클러스터형 인덱스의 단점은 무엇입니까?

클러스터형 인덱스는 별도의 인덱스 유형이 아니라 데이터 저장 방식(데이터 구조가 아니라 저장 구조)입니다. 구체적인 내용은 구현에 따라 다르지만 실제로 innodb의 클러스터형 인덱스는 btree 인덱스와 동시에 존재합니다. 데이터 행은 하나의 구조로 저장됩니다.

　테이블에 인덱스가 있는 경우 해당 데이터 행은 실제로 인덱스의 리프 페이지에 저장됩니다. 클러스터링은 데이터 행을 두 위치에 저장할 수 없기 때문에 데이터 행과 인접한 키 값이 함께 컴팩트하게 저장된다는 의미입니다. 동시에 다른 위치에 있으므로 테이블은 하나의 클러스터형 인덱스만 가질 수 있습니다. 스토리지 엔진이 인덱스 구현을 담당하기 때문에 모든 스토리지 엔진이 클러스터형 인덱스를 지원하는 것은 아닙니다. 다음은 주로 innodb를 소개하지만 아래에 설명된 원칙은 클러스터형 인덱스를 지원하는 모든 엔진에 적용 가능합니다.

리프 페이지에는 행의 모든 ​​데이터가 포함되지만 노드 페이지에는 인덱스 열(또는 리프가 아닌 노드의 노드 페이지)만 포함됩니다. 인덱스 값의 인덱스입니다. 이러한 노드 페이지에는 인덱스 열에서 추출된 값이 포함되어 있기 때문입니다.

　Innodb는 기본 키를 통해 데이터를 집계합니다. 정의된 기본 키가 없으면 Innodb는 대신 비어 있지 않은 첫 번째 고유 인덱스를 선택합니다. 비어 있지 않은 고유 인덱스가 없으면 Innodb는 암시적으로 6바이트 rowid를 정의합니다. 기본 키를 클러스터형 인덱스로 사용합니다. InnoDB는 같은 페이지의 레코드만 집계하므로 인접한 키 값이 포함된 페이지는 서로 멀리 떨어져 있을 수 있습니다.

　 주의: 클러스터된 기본 키는 성능에 도움이 될 수 있지만, 특히 테이블의 스토리지 엔진이 innodb에서 다른 엔진으로 변환될 때 심각한 성능 문제를 일으킬 수도 있습니다.

집계된 데이터에는 몇 가지 중요한 장점이 있습니다.

A: 관련 데이터를 함께 저장할 수 있습니다. 예를 들어 이메일을 구현할 때 사용자 ID를 기준으로 데이터를 집계할 수 있으므로 적은 수의 데이터 페이지만 읽어도 됩니다. 클러스터형 인덱스를 사용하지 않으면 각 이메일로 인해 디스크 IO

　B: 데이터 액세스가 더 빨라집니다. 클러스터형 인덱스 데이터 검색은 일반적으로 비클러스터형 인덱스에서 조회하는 것보다 빠릅니다.

　 C: 포함 인덱스 스캔을 사용하는 쿼리는 페이지 노드의 기본 키 값을 직접 사용할 수 있습니다.

클러스터형 인덱스의 단점:

A: 클러스터링된 데이터는 IO 집약적인 애플리케이션의 성능을 향상시키지만 모든 데이터가 메모리에 배치되면 액세스 순서가 그다지 중요하지 않으며 클러스터링된 인덱스는 이점이 없습니다. B: 삽입 속도는 삽입 순서에 따라 크게 달라집니다. 기본 키에 따르면 순차적 삽입이 innodb 테이블에 데이터를 로드하는 가장 빠른 방법이지만, 기본 키 순서대로 데이터가 로드되지 않는 경우에는 로드가 완료된 후 최적화 테이블 명령을 사용하여 테이블을 재구성하는 것이 가장 좋습니다

　C: 클러스터형 인덱스 열 업데이트 비용이 매우 높음. 업데이트된 각 행을 innodb에서 새 위치로 이동해야 하기 때문입니다.

　D: 클러스터형 인덱스 기반 테이블은 새 행이 삽입되거나 기본 행이 삽입될 때 페이지 분할 문제에 직면할 수 있습니다. 키가 업데이트되고 행을 이동해야 하는 경우 행의 기본 키 값에 따라 행을 전체 페이지에 삽입해야 하는 경우 스토리지 엔진은 행을 수용하기 위해 페이지를 두 페이지로 분할합니다. 페이지 분할로 인해 테이블이 더 많은 디스크 공간을 차지하게 됩니다.

E: 클러스터형 인덱스는 특히 행이 희박하거나 페이지 분할로 인해 데이터 저장이 불연속적인 경우 전체 테이블 검색 속도를 느리게 할 수 있습니다.

F: 보조 인덱스는 생각보다 큽니다. 보조 인덱스의 리프 노드에는 참조된 행의 기본 키 열이 포함되어 있기 때문입니다.

G: 보조 인덱스 액세스에는 하나가 아닌 두 개의 인덱스 조회가 필요합니다.

보조 인덱스 리프 노드에 저장되는 것은 행의 물리적 위치에 대한 포인터가 아니라 행의 기본 키 값이기 때문입니다. 이는 보조 인덱스를 통해 행을 검색할 때 스토리지 엔진이 해당 기본 키 값을 얻기 위해 보조 인덱스의 리프 노드를 찾은 다음 이 기본 키 값을 사용하여 클러스터형 인덱스에서 해당 행을 찾아야 함을 의미합니다. 여기서는 반복 작업이 한 번이 아닌 두 번 수행됩니다. innodb의 경우 적응형 해시 인덱스를 사용하면 이러한 반복 작업을 줄일 수 있습니다.

innodb와 myisam 물리적 저장소의 데이터 분포 비교:

Myisam:

myisam에서는 기본 키 인덱스와 보조 인덱스 간에 구조적 차이가 없습니다. 기본 키 인덱스는 기본이라는 null이 아닌 고유한 인덱스입니다.

　Innodb:

Innodb는 클러스터형 인덱스를 지원하기 때문에 동일한 데이터를 저장하는 데 매우 다른 방법을 사용합니다. Innodb 클러스터형 인덱스는 인덱스뿐만 아니라 전체 테이블의 데이터를 포함합니다. 테이블이므로 myisam처럼 별도의 행 저장소가 필요하지 않습니다. 클러스터형 인덱스의 각 리프 노드에는 기본 키 값, 트랜잭션 ID, 트랜잭션 및 MVCC에 대한 롤백 포인터 및 나머지 모든 열의 값이 포함됩니다. 기본 키가 열 접두사 인덱스인 경우 InnoDB에는 전체 기본 키도 포함됩니다. 열 및 나머지 열 값입니다.

myisam과 또 다른 점은 innodb의 보조 인덱스가 클러스터형 인덱스와 매우 다르다는 것입니다. innodb의 보조 인덱스의 리프 노드에는 행 포인터가 아닌 기본 키 값이 저장되어 있으며 이를 기본 키 값으로 사용합니다. 이 전략은 행이 이동되거나 데이터 페이지가 분할될 때 보조 인덱스의 유지 관리 작업을 줄여줍니다. 기본 키 값을 포인터로 사용하면 innodb가 더 많은 공간을 차지한다는 이점이 있습니다. 행 이동 보조 인덱스에서 이 포인터를 업데이트할 필요가 없습니다.

　Innodb 테이블을 사용하고 있으며 집계할 데이터가 없는 경우 기본 키 데이터에는 대리 키를 정의할 수 있습니다. 가장 간단한 방법은 auto_increment를 사용하는 것입니다. 열 자동 증가를 사용하면 데이터 행이 순서대로 삽입되고 기본 키를 기반으로 하는 연결 작업의 성능이 향상됩니다.

　UUID를 클러스터형 인덱스로 사용하지 마십시오. 그렇지 않으면 클러스터형 인덱스 삽입이 완전히 무작위로 이루어져 클러스터링 특성이 없는 데이터가 되기 때문에 성능이 매우 저하됩니다. UUID를 기본 키로 사용하여 행을 삽입하기 때문에 시간이 더 오래 걸릴 뿐만 아니라 인덱스도 더 커집니다. 반면에 기본 키 필드가 길어졌기 때문입니다. 페이지 분할로 인해 발생하고 조각화로 인해 인덱스가 변경되었습니다. 기본 키 값은 순차적이기 때문에 Innodb는 페이지의 최대 채우기 비율에 도달하면 각 레코드를 이전 레코드 뒤에 저장합니다(InnoDB의 기본 최대 채우기 비율은 페이지 크기의 15/16입니다. 나중에 수정하기 위한 공간), 다음 레코드는 새 페이지에 기록됩니다. 데이터가 이 순서대로 로드되면 기본 키 페이지는 대략 예상한 결과인 순차적 레코드로 채워집니다. 보조 인덱스 페이지는 다를 수 있습니다).

UUID 기본 키에서 새로 삽입된 행의 기본 키 값이 반드시 이전 값보다 클 필요는 없기 때문에 innodb는 항상 인덱스 끝에 새 행을 삽입할 수는 없지만 적절한 위치를 찾아야 합니다. 일반적으로 기존 데이터의 중간 위치이며 새 공간이 할당되므로 추가 작업이 많이 추가되고 데이터 배포가 덜 최적화됩니다. 다음은 기본 키로 UUID를 사용할 때의 몇 가지 단점입니다.

A: 쓰기 대상 페이지가 디스크에 플러시되어 캐시에서 제거되었거나 캐시에 로드되지 않았을 수 있습니다. InnoDB는 삽입하기 전에 대상 페이지를 디스크에서 메모리로 찾아서 읽어야 합니다. 많은 임의 IO

B: 쓰기 순서가 잘못되었기 때문에 innodb는 새 행에 대한 공간을 할당하기 위해 페이지 분할 작업을 자주 수행해야 합니다. 페이지 분할로 인해 많은 양의 데이터가 이동해야 합니다. 한 페이지가 아닌 삽입용으로 수정

C : 잦은 페이지 분할로 인해 페이지가 희박해지고 불규칙하게 채워져 최종 데이터가 조각나게 됩니다

이러한 무작위 값을 클러스터형 인덱스에 로드한 후 테이블 최적화를 수행하여 테이블을 다시 작성하고 페이지 채우기를 최적화해야 할 수도 있습니다. InnoDB를 사용할 때는 가능한 한 기본 키 순서대로 데이터를 삽입해야 하며, 가능할 때마다 클러스터링 키 값의 간단한 증분을 사용하여 새 행을 삽입해야 합니다.

참고: 순차 기본 키가 더 나쁜 결과를 초래하는 경우는 언제인가요?

　동시성이 높은 워크로드의 경우 Innodb에서 기본 키 순서로 삽입하면 심각한 경합이 발생할 수 있습니다. 기본 키의 상한선을 핫스팟이라고 합니다. 모든 삽입이 여기에서 발생하므로 동시 삽입 시 또 다른 핫스팟이 발생할 수 있습니다. Spot은 auto_increment 잠금 메커니즘일 수 있습니다. 이 문제가 발생하면 테이블이나 애플리케이션을 다시 디자인하거나 innodb_autoinc_lock_mode 구성을 변경해야 할 수 있습니다.

위 내용은 mysql 클러스터형 인덱스의 단점은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!