>  기사  >  데이터 베이스  >  InnoDB 행 저장 형식이란 무엇입니까?

InnoDB 행 저장 형식이란 무엇입니까?

醉折花枝作酒筹
醉折花枝作酒筹앞으로
2021-07-09 09:15:401978검색

이전 InnoDB 버전에서는 파일 형식이 하나뿐이어서 이 파일 형식에 이름을 붙일 필요가 없었습니다. InnoDB 엔진이 발전함에 따라 새로운 기능을 지원하기 위해 이전 버전과 호환되지 않는 새로운 파일 형식이 개발되었습니다. 오늘은 InnoDB 행 저장 형식을 소개하겠습니다.

InnoDB 행 저장 형식이란 무엇입니까?

InnoDB 스토리지 엔진은 REDUNDANT, COMPACT, DYNAMIC 및 COMPRESSED의 네 가지 형식을 지원합니다.

InnoDB 행 형식 개요

InnoDB 행 저장 형식이란 무엇입니까?

REDUNDANT 행 형식

REDUNDANT 형식은 이전 버전의 MySQL과의 호환성을 제공합니다.

REDUNDANT 행 형식은 두 가지 InnoDB 파일 형식(Antelope 및 Barracuda)에서 지원됩니다.

REDUNDANT 행 형식을 사용하는 테이블은 B-트리 노드 내의 인덱스 레코드에 가변 길이 열 값(VARCHAR, VARBINARY, BLOB 및 TEXT 유형)의 처음 768바이트를 저장하고 나머지는 오버플로 페이지에 저장합니다. 768바이트보다 크거나 같은 고정 길이 열은 가변 길이 열로 인코딩되며 페이지 외부에 저장될 수 있습니다. 예를 들어, 문자 집합의 최대 바이트 길이가 3utf8mb4보다 큰 경우 CHAR(255) 열은 768바이트를 초과할 수 있습니다.

열의 값이 768바이트 이하인 경우 오버플로 페이지가 사용되지 않으며 값이 B-트리 노드에 완전히 저장되므로 I/O가 약간 절약될 수 있습니다. 이는 상대적으로 짧은 BLOB 열 값에 대해서는 잘 작동하지만 B-트리 노드가 키 값이 아닌 데이터로 채워져 효율성이 떨어질 수 있습니다. BLOB 열이 많은 테이블은 B-트리 노드가 너무 가득 차고 너무 적은 행을 포함하게 하여 행이 더 짧거나 열 값이 페이지 외부에 저장된 경우보다 전체 인덱스의 효율성을 떨어뜨릴 수 있습니다.

REDUNDANT 행 형식 저장 기능

REDUNDANT 행 형식에는 다음과 같은 저장 기능이 있습니다.

  • 각 인덱스 레코드에는 6바이트 헤더가 포함되어 있습니다. 헤더는 연속된 레코드를 함께 연결하고 행 수준 잠금에 사용됩니다.

  • 클러스터형 인덱스의 레코드에는 모든 사용자 정의 열에 대한 필드가 포함됩니다. 또한 6바이트의 트랜잭션 ID 필드와 7바이트의 롤링 포인터 필드가 있습니다.

  • 테이블에 기본 키가 정의되지 않은 경우 각 클러스터형 인덱스 레코드에는 6바이트 행 ID 필드도 포함됩니다.

  • 각 보조 인덱스 레코드에는 보조 인덱스에 없는 클러스터형 인덱스 키에 대해 정의된 모든 기본 키 열이 포함됩니다.

  • 레코드에는 레코드의 각 필드에 대한 포인터가 포함되어 있습니다. 레코드에 있는 필드의 총 길이가 128바이트보다 작으면 포인터는 1바이트이고, 그렇지 않으면 2바이트입니다. 포인터 배열을 레코드 디렉터리라고 합니다. 포인터가 가리키는 영역은 레코드의 데이터 부분입니다.

  • 내부적으로는 CHAR(10)과 같은 고정 길이 문자 열이 고정 길이 형식으로 저장됩니다. VARCHAR 열에서는 후행 공백이 잘리지 않습니다. 768바이트보다 크거나 같은 고정 길이 열은 가변 길이 열로 인코딩되며 페이지 외부에 저장될 수 있습니다. 예를 들어, 문자 집합의 최대 바이트 길이가 3utf8mb4보다 큰 경우 CHAR(255) 열은 768바이트를 초과할 수 있습니다.

  • SQL NULL 값은 레코드 디렉터리에 1~2바이트를 유지합니다. NULL SQL 값은 가변 길이 열에 저장된 경우 레코드의 데이터 부분에 0바이트를 유지합니다. 고정 길이 열의 경우 열의 고정 길이가 레코드의 데이터 부분에 유지됩니다. NULL 값에 대해 고정 공간을 예약하면 인덱스 페이지 조각화를 유발하지 않고 열을 NULL에서 NULL이 아닌 값으로 업데이트할 수 있습니다.

COMPACT 행 형식

REDUNDANT 행 형식과 비교하여 COMPACT 행 형식은 행 저장 공간을 약 20% 줄입니다. REDUNDANT는 특정 작업에 대한 CPU 사용량이 증가합니다. 작업 부하가 일반적이고 캐시 적중률과 디스크 속도로 인해 제한되는 경우 COMPACT 형식이 더 빠를 수 있습니다. 작업 부하가 CPU 속도로 제한되는 경우 컴팩트 포맷이 더 느려질 수 있습니다.

COMPACT 라인 형식은 두 가지 InnoDB 파일 형식(Antelope 및 Barracuda)에서 지원됩니다.

COMPACT 행 형식을 사용하는 테이블은 B-트리 노드 내의 인덱스 레코드에 가변 길이 열 값(VARCHAR, VARBINARY, BLOB 및 TEXT 유형)의 처음 768바이트를 저장하고 나머지는 오버플로 페이지에 저장합니다.

768바이트보다 크거나 같은 고정 길이 열은 가변 길이 열로 인코딩되며 페이지 외부에 저장될 수 있습니다. 예를 들어, 문자 세트의 최대 바이트 길이가 3보다 큰 경우 CHAR(255)는 열이 utf8mb4 문자 유형인 경우 768바이트를 초과할 수 있습니다.

열의 값이 768바이트 이하인 경우 오버플로 페이지가 사용되지 않으며 값이 B-트리 노드에 완전히 저장되므로 I/O가 약간 절약될 수 있습니다. 이는 상대적으로 짧은 BLOB 열 값에 대해서는 잘 작동하지만 B-트리 노드가 키 값이 아닌 데이터로 채워져 효율성이 떨어질 수 있습니다. BLOB 열이 많은 테이블은 B-트리 노드가 너무 가득 차고 너무 적은 행을 포함하게 하여 행이 더 짧거나 열 값이 페이지 외부에 저장된 경우보다 전체 인덱스의 효율성을 떨어뜨릴 수 있습니다.

COMPACT 행 형식 저장 기능

COMPACT 행 형식에는 다음과 같은 저장 특성이 있습니다.

  • 각 인덱스 레코드에는 가변 길이 헤더가 앞에 올 수 있는 5바이트 ​​헤더가 포함되어 있습니다. 헤더는 연속된 레코드를 서로 연결하고 행 수준 잠금에 사용됩니다.

  • 레코드 헤더의 가변 길이 부분에는 NULL 열을 나타내는 비트 벡터가 포함되어 있습니다. 인덱스의 열 개수가 NULL 일 수 있는 경우 비트 벡터는 N 바이트를 차지합니다. (예를 들어 9~16개의 열이 있을 수 있는 경우 비트 벡터는 2바이트를 사용합니다.) 이 벡터의 비트 이외의 공간을 차지하지 않는 열입니다. 헤더의 가변 길이 부분에는 가변 길이 열의 길이도 포함됩니다. 각 길이에는 열의 최대 길이에 따라 1바이트 또는 2바이트가 필요합니다. 인덱스의 모든 열이 CEILING(*N*/8)NULLNULLNOT NULL이고 고정 길이를 갖는 경우 레코드 헤더에는 가변 길이 부분이 없습니다.

  • NULL이 아닌 각 가변 길이 필드의 경우 레코드 헤더에는 열 길이의 1바이트 또는 2바이트가 포함됩니다. 열의 일부가 오버플로 페이지 외부에 저장되거나 최대 길이가 255바이트를 초과하고 실제 길이가 127바이트를 초과하는 경우 2바이트만 필요합니다. 외부 저장소 열의 경우 2바이트 길이는 내부 저장소 섹션의 길이에 외부 저장소 섹션에 대한 20바이트 포인터를 더한 길이를 나타냅니다. 내부 부분은 768바이트이므로 길이는 768 + 20입니다. 20바이트 포인터는 열의 실제 길이를 저장합니다.

  • 레코드 헤더 뒤에는 NULL이 아닌 열의 데이터 내용이 옵니다.

  • 클러스터형 인덱스의 레코드에는 모든 사용자 정의 열에 대한 필드가 포함됩니다. 또한 6바이트의 트랜잭션 ID 필드와 7바이트의 롤링 포인터 필드가 있습니다.

  • 테이블에 기본 키가 정의되지 않은 경우 각 클러스터형 인덱스 레코드에는 6바이트 행 ID 필드도 포함됩니다.

  • 각 보조 인덱스 레코드에는 보조 인덱스에 없는 클러스터형 인덱스 키에 대해 정의된 모든 기본 키 열이 포함됩니다. 기본 키 열이 가변 길이인 경우 보조 인덱스가 고정 길이 열에 정의되어 있더라도 각 보조 인덱스의 레코드 헤더에는 길이를 기록하는 가변 길이 섹션이 있습니다.

  • 내부적으로 가변 길이가 아닌 문자 집합의 경우 고정 길이 문자 열(예: CHAR(10) 고정 길이 형식으로 저장됨). VARCHAR 열에서는 후행 공백이 잘리지 않습니다.

  • 내부적으로 utf8mb3 및 utf8mb4와 같은 가변 길이 문자 세트의 경우 InnoDB는 후행 공백을 잘라 바이트를 저장하려고 시도합니다. 열 값이 바이트를 초과하는 경우 후행 공백은 열 값의 최소 길이(바이트)로 조정됩니다. 열의 최대 길이는 최대 문자 바이트 길이 × CHAR(*N*)NCHAR(*N*)NCHAR(*N*)

N이며 최소 바이트 수가 예약되어 있습니다. 대부분의 경우 최소 공간을 예약하면 인덱스 페이지 조각화를 유발하지 않고 열 업데이트를 완료할 수 있습니다. 반면에 행 형식을 사용하는 경우 열은 최대 문자 바이트 길이를 차지합니다. 필드는 페이지 외부에 저장될 수 있습니다. 예를 들어, 문자 세트의 최대 바이트 길이가 3보다 큰 경우 CHAR(255)는 열이 utf8mb4 문자 유형인 경우 768바이트를 초과할 수 있습니다.行컴팩트 라인 형식 저장 특성 다이어그램

Mysql Innodb Compat 형식 구조


Mysql Innodb Compat 라인 형식 헤더 정보(비트) ———— —— ——————————— | 알 수 없음 | 알 수 없음 | 1 | 레코드는 가장 작은 레코드로 사전 정의됨 | heap_no | 레코드 유형 001 | B+ 트리 노드 포인터를 나타내며, 010은 supermum을 나타내고, 1xx는 예약된 항목을 나타냅니다. | next_record |

InnoDB 행 저장 형식이란 무엇입니까?


DYNAMIC 행 형식InnoDB 행 저장 형식이란 무엇입니까?


COMPACT 행은 동일한 저장 특성 형식을 제공하지만 긴 가변 길이 열에 대한 향상된 저장 기능을 추가하고 큰 인덱스 키에 대한 접두사를 지원합니다.

Barracuda 파일 형식은 DYNAMIC 라인 형식을 지원합니다.

ROW_FORMAT=DYNAMIC을 사용할 때 테이블을 생성하면 InnoDB는 긴 가변 길이 열 값(VARCHAR, VARBINARY, BLOB 및 TEXT 유형의 경우)을 완전히 페이지 외부에 저장할 수 있으며 클러스터형 인덱스 레코드에는 20바이트 포인터만 포함됩니다. 오버플로 페이지. 768바이트보다 크거나 같은 고정 길이 필드는 가변 길이 필드로 인코딩됩니다. 예를 들어, 문자 세트의 최대 바이트 길이가 3보다 큰 경우 CHAR(255)는 열이 utf8mb4 문자 유형인 경우 768바이트를 초과할 수 있습니다.

열이 페이지 외부에 저장되는지 여부는 페이지 크기와 행의 전체 크기에 따라 다릅니다. 행이 너무 길면 클러스터형 인덱스 레코드가 B-트리 페이지에 들어갈 때까지 오프 페이지 저장을 위해 가장 긴 열이 선택됩니다. TEXT 및 BLOB는 해당 라인에 저장되는 40바이트 이하의 열입니다.

DYNAMIC 행 형식은 맞는 인덱스 노드에 전체 행을 저장하는 효율성을 유지하지만(COMPACT 및 REDUNDANT 형식에서 수행됨) DYNAMIC 행 형식은 B-트리 노드를 큰 숫자로 채우는 문제를 피합니다. 긴 열 데이터 바이트 수입니다. DYNAMIC 행 형식은 긴 데이터 값의 일부가 페이지 외부에 저장되는 경우 일반적으로 전체 값을 페이지 외부에 저장하는 것이 가장 효율적이라는 아이디어를 기반으로 합니다. DYNAMIC 형식의 경우 더 짧은 열이 B-트리 노드에 유지되어 특정 행에 필요한 오버플로 페이지 수를 최소화할 수 있습니다.

DYNAMIC 행 형식은 최대 3072바이트의 인덱스 키 접두사를 지원합니다. 이 기능은 기본적으로 활성화되어 있는 innodb_large_prefix 변수에 의해 제어됩니다. innodb_large_prefix에 대한 자세한 내용은 변수 설명을 참조하세요.

DYNAMIC 행 형식을 사용하는 테이블은 시스템 테이블스페이스, 테이블당 파일 테이블스페이스 및 일반 테이블스페이스에 저장할 수 있습니다. 시스템 테이블스페이스에 테이블을 동적으로 저장하려면 innodb_file_per_table을 비활성화하고 일반 CREATE TABLE 또는 ALTER TABLE 문을 사용하거나 CREATE TABLE 또는 ALTER TABLE과 함께 TABLESPACE [=] innodb_system 테이블 옵션을 사용하세요. innodb_file_per_table 및 innodb_file_format 변수는 일반 테이블스페이스에는 적용되지 않으며, TABLESPACE [=] innodb_system 테이블 옵션을 사용하여 시스템 테이블스페이스에 DYNAMIC 테이블을 저장하는 경우에도 적용 가능하지 않습니다.

DYNAMIC 행 형식 저장 기능

DYNAMIC 행 형식은 COMPACT 행 형식에서 벗어난 것입니다.

COMPRESSED ROW FORMAT

COMPRESSED ROW FORMAT은 DYNAMIC ROW FORMAT과 동일한 저장 기능을 제공하지만 테이블 및 인덱스 데이터 압축에 대한 지원을 추가합니다.

Barracuda 파일 형식은 COMPRESSED 라인 형식을 지원합니다.

COMPRESSED 행 형식은 테이블 및 인덱스 데이터의 추가 저장소 및 성능 고려 사항이 압축되고 더 작은 페이지 크기를 사용하는 DYNAMIC 행 형식과 유사한 페이지 저장소 외부 세부 정보를 사용합니다. COMPRESSED 행 형식을 사용하는 KEY_BLOCK_SIZE 옵션은 클러스터형 인덱스에 저장되는 열 데이터의 양과 오버플로 페이지에 배치되는 양을 제어합니다.

COMPRESSED 행 형식은 최대 3072바이트의 인덱스 키 접두사를 지원합니다. 이 기능은 기본적으로 활성화되어 있는 innodb_large_prefix 변수에 의해 제어됩니다.

COMPRESSED는 행 형식을 사용하여 파일 테이블스페이스 또는 테이블당 일반 테이블스페이스에 테이블을 생성할 수 있습니다. 시스템 테이블스페이스는 COMPRESSED 행 형식을 지원하지 않습니다. COMPRESSED 테이블을 테이블당 파일 테이블스페이스에 저장하려면 innodb_file_per_table 변수를 활성화해야 하며 innodb_file_format을 Barracuda로 설정해야 합니다. innodb_file_per_table 및 innodb_file_format 변수는 일반 테이블스페이스에 적용되지 않습니다. 일반 테이블스페이스는 모든 행 형식을 지원하지만 물리적 페이지 크기가 다르기 때문에 압축된 테이블과 압축되지 않은 테이블이 동일한 일반 테이블스페이스에 공존할 수 없다는 점에 유의해야 합니다. 자세한 내용은 14.6.3.3절 “일반 테이블스페이스”를 참조하십시오.

COMPRESSED 행 형식 저장 기능

COMPRESSED 행 형식은 COMPACT 행 형식의 변형입니다. 단지 행 오버플로 데이터를 처리할 때 약간의 차이가 있을 뿐입니다. 문자열의 처음 768바이트는 기록된 실제 데이터에 저장되지 않고 대신 기록된 실제 데이터에만 모든 바이트가 다른 페이지에 저장됩니다. 다른 페이지의 주소를 저장합니다. 또한 압축 행 형식은 압축 알고리즘을 사용하여 페이지를 압축합니다.

관련 추천: "mysql 튜토리얼"

위 내용은 InnoDB 행 저장 형식이란 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명:
이 기사는 hxd.life에서 복제됩니다. 침해가 있는 경우 admin@php.cn으로 문의하시기 바랍니다. 삭제