MySQL 레코드 디스크 사용 계산 | 내가 맞습니까?

Question

MySQL RDBMS에서 테이블의 각 레코드에 대한 실제 디스크 사용 요구 공간을 계산하려고합니다.

테이블 이런 구조 가지고

• ID INT 4 바이트;
• VARCHAR (34) 34 바이트;
• INT 4 바이트;
• INT (5) 4 바이트;
• INT 4 바이트;
• INT 4 바이트 또한 외래 키입니다.

그래서 5 개의 INT 필드와 최대 34 개의 문자 (즉 34 바이트)의 VARCHAR가 있습니다.

나는이 개 질문이 : 내가 바로 내가 그 말을하고 할 때, 또는 오버 헤드 바이트도 있습니다입니다) 물론, 변수 VARCHAR로 (

1) 총 레코드 당 54 바이트해야을하는 디스크 사용 공간을 예측할 때 고려해야 할 사항은 무엇입니까?

2) 나는 그 필드에 정확히 5 자리 만 저장해야하기 때문에 CHAR (5) 대신 INT (5)를 사용했다. (나는 응용 프로그램으로 regExp와 문자열 길이로 INT (5)가 5 자리수 이상의 정수일 수 있음을 알아 두십시오.) 하지만 이것은 디스크 사용량 공간 최적화에 의해 5 바이트 인 CHAR (5) 대신 INT (4 바이트)를 사용하는 것과 같은 것으로 간주 될 수 있습니까? 즉, 레코드 당 1 바이트가 더 많습니까?

관심을 가져 주셔서 감사합니다. 자체 오프셋에서

1 바이트를 사용

Answer 1

한 기록하려면 별도의 비트

0 바이트의 "여분의 바이트"헤더

5 바이트

4 바이트의 ID

6 바이트 트랜잭션 ID

7 바이트 rollba VARCHAR에서 CK 포인터

0-3 * 34 바이트 (34)의 다른 정수

FK 각 고유 값

4 * 4 바이트 (한 문자 때문에 UTF8 3 바이트 소요) 보조 색인에서 하나의 레코드로 연결됩니다. 그것은 "추가 바이트"헤더

5 바이트를 사용

FK 값

4 바이트 INT

기본 키

기타 오버 헤드

4 바이트 INT는 페이지 레벨 : 페이지 당 120 바이트 (16k) 페이지 채우기 비율 15/16 - 한 페이지에 15k의 레코드가 포함될 수 있습니다.

그리고 마지막으로 - 작아야한다 비 리프 페이지에서 사용하는 추가 공간, 어쨌든

그래서, 질문에 대한 답 - 1) 예 위 정보를 이용하여 계산할 수 있습니다 약간의 오버 헤드가 될 것입니다.

CHAR (5)의 길이 바이트를 추가합니다 UTF8에, 그래서 INT는