Loading...
MySQL 9.5 Reference Manual 9.5의 13.7 Data Type Storage Requirements의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
디스크 상의 테이블 데이터에 대한 스토리지 요구 사항은 여러 가지 요소에 따라 달라집니다. 서로 다른 스토리지 엔진은 데이터 타입을 표현하고 로 데이터(raw data)를 저장하는 방식이 다릅니다. 컬럼 또는 전체 로우에 대해 테이블 데이터가 압축될 수 있으며, 이로 인해 테이블이나 컬럼의 스토리지 요구 사항을 계산하는 작업이 복잡해집니다.
디스크에서의 스토리지 레이아웃이 서로 다르더라도, 테이블 로우에 대한 정보를 통신하고 교환하는 내부 MySQL API는 모든 스토리지 엔진에 걸쳐 일관된 데이터 구조를 사용합니다.
이 절에는 MySQL이 지원하는 각 데이터 타입에 대한 스토리지 요구 사항(내부 형식 및 데이터 타입에 대해 고정 크기 표현을 사용하는 스토리지 엔진에 대한 크기 포함)에 대한 지침과 정보가 포함되어 있습니다. 정보는 범주 또는 스토리지 엔진별로 나열됩니다.
테이블의 내부 표현에서 로우의 최대 크기는 65,535바이트이며, 스토리지 엔진이 더 큰 로우를 지원할 수 있더라도 마찬가지입니다. 이 수치에는 이 크기에 대해 9~12바이트만 기여하는
BLOB 또는
TEXT 컬럼은 포함되지 않습니다.
BLOB 및
TEXT 데이터의 경우, 정보는 로우 버퍼와는 다른 메모리 영역에 내부적으로 저장됩니다. 서로 다른 스토리지 엔진은 해당 타입을 처리하기 위해 사용하는 방법에 따라 이 데이터의 할당과 스토리지를 서로 다른 방식으로 처리합니다.
더 많은 정보는 Chapter 18, Alternative Storage Engines 및 Section 10.4.7, “Limits on Table Column Count and Row Size”를 참조하십시오.
InnoDB 테이블에 대한 스토리지 요구 사항에 대한 정보는 Section 17.10, “InnoDB Row Formats”를 참조하십시오.
중요
NDB 테이블은 4바이트 얼라인먼트를 사용합니다.
모든 NDB 데이터 스토리지는 4바이트의 배수로 수행됩니다. 따라서 일반적으로 15바이트를 차지하는 컬럼 값은
NDB 테이블에서 16바이트가 필요합니다. 예를 들어,
NDB 테이블에서
TINYINT,
SMALLINT,
MEDIUMINT, 그리고
INTEGER
(INT) 컬럼 타입은 얼라인먼트 계수 때문에 레코드당 각각 4바이트의 스토리지가 필요합니다.
각 BIT(M) 컬럼은 스토리지 공간으로 M 비트를 사용합니다. 개별
BIT 컬럼은
4바이트 얼라인먼트가 아니지만,
NDB는 BIT 컬럼에 필요한 처음 1–32비트에 대해 로우당 4바이트(32비트)를 예약하고, 그다음 33–64비트에 대해 또 다른 4바이트를 예약하는 식으로 진행합니다.
NULL 자체는 어떤 스토리지 공간도 필요로 하지 않지만, 테이블 정의에 NULL을 허용하는 컬럼이 하나라도 포함된 경우에는 NDB가 로우당 최대 32개의
NULL 컬럼에 대해 4바이트를 예약합니다. (NDB Cluster 테이블이 32개를 초과하여 최대 64개의 NULL 컬럼으로 정의된 경우에는 로우당 8바이트가 예약됩니다.)
NDB 스토리지 엔진을 사용하는 모든 테이블에는 프라이머리 키가 필요합니다. 프라이머리 키를 정의하지 않으면, NDB에 의해 “hidden” 프라이머리 키가 생성됩니다. 이 hidden 프라이머리 키는 테이블 레코드당 31–35바이트를 소비합니다.
NDB 스토리지 요구 사항을 추정하기 위해 ndb_size.pl Perl 스크립트를 사용할 수 있습니다. 이 스크립트는 현재 MySQL (NDB Cluster가 아님) 데이터베이스에 연결하고, 이 데이터베이스가 NDB 스토리지 엔진을 사용한다면 얼마나 많은 공간이 필요할지를 나타내는 리포트를 생성합니다. 더 많은 정보는 Section 25.5.29, “ndb_size.pl — NDBCLUSTER Size Requirement Estimator”를 참조하십시오.
| Data Type | Storage Required |
|---|---|
TINYINT | 1바이트 |
SMALLINT | 2바이트 |
MEDIUMINT | 3바이트 |
INT,<br> INTEGER | 4바이트 |
BIGINT | 8바이트 |
FLOAT(p) | 0 <= p <= 24이면 4바이트, 25 <= p <= 53이면 8바이트 |
FLOAT | 4바이트 |
DOUBLE [PRECISION],<br> REAL | 8바이트 |
DECIMAL(M,D),<br> NUMERIC(M,D) | 가변; 다음 설명 참조 |
BIT(M) | 대략 ( M + 7) / 8바이트 |
| Data Type | Storage Required |
|---|
DECIMAL (및
NUMERIC) 컬럼의 값은 9개의 10진수(base 10)를 4바이트에 패킹하는 바이너리 포맷을 사용하여 표현됩니다. 각 값의 정수부와 소수부에 대한 스토리지는 개별적으로 결정됩니다. 9개의 자리수마다 4바이트가 필요하며, “남는” 자리수는 4바이트의 일부를 필요로 합니다. 초과 자리수에 필요한 스토리지는 다음 테이블에 나와 있습니다.
| Leftover Digits | Number of Bytes |
|---|---|
| 0 | 0 |
| 1 | 1 |
| 2 | 1 |
| 3 | 2 |
| 4 | 2 |
| 5 | 3 |
| 6 | 3 |
| 7 | 4 |
| 8 | 4 |
TIME,
DATETIME,
TIMESTAMP 컬럼의 경우, MySQL 5.6.4 이전에 생성된 테이블에 필요한 스토리지는 5.6.4부터 생성된 테이블과 다릅니다. 이는 5.6.4에서 이러한 타입에 분수 부분을 허용하도록 변경되었기 때문이며, 이 분수 부분에는 0~3바이트가 필요합니다.
| Data Type | Storage Required Before MySQL 5.6.4 | Storage Required as of MySQL 5.6.4 |
|---|---|---|
YEAR | 1바이트 | 1바이트 |
DATE | 3바이트 | 3바이트 |
TIME | 3바이트 | 3바이트 + fractional seconds storage |
DATETIME | 8바이트 | 5바이트 + fractional seconds storage |
TIMESTAMP | 4바이트 | 4바이트 + fractional seconds storage |
MySQL 5.6.4부터는
YEAR 및
DATE에 대한 스토리지는 변경되지 않았습니다.
그러나
TIME,
DATETIME,
TIMESTAMP는 다르게 표현됩니다.
DATETIME은 더 효율적으로 패킹되어 비분수 부분에 대해 8바이트 대신 5바이트만 필요하며, 세 가지 타입 모두 저장된 값의 fractional seconds precision에 따라 0~3바이트가 필요한 분수 부분을 가집니다.
| Fractional Seconds Precision | Storage Required |
|---|---|
| 0 | 0바이트 |
| 1, 2 | 1바이트 |
| 3, 4 | 2바이트 |
| 5, 6 | 3바이트 |
예를 들어, TIME(0),
TIME(2),
TIME(4),
TIME(6)는 각각 3, 4, 5, 6바이트를 사용합니다.
TIME과
TIME(0)는 동일하며 동일한 스토리지가 필요합니다.
temporal 값의 내부 표현에 대한 자세한 내용은 MySQL Internals: Important Algorithms and Structures를 참조하십시오.
다음 테이블에서 _M_은 논바이너리 문자열 타입의 경우 선언된 컬럼 길이를 문자 수로, 바이너리 문자열 타입의 경우 바이트 수로 나타냅니다.
_L_은 주어진 문자열 값의 실제 길이를 바이트 수로 나타냅니다.
| Data Type | Storage Required |
|---|---|
CHAR(M) | InnoDB 로우 포맷의 compact 패밀리는 가변 길이 문자 집합에 대해 스토리지를 최적화합니다. COMPACT Row Format Storage Characteristics를 참조하십시오.<br>그 밖의 경우, M × w 바이트, 0 <= M <= 255, 여기서 _w_는 문자 집합에서 최대 길이 문자가 필요로 하는 바이트 수입니다. |
BINARY(M) | M 바이트, 0 <= M <= 255 |
VARCHAR(M),<br> VARBINARY(M) | 컬럼 값이 0–255바이트를 필요로 하는 경우 L + 1바이트, 값이 255바이트를 초과할 수 있는 경우 L + 2바이트 |
TINYBLOB,<br> TINYTEXT | L + 1바이트, 여기서 L <<br> 2^8 |
BLOB, TEXT | L + 2바이트, 여기서 L <<br> 2^16 |
MEDIUMBLOB,<br> MEDIUMTEXT | L + 3바이트, 여기서 L <<br> 2^24 |
LONGBLOB,<br> LONGTEXT | L + 4바이트, 여기서 L <<br> 2^32 |
ENUM('value1','value2',...) | enumeration 값의 개수에 따라 1 또는 2바이트 (최대 65,535 값) |
SET('value1','value2',...) | set 멤버의 개수에 따라 1, 2, 3, 4, 또는 8바이트 (최대 64 멤버) |
variable-length 문자열 타입은 길이 프리픽스와 데이터로 저장됩니다. 길이 프리픽스에는 데이터 타입 및 프리픽스 값(문자열의 바이트 길이인 L)에 따라 1~4바이트가 필요합니다. 예를 들어,
MEDIUMTEXT 값에 대한 스토리지는 값을 저장하기 위한 L 바이트에 길이를 저장하기 위한 3바이트가 추가로 필요합니다.
특정
CHAR,
VARCHAR,
TEXT 컬럼 값에 사용되는 바이트 수를 계산하려면, 해당 컬럼에 사용된 문자 집합과 값에 멀티바이트 문자가 포함되어 있는지를 고려해야 합니다. 특히 UTF-8 유니코드 문자 집합을 사용할 때는 모든 문자가 동일한 바이트 수를 사용하지 않는다는 점을 염두에 두어야 합니다.
utf8mb3 및 utf8mb4 문자 집합은 각각 문자당 최대 3바이트와 4바이트가 필요할 수 있습니다. 서로 다른 범주의 utf8mb3 또는
utf8mb4 문자에 사용되는 스토리지에 대한 상세한 분류는
Section 12.9, “Unicode Support”를 참조하십시오.
VARCHAR,
VARBINARY,
BLOB,
TEXT 타입은 variable-length 타입입니다. 각 타입에 대해 스토리지 요구 사항은 다음 요소에 따라 달라집니다:
컬럼 값의 실제 길이
컬럼의 최대 가능 길이
컬럼에 사용된 문자 집합 (일부 문자 집합에는 멀티바이트 문자가 포함되어 있기 때문)
예를 들어, VARCHAR(255) 컬럼은 최대 길이가 255 문자인 문자열을 저장할 수 있습니다. 컬럼이 latin1 문자 집합(문자당 1바이트)을 사용한다고 가정하면, 실제로 필요한 스토리지는 문자열의 길이( L)에 문자열 길이를 기록하기 위한 1바이트를 더한 값입니다. 문자열
'abcd'의 경우 _L_은 4이므로 스토리지 요구 사항은 5바이트입니다. 동일한 컬럼이 대신 ucs2 더블바이트 문자 집합을 사용하도록 선언된 경우, 스토리지 요구 사항은 10바이트입니다. 'abcd'의 길이는 8바이트이고, 최대 길이가 255바이트를 초과(최대 510바이트까지)하므로 길이를 저장하는 데 2바이트가 필요하기 때문입니다.
VARCHAR 또는
VARBINARY 컬럼에 저장할 수 있는 _바이트_의 유효 최대 개수는 모든 컬럼이 공유하는 최대 로우 크기인 65,535바이트에 의해 제한됩니다. 멀티바이트 문자를 저장하는
VARCHAR 컬럼의 경우, _문자_의 유효 최대 개수는 이보다 작습니다. 예를 들어,
utf8mb4 문자는 문자당 최대 4바이트가 필요할 수 있으므로 utf8mb4 문자 집합을 사용하는
VARCHAR 컬럼은 최대 16,383 문자로 선언할 수 있습니다. Section 10.4.7, “Limits on Table Column Count and Row Size”를 참조하십시오.
InnoDB는 길이가 768바이트 이상인 고정 길이 필드를 가변 길이 필드로 인코딩할 수 있으며, 이 필드는 페이지 밖(off-page)에 저장될 수 있습니다. 예를 들어, 문자 집합의 최대 바이트 길이가 3보다 큰(utf8mb4의 경우처럼) 경우 CHAR(255) 컬럼은 768바이트를 초과할 수 있습니다.
NDB 스토리지 엔진은 가변 폭(variable-width) 컬럼을 지원합니다. 이는 NDB Cluster 테이블의
VARCHAR 컬럼이(4바이트 얼라인먼트 예외를 제외하면) 다른 어떤 스토리지 엔진과 동일한 양의 스토리지를 필요로 함을 의미합니다. 따라서 latin1 문자 집합을 사용하는 VARCHAR(50) 컬럼에 저장된 문자열 'abcd'는
MyISAM 테이블에서 동일한 컬럼 값이 5바이트가 필요한 것과 달리 8바이트가 필요합니다.
TEXT,
BLOB,
JSON 컬럼은 NDB 스토리지 엔진에서 다르게 구현됩니다. 여기서 컬럼의 각 로우는 두 개의 분리된 부분으로 구성됩니다. 이 중 하나는 고정 크기(TEXT와 BLOB의 경우 256바이트, JSON의 경우 4000바이트)이므로 실제로 원래 테이블에 저장됩니다. 다른 하나는 256바이트를 초과하는 데이터로 구성되며, hidden blob parts 테이블에 저장됩니다. 두 번째 테이블의 로우 크기는 컬럼의 정확한 타입에 따라 결정되며, 다음 테이블에 나와 있습니다:
| Type | Blob Part Size |
|---|---|
BLOB, TEXT | 2000 |
MEDIUMBLOB,<br> MEDIUMTEXT | 4000 |
LONGBLOB,<br> LONGTEXT | 13948 |
JSON | 8100 |
이는
TEXT 컬럼의 크기가 size <= 256(여기서 size는 로우의 크기를 나타냄)인 경우 256이며, 그렇지 않은 경우 크기는 256 + size + (2000 × (size − 256) % 2000)임을 의미합니다.
NDB는 TINYBLOB 또는 TINYTEXT 컬럼 값에 대해서는 blob part를 별도로 저장하지 않습니다.
NDB blob 컬럼의 blob part 크기는 parent 테이블을 생성하거나 변경할 때 컬럼 코멘트에서 NDB_COLUMN을 사용하여 최대 13948까지 늘릴 수 있습니다. NDB는 또한 컬럼 코멘트에서 NDB_TABLE을 사용하여 TEXT,
BLOB, JSON 컬럼의 인라인 크기 설정을 지원합니다. 더 많은 정보는 NDB_COLUMN Options를 참조하십시오.
ENUM 오브젝트의 크기는 서로 다른 enumeration 값의 개수에 따라 결정됩니다. 최대 255개의 가능한 값이 있는 enumeration에는 1바이트가 사용됩니다. 256에서 65,535 사이의 가능한 값을 가진 enumeration에는 2바이트가 사용됩니다. Section 13.3.6, “The ENUM Type”를 참조하십시오.
SET 오브젝트의 크기는 서로 다른 set 멤버의 개수에 따라 결정됩니다. set 크기가 _N_이면 오브젝트는 (N+7)/8바이트를 차지하며, 이는 1, 2, 3, 4 또는 8바이트로 올림됩니다.
SET은 최대 64개의 멤버를 가질 수 있습니다. Section 13.3.7, “The SET Type”를 참조하십시오.
MySQL은 geometry 값을 SRID를 나타내는 4바이트와 그 뒤에 값의 WKB 표현을 사용하여 저장합니다.
LENGTH() 함수는 값 스토리지에 필요한 바이트 수를 반환합니다.
spatial 값에 대한 WKB 및 내부 스토리지 포맷에 대한 설명은 Section 13.4.3, “Supported Spatial Data Formats”를 참조하십시오.
일반적으로
JSON 컬럼에 대한 스토리지 요구 사항은 LONGBLOB 또는
LONGTEXT 컬럼과 거의 동일합니다. 즉, JSON document가 차지하는 공간은 이들 타입 중 하나의 컬럼에 document의 문자열 표현을 저장하는 경우와 대략 동일합니다. 그러나 바이너리 인코딩(lookup을 위해 저장된 개별 값의 메타데이터 및 딕셔너리 포함)에 의해 부과되는 오버헤드가 있습니다. 예를 들어, JSON document에 저장된 문자열은 문자열 길이와 이 문자열이 저장된 오브젝트 또는 배열의 크기에 따라 4~10바이트의 추가 스토리지가 필요합니다.
또한 MySQL은 JSON 컬럼에 저장된 JSON document의 크기가
max_allowed_packet의 값보다 커질 수 없도록 제한을 둡니다.
13.6 Data Type Default Values
13.8 Choosing the Right Type for a Column
