MySQL의 데이터 행 및 행 오버플로 메커니즘에 대한 이해

mysql 비디오 튜토리얼 열은 데이터 행과 행 오버플로 메커니즘을 소개합니다.

관련 무료 학습 권장사항: mysql 비디오 튜토리얼

1. 행의 형식은 무엇입니까?

다음과 같이 MySQL 행 형식 설정을 확인할 수 있습니다.

사실 MySQL 데이터 행에는 두 가지 형식이 있습니다. 하나는 그림의 Compact 형식이고 다른 하나는 Redundant 형식입니다.

Compact는 하나의 데이터 페이지에 더 많은 데이터 행을 저장할 수 있도록 설계된 압축 행 형식입니다.

하나의 데이터 페이지에 더 많은 데이터 행을 저장할 수 있다는 것이 얼마나 흥미로운지 아실 겁니다. MySQL은 더 많은 데이터 행을 데이터 페이지 단위로 디스크에서 읽습니다. 데이터 페이지 하나면 공간이 덜 사용되고 전체적인 효율성이 높아진다는 뜻이겠죠?

공식 웹사이트 소개: 컴팩트는 중복 형식보다 저장 공간을 20% 절약할 수 있습니다.

Compact는 MySQL5.0부터 도입되었습니다. MySQL5.1 이후에는 행 형식이 기본적으로 Compact로 설정됩니다. 따라서 이 문서에서 설명하는 내용도 Compact 형식입니다.

2. 컴팩트한 라인 형식은 어떤 모습인가요?

테이블의 일부 열은 null이 허용되고 일부 열은 가변 길이 varchar 유형이라는 점을 알아야 합니다.

컴팩트 라인 형식은 이 정보를 어떻게 구성하고 설명하나요? 아래와 같이:

각 부분에는 위에서 표시한 1, 2, 3보다 더 많은 데이터가 포함될 수 있습니다.

좀 더 직관적인 느낌과 이해를 드리기 위해 보여드릴 부분만 골라봤습니다.

3. MySQL의 단일 행에는 얼마나 많은 데이터를 저장할 수 있나요?

MySQL 설정에서는 단일 데이터 행에 최대 65535바이트의 데이터를 저장할 수 있습니다(문자가 아닌 바이트라는 점에 유의하세요)

그러나 다음과 같은 데이터 테이블을 생성하면 오류가 발생합니다.

MySQL에서는 데이터 페이지의 각 행에 위에서 언급한 숨겨진 열이 있으므로 길이가 65535바이트인 열을 생성하는 것을 허용하지 않습니다.

그래서 테이블을 성공적으로 생성하려면 varchar의 길이를 65532바이트로 줄이세요

여기서 65535는 문자가 아닌 바이트를 나타냅니다.

따라서 charset를 utf8 인코딩 형식으로 변경하면 varchar(N)의 N은 실제로 N 바이트가 아닌 N 문자를 나타냅니다. 따라서 아래와 같이 테이블을 생성하면 오류가 발생합니다.

encode=utf8인 경우 3바이트는 1문자를 나타냅니다. 그러면 65535 / 3 = 21845자입니다.

4. 컴팩트 형식은 어떻게 컴팩트하게 되나요?

MySQL은 매번 무작위 IO 읽기를 수행합니다.

기본적으로 데이터 페이지 크기는 16KB입니다. 데이터 페이지에는 여러 행이 저장되어 있습니다.

즉, 데이터 페이지에 저장할 수 있는 데이터 행이 많을수록 MySQL이 전체적으로 수행하는 IO 횟수가 줄어든다는 뜻인가요? 성능이 더 빨라졌나요?

Compact 형식의 구현 아이디어는 열 유형이 VARCHAR, VARBINARY, BLOB 또는 TEXT일 때 768바이트를 초과하는 열의 데이터가 다른 데이터 페이지에 배치된다는 것입니다.

아래와 같이:

여기서 전체 내용을 보면 매우 명확합니까?

MySQL은 단일 varchar 열이나 Text 열이 너무 커서 단일 데이터 페이지에 너무 적은 행 레코드가 저장되어 IO가 급증하고 메모리를 차지하는 것을 효과적으로 방지하기 위해 이 작업을 수행합니다.

5. 행 오버플로란 무엇인가요?

행 오버플로란 무엇인가요?

데이터 페이지의 기본 크기가 16KB인 경우 바이트로 환산하면: 16*1024 = 16384바이트

그러면 단일 페이지에 저장할 수 있는 16384바이트가 저장할 수 있는 최대 65535바이트와 몇 배 다르다는 것을 눈치채셨나요? 단일 행에 저장됩니까?

즉, 저장하려는 데이터 행이 65532바이트를 초과하면 쓸 수 없게 됩니다. 저장하려는 데이터의 단일 행이 65535바이트보다 작고 16384바이트보다 큰 경우 성공적으로 삽입할 수 있지만 데이터 페이지는 삽입한 데이터를 저장할 수 없습니다. 이때 반드시 줄이 넘칠 것입니다!

실제로 MySQL의 설정에서는 16384byte edge에 도달할 때까지 행 오버플로가 발생하지 않습니다.

varchar, 텍스트 등 유형의 줄에 사용됩니다. 이러한 열 저장 공간의 길이가 수백 바이트에 도달하면 행 오버플로가 발생합니다.

6. 어떻게 넘치나요?

이 사진을 보세요:

MySQL 설정에서 varchar 열의 길이가 768바이트에 도달하면 열의 처음 768바이트가 접두어로 처리되어 행에 저장되고, 추가 데이터는 오버플로되어 오버플로 페이지에 저장된 다음 오프셋 포인터를 통해 두 개를 연결합니다. 이것이 행 오버플로 메커니즘입니다.

7. 질문에 대해 생각해 보세요

이런 질문에 대해 생각해 본 적이 있는지 모르겠습니다.

우선, 이 B에서는 MySQL이 B+Tree의 클러스터형 인덱스를 사용한다는 것을 알아야 합니다. +트리, 리프가 없습니다. 노드는 인덱스만 저장하고 데이터는 저장하지 않으며, 리프 노드는 실제 데이터를 저장합니다. 동시에 리프 노드는 데이터 페이지를 가리킵니다.

그럼 단일 행을 저장할 수 없는 경우 두 개의 데이터 페이지에 저장하면 어떨까요? 아래 사진과 같습니다~.

단일 노드에 저장한다면, 메인뱅크에 저장하기 위해 여러 노드를 활용하겠습니다! 어쩌면 내 B+Tee가 이런 식으로 점점 더 커질 수도 있습니다(실제로는 잘못된 생각입니다)

이 잘못된 설명에 해당하는 두뇌 맵은 다음과 같습니다.

그러면 MySQL이 이것을 하지 않는 이유는 다음과 같습니다.

MySQL이 데이터 페이지에 더 많은 데이터 행을 저장하려면 최소한 두 행의 데이터를 저장해야 합니다. 그렇지 않으면 B+Tree의 의미가 상실됩니다. B+Tree도 비효율적인 연결리스트로 변질됩니다.

이 파란색 문장을 맛보실 수 있습니다. 각 데이터 페이지는 최소한 두 행의 데이터를 저장해야 한다고 말하지만, 데이터 페이지가 한 행만 저장할 수 없다는 의미는 아닙니다. 실제로 한 줄의 데이터를 작성한 다음 식사를 하고 다른 일을 할 수 있습니다. 이 데이터 페이지에는 항상 하나의 데이터 행만 있습니다.

이 문장의 의미는 이 데이터 페이지에 데이터 행을 쓰면 크기가 크더라도 데이터 페이지의 한계에 도달하지만 행 오버플로 메커니즘을 통해 발생한다는 것입니다. 다음 데이터 조각이 이 데이터 페이지에 기록될 수 있다는 것은 여전히 ​​보장됩니다.

올바른 뇌 지도는 다음과 같습니다.

위 내용은 MySQL의 데이터 행 및 행 오버플로 메커니즘에 대한 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!