MyISAM 및 InnoDB 최고

RAM의 제한으로 인해 동시성 성능의 이점을 얻기 때문에 InnoDB가 클러스터형 인덱스 대신 MyISAM과 동일한 인덱스를 사용하도록 할 수 있습니까?

gen_clust_index 이노의 후드 (클러스터 인덱스)의 ROWID와 함께 기본 키의 항목을 수용. gen_clust_index의 사용에있어 흥미로운 점은 생성하는 고유하지 않은 인덱스는 항상 테이블의 gen_clust_index에 해당하는 rowid를 갖기 때문입니다. 따라서 항상 보조 인덱스와 gen_clust_index에 대한 이중 인덱스 조회가 있습니다.

gen_clust_index 또는 최소한의 한계 결과로 인해 테이블 ​​또는 기본 키의 레이아웃을 개선하려는 시도가 무효화됩니다.

예

어떤 사람들은 MyISAM을 PRIMARY KEY 순서로 정렬하려고 시도합니다. 에 따르면 MySQL 데이터베이스 설계 및 조정, 페이지 236 "인덱스 순서대로 테이블을 저장"부제목 아래 단락 7 :

테이블에서 넓은 범위의 색인화 된 데이터를 자주 검색하거나 동일한 색인 키에서 결과를 일관되게 정렬하는 경우 --sort-records 옵션을 사용하여 myisamchk를 실행하는 것이 좋습니다. 이렇게하면 MySQL에게 인덱스와 동일한 물리적 순서로 테이블 데이터를 정렬하도록 지시하고 이러한 종류의 작업 속도를 높일 수 있습니다. 또는 ALTER TABLE 문을 ORDER BY 특정 컬럼 옵션과 결합하여 동일한 결과를 얻을 수 있습니다.

물론 이것은 MyISAM에 효과적이며 효과적 입니다. 열이 PRIMARY KEY의 열일 수도 있고 아닐 수도있는 InnoDB에 대해 ALTER TABLE ... ORDER BY col1, col2, ..., coln을 수행 할 수 있습니다. InnoDB의 결과는 더 빠르지 않습니다. 왜냐하면 ... 맞습니다. 매번 gen_clust_index를 참조하십시오.

일부 사람들은 테이블 행 형식을 FIXED로 사용하여 ALTER TABLE mydb.mytb ROW_FORMAT=Fixed;다른 변경없이 읽기 성능을 20 % 향상시킬 수 있습니다. 이것은 MyISAM에 효과적이며 효과적 입니다. InnoDB의 결과는 더 빠르지 않습니다. 왜냐하면 ... 맞습니다. 매번 gen_clust_index를 참조하십시오.

mydb.mytb라는 InnoDB 테이블에서 다음을 수행 할 수 있습니다.

CREATE TABLE mydb.mytc LIKE mydb.mytb;
INSERT INTO mydb.mytc SELECT * FROM mydb.mytb ORDER BY col1,col2,...coln;
ALTER TABLE mydb.mytb RENAME mydb.mytd;
ALTER TABLE mydb.mytc RENAME mydb.mytb;
DROP TABLE mydb.mytd;

그러면 gen_clust_index에 테이블이 rowid 순서로 배치됩니다. 이로 인해 InnoDB에 대한 한계 결과를 얻을 수 있습니다. 왜냐하면 맞습니다. 매번 gen_clust_index를 참조해야합니다.

자, 조금 우스워 봅시다. HandlerSocket (이전의 HANLDER) 인터페이스 라고하는 NoISA 인터페이스를 쿼리 (SELECT 전용)하는 MyISAM 및 InnoDB가 있습니다 . 이를 통해 모든 SQL, ACID 및 MVCC 프로토콜 을 무시할 수있는 데이터에 액세스 할 수 있습니다 . 가능하지만, 코드와 유지 보수에 너무 많은 방법을 사용해야합니다. AFAIK HandlerSocket 인터페이스가 gen_clust_index와 상호 작용하는지 여부를 나타내는 인쇄물에는 아무것도 없습니다.

요약하면, 고양이를 껍질을 벗기는 방법에는 여러 가지가 있습니다. 이 경우 고양이를 잡을 수 없습니다 (gen_clust_index). 이것이 MyISAM이 읽기 성능, 테이블 순서의 유연성, 테이블 행 형식 및이를 지원하는 도구로 인해 계속 존재하는 이유라고 생각합니다. InnoDB는 일부 용감한 영혼이 InnoDB 소스 코드를 가져 와서 MyISAM 및 InnoDB 모두를 최대한 활용하는 코드로 변환 할 때까지 ACID 호환 특성을 고려하여 디자인 된 상태로 유지됩니다 .

클러스터 된 인덱스는 아마도 기존의 스핀 드라이브 이노의 동시성 성능에 대한 이유.

행 데이터가 인덱스 검색이 이어지는 동일한 페이지에 있기 때문에 클러스터형 인덱스를 통해 행에 빠르게 액세스 할 수 있습니다. 테이블이 큰 경우 클러스터형 인덱스 아키텍처는 종종 인덱스 레코드와 다른 페이지를 사용하여 행 데이터를 저장하는 스토리지 조직과 비교할 때 디스크 I / O 작업을 저장합니다. 예를 들어 MyISAM은 하나의 파일을 데이터 행에 사용하고 다른 파일은 인덱스 레코드에 사용합니다.

디스크 I / O는 비싸다. 따라서 축소하면 동시성을 향상시키는 데 큰 이점이 있습니다.

디스크 I / O가 저렴 해지고 병목 현상이 줄어들 기 시작하면 (예 : SSD 기술의 안정성이 높아짐) Oracle은 InnoDB 인덱스 작동 방식을 변경하기로 결정할 수 있습니다. 동일한 기술이 'RAM의 한계'를 덜 문제로 만들기 때문에 동일하게 유지 될 가능성이 높습니다.

짧은 답변: 아니요.

기본 키를 통한 InnoDB 클러스터 및 기본 키가 없으면 첫 번째 고유 인덱스를 선택합니다. 고유 인덱스가 없으면 클러스터링을 위해 숨겨진 6 바이트 키를 만듭니다.

숨겨진 6 바이트 키가있는 경우 보조 인덱스는 행 위치에 대한 정확한 포인터 (MyISAM에서와 같이)가 아니라이 키를 참조하므로 레코드를 찾기 위해 보조 키 통과와 기본 키 통과가 생깁니다. .

귀하의 질문에서 조금 외삽하기 위해, 효율적으로 검색하려면 모든 루트 노드가 메모리에 있어야하기 때문에 리프 페이지를 찾기 위해 항상이 경로를 걸어야하기 때문에 트리에 맞는 메모리에 대해 걱정하고 있다고 가정합니다.

이것은 사실이지만 하나의 위안은 상용 데이터베이스가 나무를 깊기보다는 가능한 한 뚱뚱하게 만들려고한다는 것입니다. 데이터 에서 xtrabackup --stats 를 실행 하여보십시오. 예를 들면 다음과 같습니다.

<INDEX STATISTICS>
  table: test/table1, index: PRIMARY, space id: 12, root page 3
  estimated statistics in dictionary:
    key vals: 25265338, leaf pages 497839, size pages 498304
  real statistics:
     level 2 pages: pages=1, data=5395 bytes, data/pages=32%
     level 1 pages: pages=415, data=6471907 bytes, data/pages=95%
        leaf pages: recs=25958413, pages=497839, data=7492026403 bytes, data/pages=91%

497839 개의 리프 페이지 (~ 8GB)가 있었지만 416 페이지 (6.5MB) 만있었습니다. 프로덕션 데이터에서이 명령을 몇 번 실행했으며 수백만 억 개의 레코드가 있고 레벨 1-3 페이지 + 리프 페이지 만 있으면 항상 놀라게됩니다.